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?
>
> [EMAIL PROTECTED]:~# 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
> [EMAIL PROTECTED]:~# strace -p 1 # init process, didn't expect to work
> attach: ptrace(PTRACE_ATTACH, ...): No such process
> [EMAIL PROTECTED]:~# strace -p 17873 # tracing inetd gives no output
> [EMAIL PROTECTED]:~# strace -p 17887 # atd process not permitted?
> trace: ptrace(PTRACE_SYSCALL, ...): Operation not permitted
> detach: ptrace(PTRACE_DETACH, ...): Operation not permitted
> [EMAIL PROTECTED]:~# 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 ...>
> [EMAIL PROTECTED]:~# strace -p 17770 # syslogd is fine
> select(1, [0], NULL, NULL, NULL <unfinished ...>
> [EMAIL PROTECTED]:~# strace -p 25148 # exim4 is also not permitted
> trace: ptrace(PTRACE_SYSCALL, ...): Operation not permitted
> detach: ptrace(PTRACE_DETACH, ...): Operation not permitted
> [EMAIL PROTECTED]:~# 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
> [EMAIL PROTECTED]:~#
>
> 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
>
> [EMAIL PROTECTED]:~# 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
[EMAIL PROTECTED]
http://list.linux-vserver.org/mailman/listinfo/vserver
