From: Joe Peterson <joe@skyrush.com>
To: Vegard Nossum <vegard.nossum@gmail.com>
Cc: Alan Cox <alan@redhat.com>, Alan Cox <alan@lxorguk.ukuu.org.uk>,
David Newall <davidn@davidnewall.com>, Willy Tarreau <w@1wt.eu>,
Harald Dunkel <harald.dunkel@t-online.de>,
linux-kernel@vger.kernel.org
Subject: Re: 2.6.25.3: su gets stuck for root
Date: Sat, 14 Jun 2008 14:52:05 -0600 [thread overview]
Message-ID: <48542F75.5070605@skyrush.com> (raw)
In-Reply-To: <19f34abd0806141334w67547e84hf1021c0fd1139b8b@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2153 bytes --]
Vegard Nossum wrote:
> Yeah, a user-space process can do this, and it's the right behaviour
> for the kernel. I did post a program that would "reproduce" what
> you're seeing. I do now believe that it's something timing-related, as
> Alan suggested initially. (But timing-related with your scripts, that
> is. I must say, that "sleep 2" does look a bit suspicious; I have no
> idea what that is supposed to do :-))
Ah, that is something I put in there to artificially make it more
reproducible. Here's the reason: when I first encountered the problem,
it was happening if the home dir of the user was on the "btrfs"
filesystem (the new checksumming one from Oracle). This made me suspect
btrfs initially. But I reproduced the problem [more sporadically] when
the home was on ext3 as well. Since btrfs has a different performance
profile, especially when first accessed after a mount (and it is a
filesystem still under development, so some optimizations are yet to
come), I figured it might be timing-related, and sure enough, adding the
"sleep 2" proved that.
So without the sleep 2 and with a home of ext3, it rarely happens, since
it takes very little time to read the homedir files (.bashrc, etc.).
Putting in the sleep makes it almost always happen. It seems like the
delay invoked by the sleep causes that subsequent stty call to hang.
> I suppose it would be more useful to see a trace where you include a
> few more system calls, can you try:
>
> # strace -e trace=process,ioctl,setpgid -f su foo
>
> instead?
OK, attached.
> Just for the record, I'm probably not the best person to debug this,
> so I'm just trying to figure it out as we go. On the other hand, I
> don't see better suggestions from anybody else. Thank you for
> persisting, though! :-)
>
> (And the fact that the results differ with the kernel versions does
> make this relevant for LKML still.)
Thanks for helping. Yes, this is the kind of nagging issue that really
bugs me, since it is intermittent and makes things feel unstable. If we
determine the problem is in something else (like stty or bash), then at
least I can file a bug with them.
-Joe
[-- Attachment #2: strace_su.log --]
[-- Type: text/x-log, Size: 5681 bytes --]
9738 execve("/bin/su", ["su", "foo"], [/* 50 vars */]) = 0
9738 ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0
9738 ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0
9738 ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0
9738 clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0xb7dfc708) = 9740
9738 waitpid(-1, <unfinished ...>
9740 execve("/bin/bash", ["bash"], [/* 50 vars */]) = 0
9740 ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0
9740 ioctl(2, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0
9740 ioctl(255, TIOCGPGRP, [9737]) = 0
9740 setpgid(0, 9740) = 0
9740 ioctl(255, TIOCSPGRP, [9740]) = 0
9740 ioctl(255, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0
9740 clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0xb7df1708) = 9741
9741 exit_group(0) = ?
9740 --- SIGCHLD (Child exited) @ 0 (0) ---
9740 waitpid(-1, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], WNOHANG) = 9741
9740 waitpid(-1, 0xbfb187fc, WNOHANG) = -1 ECHILD (No child processes)
9740 ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, 0xbfb18774) = -1 ENOTTY (Inappropriate ioctl for device)
9740 clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0xb7df1708) = 9742
9742 clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0xb7df1708) = 9743
9742 waitpid(-1, <unfinished ...>
9743 execve("/usr/bin/dircolors", ["dircolors", "-b", "/etc/DIR_COLORS"], [/* 49 vars */]) = 0
9743 exit_group(0) = ?
9742 <... waitpid resumed> [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], 0) = 9743
9742 --- SIGCHLD (Child exited) @ 0 (0) ---
9742 waitpid(-1, 0xbfb17fbc, WNOHANG) = -1 ECHILD (No child processes)
9742 exit_group(0) = ?
9740 --- SIGCHLD (Child exited) @ 0 (0) ---
9740 waitpid(-1, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], WNOHANG) = 9742
9740 waitpid(-1, 0xbfb1824c, WNOHANG) = -1 ECHILD (No child processes)
9740 clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0xb7df1708) = 9744
9740 waitpid(-1, <unfinished ...>
9744 execve("/bin/sleep", ["sleep", "2"], [/* 49 vars */]) = 0
9744 exit_group(0) = ?
9740 <... waitpid resumed> [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], 0) = 9744
9740 ioctl(255, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0
9740 ioctl(255, TIOCGWINSZ, {ws_row=30, ws_col=80, ws_xpixel=724, ws_ypixel=454}) = 0
9740 ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0
9740 ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0
9740 ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0
9740 ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0
9740 ioctl(1, TIOCGWINSZ, {ws_row=30, ws_col=80, ws_xpixel=724, ws_ypixel=454}) = 0
9740 ioctl(0, TIOCGWINSZ, {ws_row=30, ws_col=80, ws_xpixel=724, ws_ypixel=454}) = 0
9740 --- SIGCHLD (Child exited) @ 0 (0) ---
9740 waitpid(-1, 0xbfb18d3c, WNOHANG) = -1 ECHILD (No child processes)
9740 clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0xb7df1708) = 9745
9740 waitpid(-1, <unfinished ...>
9745 execve("/bin/stty", ["stty", "-ixany"], [/* 49 vars */]) = 0
9745 ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0
9745 ioctl(0, SNDCTL_TMR_STOP or TCSETSW, {B38400 opost isig icanon echo ...}) = 0
9745 ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0
9745 exit_group(0) = ?
9740 <... waitpid resumed> [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], 0) = 9745
9740 ioctl(255, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0
9740 ioctl(255, TIOCGWINSZ, {ws_row=30, ws_col=80, ws_xpixel=724, ws_ypixel=454}) = 0
9740 --- SIGCHLD (Child exited) @ 0 (0) ---
9740 waitpid(-1, 0xbfb18d3c, WNOHANG) = -1 ECHILD (No child processes)
9740 ioctl(255, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0
9740 ioctl(255, TIOCGWINSZ, {ws_row=30, ws_col=80, ws_xpixel=724, ws_ypixel=454}) = 0
9740 ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0
9740 ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0
9740 ioctl(1, TIOCGWINSZ, {ws_row=30, ws_col=80, ws_xpixel=724, ws_ypixel=454}) = 0
9740 ioctl(0, TIOCGWINSZ, {ws_row=30, ws_col=80, ws_xpixel=724, ws_ypixel=454}) = 0
9740 ioctl(0, TIOCSWINSZ, {ws_row=30, ws_col=80, ws_xpixel=724, ws_ypixel=454}) = 0
9740 ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0
9740 ioctl(255, TIOCSPGRP, [9740]) = 0
9740 ioctl(0, TIOCGWINSZ, {ws_row=30, ws_col=80, ws_xpixel=724, ws_ypixel=454}) = 0
9740 ioctl(0, TIOCSWINSZ, {ws_row=30, ws_col=80, ws_xpixel=724, ws_ypixel=454}) = 0
9740 ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0
9740 ioctl(0, SNDCTL_TMR_STOP or TCSETSW, {B38400 opost isig -icanon -echo ...}) = 0
9740 ioctl(0, SNDCTL_TMR_STOP or TCSETSW, {B38400 opost isig icanon echo ...}) = 0
9740 ioctl(255, TIOCSPGRP, [9737]) = 0
9740 setpgid(0, 9737) = 0
9740 exit_group(0) = ?
9738 <... waitpid resumed> [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], WSTOPPED) = 9740
9738 exit_group(0) = ?
next prev parent reply other threads:[~2008-06-14 20:52 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-02 1:31 2.6.25.3: su gets stuck for root Joe Peterson
2008-06-02 5:12 ` Harald Dunkel
2008-06-02 5:32 ` Willy Tarreau
2008-06-02 5:55 ` Joe Peterson
2008-06-02 8:10 ` Alan Cox
2008-06-02 9:01 ` David Newall
2008-06-02 9:20 ` Alan Cox
2008-06-02 10:16 ` Vegard Nossum
2008-06-02 10:39 ` Vegard Nossum
2008-06-02 10:52 ` Alan Cox
2008-06-02 10:57 ` Vegard Nossum
2008-06-02 12:28 ` Alan Cox
2008-06-02 14:31 ` Vegard Nossum
2008-06-02 10:50 ` Alan Cox
2008-06-17 15:32 ` Joe Peterson
2008-06-02 15:26 ` Joe Peterson
2008-06-02 15:51 ` Alan Cox
2008-06-02 16:03 ` Joe Peterson
2008-06-04 14:43 ` Joe Peterson
2008-06-04 15:16 ` Alan Cox
2008-06-04 16:52 ` Joe Peterson
2008-06-04 17:10 ` Alan Cox
2008-06-04 20:32 ` Joe Peterson
2008-06-11 14:04 ` Joe Peterson
2008-06-12 11:52 ` Vegard Nossum
2008-06-14 1:49 ` Joe Peterson
2008-06-14 7:45 ` Vegard Nossum
2008-06-14 17:43 ` Joe Peterson
2008-06-14 20:34 ` Vegard Nossum
2008-06-14 20:52 ` Joe Peterson [this message]
2008-06-14 21:26 ` Vegard Nossum
2008-06-14 21:34 ` Joe Peterson
2008-07-02 18:03 ` tty session leader issue (was Re: 2.6.25.3: su gets stuck for root) Joe Peterson
2008-07-02 19:21 ` markus reichelt
2008-07-06 14:08 ` Tim Connors
2008-07-06 16:44 ` Alan Cox
2008-07-06 18:49 ` tty session leader issue [cause now known!] " Joe Peterson
2008-06-02 5:42 ` 2.6.25.3: su gets stuck for root Joe Peterson
-- strict thread matches above, loose matches on Subject: below --
2008-05-13 6:17 Harald Dunkel
2008-05-13 6:47 ` Vegard Nossum
2008-05-13 17:43 ` Harald Dunkel
2008-05-13 19:46 ` Willy Tarreau
2008-05-14 4:55 ` Harald Dunkel
2008-05-14 5:46 ` Willy Tarreau
2008-05-14 7:34 ` Vegard Nossum
2008-05-14 17:05 ` Harald Dunkel
2008-05-14 17:17 ` Vegard Nossum
2008-05-14 17:35 ` Alan Cox
2008-05-18 17:56 ` Harald Dunkel
2008-05-18 17:51 ` Alan Cox
2008-05-20 19:01 ` Harald Dunkel
2008-05-20 19:12 ` david
2008-05-20 20:26 ` Harald Dunkel
2008-05-20 20:38 ` Willy Tarreau
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=48542F75.5070605@skyrush.com \
--to=joe@skyrush.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=alan@redhat.com \
--cc=davidn@davidnewall.com \
--cc=harald.dunkel@t-online.de \
--cc=linux-kernel@vger.kernel.org \
--cc=vegard.nossum@gmail.com \
--cc=w@1wt.eu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox