About this list Date view Thread view Subject view Author view Attachment view

From: Tomas Fasth (tomas_at_euronetics.se)
Date: Wed 13 Oct 2004 - 12:31:59 BST


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.

Regards, Tomas
_______________________________________________
Vserver mailing list
Vserver_at_list.linux-vserver.org
http://list.linux-vserver.org/mailman/listinfo/vserver


About this list Date view Thread view Subject view Author view Attachment view
[Next/Previous Months] [Main vserver Project Homepage] [Howto Subscribe/Unsubscribe] [Paul Sladen's vserver stuff]
Generated on Wed 13 Oct 2004 - 12:32:36 BST by hypermail 2.1.3