From: Herbert Poetzl (herbert_at_13thfloor.at)
Date: Wed 13 Oct 2004 - 15:17:26 BST
On Wed, Oct 13, 2004 at 01:31:59PM +0200, Tomas Fasth wrote:
> Herbert Poetzl wrote:
> >On Mon, Oct 11, 2004 at 05:36:52PM +0200, Tomas Fasth wrote:
> >
> >>Hello list
> >>
> >>I have a production system running linux kernel version 2.4.20 with
> >>ctx patch applied. After entering a virtual context I'm unable to
> >>attach to running processes using the strace utility, and I don't
> >>understand why. What am I missing?
> >
> >
> >hmm, maybe an update?
>
> Yes, that would definitely be a Good Thing (tm). However, being on a
> stable on-line production system while troubleshooting a mta problem
> unrelated to vserver functionality, I was a bit reluctant to change
> the runtime environment until I have located the source of this
> particular problem. Running strace was just a convinient way to
> better understand what that particular program was doing.
>
> May be I should put the question differently; Is there a reasonable
> explaination to the following behavior?
>
> root_at_queue:~# ps ax
> PID TTY STAT TIME COMMAND
> 1 ? S 0:07 init [2]
> 17873 ? S 0:00 /usr/sbin/inetd
> 17887 ? S 0:00 [atd]
> 17890 ? S 0:00 /usr/sbin/cron
> 13149 ? S 0:00 [sshd]
> 13151 ? S 0:00 [sshd]
> 13152 pts/0 S 0:00 -bash
> 13153 pts/0 S 0:00 bash
> 25148 ? S 0:01 [exim4]
> 17884 ? S 0:02 /usr/sbin/sshd
> 17770 ? S 0:05 /sbin/syslogd
> 13224 pts/0 R 0:00 ps ax
> root_at_queue:~# strace -p 1 # init process, didn't expect to work
> attach: ptrace(PTRACE_ATTACH, ...): No such process
> root_at_queue:~# strace -p 17873 # tracing inetd gives no output
> root_at_queue:~# strace -p 17887 # atd process not permitted?
> trace: ptrace(PTRACE_SYSCALL, ...): Operation not permitted
> detach: ptrace(PTRACE_DETACH, ...): Operation not permitted
> root_at_queue:~# strace -p 17890 # cron process, can do
> time(NULL) = 1097618204
> time(NULL) = 1097618204
> rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
> rt_sigaction(SIGCHLD, NULL, {0x804a0a8, [CHLD],
> SA_RESTART|0x4000000}, 8) = 0
> rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
> nanosleep({17, 0}, <unfinished ...>
> root_at_queue:~# strace -p 17770 # syslogd is fine
> select(1, [0], NULL, NULL, NULL <unfinished ...>
> root_at_queue:~# strace -p 25148 # exim4 is also not permitted
> trace: ptrace(PTRACE_SYSCALL, ...): Operation not permitted
> detach: ptrace(PTRACE_DETACH, ...): Operation not permitted
> root_at_queue:~# ps ax
> PID TTY STAT TIME COMMAND
> 1 ? S 0:07 init [2]
> 13149 ? S 0:00 [sshd]
> 13151 ? S 0:00 [sshd]
> 13152 pts/0 S 0:00 -bash
> 13153 pts/0 S 0:00 bash
> 17884 ? S 0:02 /usr/sbin/sshd
> 17873 ? S 0:00 /usr/sbin/inetd
> 17887 ? T 0:00 [atd]
> 17890 ? S 0:00 /usr/sbin/cron
> 17770 ? S 0:05 /sbin/syslogd
> 25148 ? T 0:01 [exim4]
> 13325 pts/0 R 0:00 ps ax
> root_at_queue:~#
>
> So, strace on cron and syslogd work as expected; atd and exim4 does
> not. Further more, note that atd and exim4 is now in T (traced or
> stopped) mode. Running
>
> root_at_queue:~# kill -CONT 17887 25148
>
> will bring those processes back to life. Have anybody on this list
> seen this behavior before? Is it a known problem in older ctx
> patches? Maybe Jacques can recall something? Just gaining some
> understanding on the issue would help me alot. I'm not asking for a
> fix, since I will eventually upgrade the system anyway.
the mechanisms of ptrace are based on the break/stop/cont
functionality, the operation not permitted is probably
caused by the vserver patch, but the stopped process
remains is normal behavior ...
the ppid in the 'fakeinit' setup can not be resolved
properly so maybe this explains the selection of
traceable and untraceable processes, a pstree would
be nice here with pids and if possible ppids from
/proc ...
HTH,
Herbert
> Regards, Tomas
_______________________________________________
Vserver mailing list
Vserver_at_list.linux-vserver.org
http://list.linux-vserver.org/mailman/listinfo/vserver