Re: cvs commit: src/sys/kern kern_sig.c (fwd)
Tim Robbins wrote: > This has nothing to do with PAM. Here is a simple program which behaves > differently between 4.6-RELEASE and 5.0-CURRENT. I don't know which > of the two behaviours is correct. [ ... ] If 4.6 disagrees with 5.0, then 5.0 is wrong (IMO), because a change was necessary for them to disagree. BTW: *This* is the bug that I was thinking about, Andrey... -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/kern kern_sig.c (fwd)
There is a kernel change brewing that may change this On Wed, 14 Aug 2002, Tim Robbins wrote: > > This has nothing to do with PAM. Here is a simple program which behaves > differently between 4.6-RELEASE and 5.0-CURRENT. I don't know which > of the two behaviours is correct. > > [...] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/kern kern_sig.c (fwd)
On Tue, Aug 13, 2002 at 11:54:06PM -0700, Terry Lambert wrote:
> Tim Robbins wrote:
> > On Tue, Aug 13, 2002 at 05:04:20PM -0700, Terry Lambert wrote:
> > > Both different reports have been from Tim Robbins. It may
> > > be that he has a local problem, and that his local problem
> > > is greatly confusing this discussion.
> >
> > Unfortunately, this is not a local problem -- I can reproduce it locally
> > (i386, world/kernel from yesterday), on panther.freebsd.org (sparc64, kernel
> > built July 19), and beast.freebsd.org (alpha, also built July 19). I cannot
> > reproduce it on ref5 (i386, built July 1).
>
> If you update to the very most recent current, do the problems
> occur? It's currently August 13th, which means that you are a
> month behind on the machines with the problem, and a month and
> a half behind on the other.
The kernel/world I am running locally is less than 24 hours old.
>
> If both problems still occur with the most recent current, do
> they go away if you back out *just* the PAM changes?
This has nothing to do with PAM. Here is a simple program which behaves
differently between 4.6-RELEASE and 5.0-CURRENT. I don't know which
of the two behaviours is correct.
#include
#include
#include
#include
#include
#include
#include
int
main(int argc, char *argv[])
{
pid_t pid;
int status;
switch (pid = vfork()) {
case -1:
err(1, "fork");
case 0:
execl("/bin/csh", "csh", NULL);
err(1, "csh");
default:
fprintf(stderr, "(waiter) waiting\n");
while (waitpid(pid, &status, WUNTRACED) != -1 && WIFSTOPPED(status)) {
fprintf(stderr, "(waiter) stopping ourself\n");
killpg(0, SIGSTOP);
fprintf(stderr, "(waiter) continuing child\n");
killpg(pid, SIGCONT);
fprintf(stderr, "(waiter) waiting\n");
}
}
return (0);
}
%%
4.6.1-RELEASE-p10, OpenBSD 3.0:
%set prompt="root% "
root% ./waiter
(waiter) waiting
%suspend
Suspended
root% fg
./waiter
%
5.0-CURRENT built August 14 (today):
%set prompt="root% "
root% ./waiter
(waiter) waiting
%suspend
Suspended
root% fg
./waiter
%(waiter) stopping ourself
Suspended (signal)
root%
Linux behaves differently to both, but the change in behaviour does not
seem to make it stop working.
Tim
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/kern kern_sig.c (fwd)
Tim Robbins wrote: > On Tue, Aug 13, 2002 at 05:04:20PM -0700, Terry Lambert wrote: > > Both different reports have been from Tim Robbins. It may > > be that he has a local problem, and that his local problem > > is greatly confusing this discussion. > > Unfortunately, this is not a local problem -- I can reproduce it locally > (i386, world/kernel from yesterday), on panther.freebsd.org (sparc64, kernel > built July 19), and beast.freebsd.org (alpha, also built July 19). I cannot > reproduce it on ref5 (i386, built July 1). If you update to the very most recent current, do the problems occur? It's currently August 13th, which means that you are a month behind on the machines with the problem, and a month and a half behind on the other. If both problems still occur with the most recent current, do they go away if you back out *just* the PAM changes? You haven't really done the necessary fault isolation needed to determine if there is a problem which was introduced by the KSE commit to the signal handling (and your July 19th date is too early for anyone to reasonably repeat your testing). It may be that something was broken and then fixed, and you do not have the fix simply because you are running old code. It's always possible to find the fix, even if you have to do a binary search of the source tree. For 32 days, we are talking log2(32)+1 or 6 builds, maximum, to find the commit that is the root cause of the behaviour you are seeing. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/kern kern_sig.c (fwd)
Terry Lambert wrote: > Steve Kargl wrote: > > On Tue, Aug 13, 2002 at 06:25:37PM -0700, Terry Lambert wrote: > > > The patch that Tim posted, which is GPL'ed because of its origin, > > > and therefore unusable exacept as a model, "fixes" the problem > > > by blocking the signal delivery before the fork. > > > > Can you provide a non-GPL patch to assuage your repeated > > beratement of Tim? > > I'm not repeatedly berating him. I'm simply pointing out > that the proposed patch has a license incompatbile with > the source code. As to your question about the patch, I'm using code that predates the PAM changes, and not running with the most recent set of KSE changes to the signal handling, so I don't have the problem. The simplest solution is to undo the things that happened between the time the problem started, and the time there wasn't a problem. IMO, it's the responsibility of the people who broke it to fix it, as the price for having the changes they made stay in the source tree. Making changes that break things you personally don't care about is not a workable model (also IMO). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/kern kern_sig.c (fwd)
Steve Kargl wrote: > On Tue, Aug 13, 2002 at 06:25:37PM -0700, Terry Lambert wrote: > > The patch that Tim posted, which is GPL'ed because of its origin, > > and therefore unusable exacept as a model, "fixes" the problem > > by blocking the signal delivery before the fork. > > Can you provide a non-GPL patch to assuage your repeated > beratement of Tim? I'm not repeatedly berating him. I'm simply pointing out that the proposed patch has a license incompatbile with the source code. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/kern kern_sig.c (fwd)
On Tue, Aug 13, 2002 at 05:04:20PM -0700, Terry Lambert wrote: > Both different reports have been from Tim Robbins. It may > be that he has a local problem, and that his local problem > is greatly confusing this discussion. Unfortunately, this is not a local problem -- I can reproduce it locally (i386, world/kernel from yesterday), on panther.freebsd.org (sparc64, kernel built July 19), and beast.freebsd.org (alpha, also built July 19). I cannot reproduce it on ref5 (i386, built July 1). Tim To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/kern kern_sig.c (fwd)
On Tue, Aug 13, 2002 at 06:25:37PM -0700, Terry Lambert wrote: > > The patch that Tim posted, which is GPL'ed because of its origin, > and therefore unusable exacept as a model, "fixes" the problem > by blocking the signal delivery before the fork. > Can you provide a non-GPL patch to assuage your repeated beratement of Tim? -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/kern kern_sig.c (fwd)
--- Terry Lambert <[EMAIL PROTECTED]> wrote: > > My machine may be different with Tim's, it is a P4 1.5G CPU, > > its speed maybe fast enough to skip the problem. BTW, bde has > > also reported the problem, so this is serious, wouldn't kernel > > send out SIGTTOU when null change a foreground group is enough > > to fix the problem?. but why don't they block SIGTTOU when > > calling tcsetpgrp()? > > Bruce reported the first problem, with su, which arose from > DES changing the code to support PAM, and to have an extra > fork, where it didn't before. > > Bruce reported that he *didn't* have the second problem reported > by Tim Robbins, which appears to be local to his site (a search > of the archives indicates that he is the only one reporting it). > > The patch that Tim posted, which is GPL'ed because of its origin, > and therefore unusable exacept as a model, "fixes" the problem > by blocking the signal delivery before the fork. > > Note that merely blocking the delivery means that the signal will > be delivered later, since block sugnals are accumulated, not > discarded (see what the patch does, for details). > > -- Terry Sorry, I mean ignore SIGTTOU. David Xu __ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/kern kern_sig.c (fwd)
David Xu wrote: > > Both different reports have been from Tim Robbins. It may > > be that he has a local problem, and that his local problem > > is greatly confusing this discussion. > > > > If you can not repeat his second problem on -current locally, > > I would be tempted to dismiss it as being a local problem, and > > not a general one. > > > > Tim was also the person who posted the GPL'ed path that I was > > worried that Andrey was using against "su"; not to disparage > > anyone, but most of my personal confusion has been coming from > > things Tim said... 8-). > > My machine may be different with Tim's, it is a P4 1.5G CPU, > its speed maybe fast enough to skip the problem. BTW, bde has > also reported the problem, so this is serious, wouldn't kernel > send out SIGTTOU when null change a foreground group is enough > to fix the problem?. but why don't they block SIGTTOU when > calling tcsetpgrp()? Bruce reported the first problem, with su, which arose from DES changing the code to support PAM, and to have an extra fork, where it didn't before. Bruce reported that he *didn't* have the second problem reported by Tim Robbins, which appears to be local to his site (a search of the archives indicates that he is the only one reporting it). The patch that Tim posted, which is GPL'ed because of its origin, and therefore unusable exacept as a model, "fixes" the problem by blocking the signal delivery before the fork. Note that merely blocking the delivery means that the signal will be delivered later, since block sugnals are accumulated, not discarded (see what the patch does, for details). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/kern kern_sig.c (fwd)
--- Terry Lambert <[EMAIL PROTECTED]> wrote: > David Xu wrote: > > > What about chpass, vipw, and the other pw_edit() consumers? vipw > > > works correctly wrt suspending with ^Z on 4.6-RELEASE, but does not > > > on -CURRENT. As far as I can see, pw_edit()'s logic has not been changed. > > > > > > This is a slightly different case to that of the shell suspending _itself_, > > > but I think it's similar enough that the solution may be the same. > > > > I have very current source, and don't have any problem you have encountered. > > I can not reproduced it. > > > Both different reports have been from Tim Robbins. It may > be that he has a local problem, and that his local problem > is greatly confusing this discussion. > > If you can not repeat his second problem on -current locally, > I would be tempted to dismiss it as being a local problem, and > not a general one. > > Tim was also the person who posted the GPL'ed path that I was > worried that Andrey was using against "su"; not to disparage > anyone, but most of my personal confusion has been coming from > things Tim said... 8-). > > -- Terry My machine may be different with Tim's, it is a P4 1.5G CPU, its speed maybe fast enough to skip the problem. BTW, bde has also reported the problem, so this is serious, wouldn't kernel send out SIGTTOU when null change a foreground group is enough to fix the problem?. but why don't they block SIGTTOU when calling tcsetpgrp()? David __ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/kern kern_sig.c (fwd)
David Xu wrote: > > What about chpass, vipw, and the other pw_edit() consumers? vipw > > works correctly wrt suspending with ^Z on 4.6-RELEASE, but does not > > on -CURRENT. As far as I can see, pw_edit()'s logic has not been changed. > > > > This is a slightly different case to that of the shell suspending _itself_, > > but I think it's similar enough that the solution may be the same. > > I have very current source, and don't have any problem you have encountered. > I can not reproduced it. Both different reports have been from Tim Robbins. It may be that he has a local problem, and that his local problem is greatly confusing this discussion. If you can not repeat his second problem on -current locally, I would be tempted to dismiss it as being a local problem, and not a general one. Tim was also the person who posted the GPL'ed path that I was worried that Andrey was using against "su"; not to disparage anyone, but most of my personal confusion has been coming from things Tim said... 8-). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/kern kern_sig.c (fwd)
--- Tim Robbins <[EMAIL PROTECTED]> wrote: > On Tue, Aug 13, 2002 at 06:14:38AM -0700, David Xu wrote: > > > --- Terry Lambert <[EMAIL PROTECTED]> wrote: > > > I did. It's still an order of operation problem in the kernel > > > during fork(), as Bruce pointed out in a later posting (so me > > > pointing it out here is probably redundant... 8-)). > > > > > > I still think other code is going to have the problem, too, so > > > changing su alone doesn't fix things. Better to not deliver > > > the tty output stopped signal. > > > > > > -- Terry > > > > Don't touch tty code, if you change, you'll break more code, > > current problem is just because su forks a child process and > > want to take over some job control work from shell, it is of > > course not a easy job. the problem does not exist in STABLE > > branch because su does not fork. > > What about chpass, vipw, and the other pw_edit() consumers? vipw > works correctly wrt suspending with ^Z on 4.6-RELEASE, but does not > on -CURRENT. As far as I can see, pw_edit()'s logic has not been changed. > > This is a slightly different case to that of the shell suspending _itself_, > but I think it's similar enough that the solution may be the same. > > > Tim I have very current source, and don't have any problem you have encountered. I can not reproduced it. David Xu __ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/kern kern_sig.c (fwd)
Bruce Evans wrote: > Er, I didn't point out anything like this, and thought that it wasn't > a kernel problem. It's certainly not a problem at fork() time. [ ... ] > I think unwanted SIGTTOU's are just a sympto. Here's the source of my confusion; I thought that you meant they were the proximal cause. > > What about chpass, vipw, and the other pw_edit() consumers? vipw > > works correctly wrt suspending with ^Z on 4.6-RELEASE, but does not > > on -CURRENT. As far as I can see, pw_edit()'s logic has not been changed. > > Here is a trace for vi and vipw (but not the shell) from when I hit ^Z > in the editor to when the shell is given control because vi is bogusly > stopped again: [ ... ] > This ioctl blocks and the shell gains control. Apparently vi is still > in the background at this point, but it shouldn't be... Or maybe which > process is in the background depends on races, and it is normal for > vi to block here (please check on RELENG_4 if you have it handy), and > the problem is simply a missing or extra signal that results in vi not > being put back in the foreground. This does not happen in 4.1-RELEASE or 4.4-RELEASE, AFAICT. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/kern kern_sig.c (fwd)
On Tue, 13 Aug 2002, Tim Robbins wrote: > On Tue, Aug 13, 2002 at 06:14:38AM -0700, David Xu wrote: > > > --- Terry Lambert <[EMAIL PROTECTED]> wrote: > > > I did. It's still an order of operation problem in the kernel > > > during fork(), as Bruce pointed out in a later posting (so me > > > pointing it out here is probably redundant... 8-)). Er, I didn't point out anything like this, and thought that it wasn't a kernel problem. It's certainly not a problem at fork() time. > > > I still think other code is going to have the problem, too, so > > > changing su alone doesn't fix things. Better to not deliver > > > the tty output stopped signal. > > > > Don't touch tty code, if you change, you'll break more code, > > current problem is just because su forks a child process and > > want to take over some job control work from shell, it is of > > course not a easy job. the problem does not exist in STABLE > > branch because su does not fork. I think unwanted SIGTTOU's are just a sympto. > What about chpass, vipw, and the other pw_edit() consumers? vipw > works correctly wrt suspending with ^Z on 4.6-RELEASE, but does not > on -CURRENT. As far as I can see, pw_edit()'s logic has not been changed. Here is a trace for vi and vipw (but not the shell) from when I hit ^Z in the editor to when the shell is given control because vi is bogusly stopped again: 32898 vi 0.10 CALL read(0,0x8118000,0xff) 32898 vi 8.642726 GIO fd 0 read 1 byte "\^Z" I waited about 10 seconds before hitting ^Z. 32898 vi 0.36 RET read 1 32898 vi 0.007736 CALL break(0x813c000) 32898 vi 0.08 RET break 0 32898 vi 0.000650 CALL sigaction(0x12,0x810684c,0x8106864) 32898 vi 0.04 RET sigaction 0 32898 vi 0.002177 CALL poll(0xbfbff438,0x1,0) 32898 vi 0.07 RET poll 0 32898 vi 0.000997 CALL poll(0xbfbff438,0x1,0) 32898 vi 0.12 RET poll 0 32898 vi 0.55 CALL write(0x1,0x8131000,0x5) 32898 vi 0.17 GIO fd 1 wrote 5 bytes "\^[[25d" 32898 vi 0.67 RET write 5 32898 vi 0.06 CALL sigaction(0x12,0x8106864,0) 32898 vi 0.04 RET sigaction 0 32898 vi 0.16 CALL write(0x1,0x8131000,0x8) 32898 vi 0.05 GIO fd 1 wrote 8 bytes "\^[[25;1H\r" 32898 vi 0.24 RET write 8 32898 vi 0.000731 CALL ioctl(0x1,TIOCSETAW,0x811942c) 32898 vi 0.17 RET ioctl 0 32898 vi 0.000510 CALL ioctl(0,TIOCSETAW,0xbfbff440) 32898 vi 0.10 RET ioctl 0 32898 vi 0.001196 CALL kill(0,0x12) vi does some setup and then kills the process group with SIGTSTP. 32897 vipw 5.363986 RET wait4 32898/0x8082 I waited about 5 seconds before hitting %. 32898 vi 0.33 RET kill 0 vi regained control. Not sure if this is right. 32897 vipw 0.004388 CALL getpid 32897 vipw 0.02 RET getpid 32897/0x8081 32898 vi 0.19 CALL sigaction(0x12,0x810684c,0x8106864) 32898 vi 0.04 RET sigaction 0 32897 vipw 0.005508 CALL kill(0x8081,0x12) vipw does nothing much and then kills itself with SIGTSTP. 32898 vi 0.64 CALL ioctl(0x1,TIOCGETA,0xbfbff3a0) 32898 vi 0.03 RET ioctl 0 32898 vi 0.002309 CALL ioctl(0x1,TIOCGWINSZ,0xbfbff3f8) 32898 vi 0.03 RET ioctl 0 32898 vi 0.007648 CALL ioctl(0x1,TIOCSETAW,0x8119458) This ioctl blocks and the shell gains control. Apparently vi is still in the background at this point, but it shouldn't be... Or maybe which process is in the background depends on races, and it is normal for vi to block here (please check on RELENG_4 if you have it handy), and the problem is simply a missing or extra signal that results in vi not being put back in the foreground. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/kern kern_sig.c (fwd)
On 13-Aug-2002 (15:06:48/GMT) Riccardo Torrini wrote: > ...important data are on NFS -CURRENT server... No, I means -STABLE server (obvious :) Riccardo. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/kern kern_sig.c (fwd)
On 13-Aug-2002 (13:59:39/GMT) Tim Robbins wrote: > What about chpass, vipw, and the other pw_edit() consumers? vipw > works correctly wrt suspending with ^Z on 4.6-RELEASE, but does > not on -CURRENT. vipw works _perfectly_ here, on a not-too-current -CURRENT, from tcsh I can suspend (^Z), list jobs (jobs), resume (fg) and I can continue editing, with the cursor exactly in the same place. This is a SMP machine, dual pIII/500, I use as my desktop (important data are on NFS -CURRENT server :P) from 3.0, so it can contain a lot of old (unsed) file, maybe even a.out ones... # uname -v FreeBSD 5.0-CURRENT #34: Wed May 8 02:31:46 CEST 2002 What changed from my (really) old (pre gcc_3.1) current? Riccardo. PS: world and ports compiled with some 'insane' options (-O2): CPUTYPE=p3 CFLAGS= -O2 -pipe NOPROFILE= true COMPAT3X= yes COMPAT4X= yes To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/kern kern_sig.c (fwd)
On Tue, Aug 13, 2002 at 06:14:38AM -0700, David Xu wrote: > --- Terry Lambert <[EMAIL PROTECTED]> wrote: > > I did. It's still an order of operation problem in the kernel > > during fork(), as Bruce pointed out in a later posting (so me > > pointing it out here is probably redundant... 8-)). > > > > I still think other code is going to have the problem, too, so > > changing su alone doesn't fix things. Better to not deliver > > the tty output stopped signal. > > > > -- Terry > > Don't touch tty code, if you change, you'll break more code, > current problem is just because su forks a child process and > want to take over some job control work from shell, it is of > course not a easy job. the problem does not exist in STABLE > branch because su does not fork. What about chpass, vipw, and the other pw_edit() consumers? vipw works correctly wrt suspending with ^Z on 4.6-RELEASE, but does not on -CURRENT. As far as I can see, pw_edit()'s logic has not been changed. This is a slightly different case to that of the shell suspending _itself_, but I think it's similar enough that the solution may be the same. Tim To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/kern kern_sig.c (fwd)
--- Terry Lambert <[EMAIL PROTECTED]> wrote: > I did. It's still an order of operation problem in the kernel > during fork(), as Bruce pointed out in a later posting (so me > pointing it out here is probably redundant... 8-)). > > I still think other code is going to have the problem, too, so > changing su alone doesn't fix things. Better to not deliver > the tty output stopped signal. > > -- Terry Don't touch tty code, if you change, you'll break more code, current problem is just because su forks a child process and want to take over some job control work from shell, it is of course not a easy job. the problem does not exist in STABLE branch because su does not fork. David Xu __ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/kern kern_sig.c (fwd)
On Mon, Aug 12, 2002 at 17:10:47 -0700, Terry Lambert wrote: > > I don't unserstand the question. Why not the same license that's > areleady on the source code for "su"? See usr.bin/su.c header for license. > I still think other code is going to have the problem, too, so > changing su alone doesn't fix things. Better to not deliver > the tty output stopped signal. It is traditional BSD way of stop/cont handling, unchanged starting from very early times. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/kern kern_sig.c (fwd)
"Andrey A. Chernov" wrote: > > UGH! > > > > #1License on patch is GPL > > Why not Microsoft? I don't unserstand the question. Why not the same license that's areleady on the source code for "su"? > > #2I guess now that this irritant is gone, the signals code > > will remain screwed up, until some time later when you > > see the shark fin above water, just before it bites > > someone else? > > Read commit message 2 or 3 times. Meditate on each word. I did. It's still an order of operation problem in the kernel during fork(), as Bruce pointed out in a later posting (so me pointing it out here is probably redundant... 8-)). I still think other code is going to have the problem, too, so changing su alone doesn't fix things. Better to not deliver the tty output stopped signal. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/kern kern_sig.c (fwd)
On Tue, Aug 13, 2002 at 04:58:17 +1000, Bruce Evans wrote: > > Explanation of this patch: Thanx. Could you please commit this explanation, or some re-phrasing of it into su.c? -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/kern kern_sig.c (fwd)
On Mon, Aug 12, 2002 at 09:21:31PM +0400, Andrey A. Chernov wrote: > On Tue, Aug 13, 2002 at 03:15:02 +1000, Bruce Evans wrote: > > > > Anyway, it has one blatant style bug (not 1TBS) and no explanation of > > the bug, so it should not have been committed verbatim. See another > > reply for an analysis of the patch. > > According to commit guide, explanations are not commited, only what is > changed. For explanation (terminal group mismatch) read whole thread, > especially David's analysis. Wrong Andrey. For hairy code, there should be comments -- especially if one must realize someone obtuse to understand how the code works. 6mo. from now no one will be able to find the explanation in a mailing list. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/kern kern_sig.c (fwd)
On Mon, 12 Aug 2002, Andrey A. Chernov wrote: > On Tue, Aug 13, 2002 at 03:15:02 +1000, Bruce Evans wrote: > > > > Anyway, it has one blatant style bug (not 1TBS) and no explanation of > > the bug, so it should not have been committed verbatim. See another > > reply for an analysis of the patch. > > According to commit guide, explanations are not commited, only what is > changed. For explanation (terminal group mismatch) read whole thread, > especially David's analysis. The analysis in the thread seems to be incomplete. > What another reply you mean? I just wrote one :-). Rereading earlier analysis just gave me a hint about tcsetpgrp() to the same value causes problems: it causes an unexpected SIGTTOU because a background process attemps to do something (TIOCSPGRP) that can only be done in the foreground (the background process is forced to wait until it gets to the foreground, and it doesn't help for the change to be null since the process must be in the foreground to even check for null changes). Presumably the child su is in the foreground at that point. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/kern kern_sig.c (fwd)
On Sun, 11 Aug 2002, David Xu wrote:
> following is patch for su, I can type "suspend" and stop $$ without the
> problem you described, I have tested it under tcsh and bash, all works
> for me.
>
> --- su.c Mon Aug 12 13:08:01 2002
> +++ su.c.new Mon Aug 12 13:16:14 2002
> @@ -329,10 +329,13 @@
> default:
> while ((ret_pid = waitpid(child_pid, &statusp, WUNTRACED)) != -1) {
> if (WIFSTOPPED(statusp)) {
> - child_pgrp = tcgetpgrp(1);
> kill(getpid(), SIGSTOP);
> - tcsetpgrp(1, child_pgrp);
> - kill(child_pid, SIGCONT);
> + child_pgrp = getpgid(child_pid);
> + if (tcgetpgrp(1) == getpgrp())
> + {
> + tcsetpgrp(1, child_pgrp);
> + kill(child_pid, SIGCONT);
> + }
> statusp = 1;
> continue;
> }
Explanation of this patch:
(1) su has shot itself in the foot using PAM. Normally the parent shell
waits for children and handles them when they stop. The extra process
for PAM is now in between the parent shell and the su shell, so the
parent shell can't do this directly. The above code attempts to
relay some aspects of job control back to the parent shell. It is
not clear that it can do this properly without duplicating lots of
shell specific job control, but I think it can do this in principle.
There are related problems for propagation of SIGHUP to indirect
descendants of login shells when the shell exits. Here there is
at least there is an intermediate process that can relay the signals
if necessary. I think propagation of SIGHUP is automatic if the
intermediate process doesn't exit first and it doesn't change its
job control stuff too much, so the SIGHUP problem doesn't affect
PAMmed applications.
(2) To relay SIGSTOP, the intermediate su just needs stop itself. To
relay SIGCONT, the intermediate su needs to switch to enough of
its child's job control environment before starting the child.
Switching only fd 1's process group seems to be sufficient, but
it is not easy to determine even that and the broken version got
it wrong.
The child's environment is very shell-dependent. Some of the following
may depend on the initial shell being bash:
(a) sh, csh and bash start a new process group (equal to their pid).
zsh stays in the process group of the intermediate su process.
(b) "kill -STOP $$ ... fg" worked in most (all?) cases because
fd 1's pgrp is still the child's pgid when the child is killed
in that way. For zsh the child's pgid is the same as the
intermediate shell's so the pgrps can't be different, and for
the other shells I think the pgrp hasn't been changed because
the child can'tcontrol it (SIGSTOP is uncatchable) and the
kernel doesn't. Later, switching fd 1's pgrp back to the
child's pgid works except possbly for zsh because it is correct
and different.
(c) "suspend ... fg" failed for several reasons. First, something
(presumably the child) sets fd 1's pgrp to the intermediate
su's pgid, so tcgetpgrp(1) gives a wrong pgrp for restoring
later. The patch fixes this by not getting the pgrp in this
way. It uses getpgid(child_pid) instead. I think this works
for at least normal shells. Second when the pgrp is restored,
something (presumably the shell above the intermediate su, or
the kernel) has already switched fd 1's pgrp to child's pgid
instead of to the intermediate su's pgid (despite the intermediate
su's being correct at SIGSTOP time for suspend but not for
kill -STOP). Setting fd 1's pgrp to the value that it alread
has is then fatal for reasons that I don't completely understand
yet. The patch avoids the problem by not doing apparently-null
tcsetpgrp()'s. Sending the SIGCONT seems to have no affect in
this case, so I think shell above the su's has already started
both the child su and the intermediate one and this isn't a
problem until the su's get in each other's way. Putting printfs
in the above code seems to make the problem easier to debug by
ensuring that they get in each other's way :-).
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/kern kern_sig.c (fwd)
On Tue, Aug 13, 2002 at 03:15:02 +1000, Bruce Evans wrote: > > Anyway, it has one blatant style bug (not 1TBS) and no explanation of > the bug, so it should not have been committed verbatim. See another > reply for an analysis of the patch. According to commit guide, explanations are not commited, only what is changed. For explanation (terminal group mismatch) read whole thread, especially David's analysis. What another reply you mean? -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/kern kern_sig.c (fwd)
On Mon, 12 Aug 2002, Andrey A. Chernov wrote: > On Mon, Aug 12, 2002 at 04:03:31 -0700, Terry Lambert wrote: > > "Andrey A. Chernov" wrote: > > > On Sun, Aug 11, 2002 at 22:53:15 -0700, David Xu wrote: > > > > following is patch for su, I can type "suspend" and stop $$ without the > > > > problem you described, I have tested it under tcsh and bash, all works > > > > for me. > > > > > > Thanx, committed. > > > > UGH! > > > > #1 License on patch is GPL > > Why not Microsoft? > > > #2 I guess now that this irritant is gone, the signals code > > will remain screwed up, until some time later when you > > see the shark fin above water, just before it bites > > someone else? > > Read commit message 2 or 3 times. Meditate on each word. Anyway, it has one blatant style bug (not 1TBS) and no explanation of the bug, so it should not have been committed verbatim. See another reply for an analysis of the patch. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/kern kern_sig.c (fwd)
On Mon, Aug 12, 2002 at 04:03:31 -0700, Terry Lambert wrote: > "Andrey A. Chernov" wrote: > > On Sun, Aug 11, 2002 at 22:53:15 -0700, David Xu wrote: > > > following is patch for su, I can type "suspend" and stop $$ without the > > > problem you described, I have tested it under tcsh and bash, all works > > > for me. > > > > Thanx, committed. > > UGH! > > #1License on patch is GPL Why not Microsoft? > #2I guess now that this irritant is gone, the signals code > will remain screwed up, until some time later when you > see the shark fin above water, just before it bites > someone else? > Read commit message 2 or 3 times. Meditate on each word. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/kern kern_sig.c (fwd)
"Andrey A. Chernov" wrote: > On Sun, Aug 11, 2002 at 22:53:15 -0700, David Xu wrote: > > following is patch for su, I can type "suspend" and stop $$ without the > > problem you described, I have tested it under tcsh and bash, all works > > for me. > > Thanx, committed. UGH! #1 License on patch is GPL #2 I guess now that this irritant is gone, the signals code will remain screwed up, until some time later when you see the shark fin above water, just before it bites someone else? Saying "Don't walk there" doesn't dig up and disarm the landmine. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/kern kern_sig.c (fwd)
Tim Robbins wrote: > I compiled GNU sh-utils 1.16 with Redhat's PAM patch on -current. It works > well and does not seem to have the bugs w/ csh's suspend or kill -STOP $$ > that I complained about earlier. > > This means that either our su is broken, or the different way Redhat > has implemented it is managing to avoid a kernel bug of ours. Obviously it's different, if it behaves differently. The issue is whether or not a kernel change in signal handling means that the su code that has been in FreeBSD for many years is now "magically" no longer the right way to do things. The effects not only the su code itself, but any code out there that anyone has written, which is either derived from the old su code, or modelled on the way the old code has done things. It's all well and good to work around a kernel bug by changing user space code, but working around it by changing the user space code *hardly* fixes the underlying bug, which will just sit there waiting to bite the next poor unsuspecting slob on the arse. > The key differences with our implementation seem to be that they block > all allowed signals except SIGALRM and SIGTERM with sigprocmask() after the > fork on the parent side (race?), and they don't mess around with > tc[gs]etpgrp(). It should not be required that you do this. It's pretty obvious what is happening, if blocking the signals works around the problem: signal delivery requires a stall barrier until after the fork inheritance has been cleaned up. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/kern kern_sig.c (fwd)
On Sun, Aug 11, 2002 at 22:53:15 -0700, David Xu wrote: > following is patch for su, I can type "suspend" and stop $$ without the > problem you described, I have tested it under tcsh and bash, all works > for me. > Thanx, committed. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/kern kern_sig.c (fwd)
On Sun, Aug 11, 2002 at 06:54:42PM -0700, Julian Elischer wrote:
> I am forwarding this to -current as I think it needs more neurons on it..
> I am presently unable to spend any due to work commitments, and due to a sort-of
> personal confusion about tis stuff anyhow..
>
>
> David Xu wrote:
> >
> > does anyone believe that su behaviours correctly?
> > we are talking that kernel has bug to handle job control
> > but I found that the issue may not related to signal handling
> > problem, but related to su or csh's job control.
> > I see this piece of code in su.c:
> >
> > switch (child_pid) {
> > default:
> > while ((ret_pid = waitpid(child_pid, &statusp, WUNTRACED)) !=
>eca-1) {
> > if (WIFSTOPPED(statusp)) {
> > child_pgrp = tcgetpgrp(1);
> > kill(getpid(), SIGSTOP);
> > tcsetpgrp(1, child_pgrp);
> > kill(child_pid, SIGCONT);
> > statusp = 1;
> > continue;
> > }
> > break;
> > }
> >
> > I have traced down su. In my test, the su process forked a
> > child process, child process pid is 873 while parent pid is 872.
> > these code are in question, I found that tcgetpgrp(1) really
> > returns parent su pid, it is 872, parent su process
> > then suspends itself until login shell unsuspends it,
> > when it resumes, I have inserted another tcgetpgrp(1) after it resumes,
> > and found that it was 873, it was child su process pid! not 872,
> > because parent su was not in foreground group, when it called tcsetpgrp(1, 872),
> > it got a SIGTTOU and suspended there, the SIGCONT was not sent out.
> > so the code's behaviour is not what the author's want, and all job
> > control gets weird. I suguest this job control assumption should be removed,
> > strange thing is why su calls fork()? why doesn't call directly execvl()?
> > I don't see su calls fork() in OpenBSD.
I compiled GNU sh-utils 1.16 with Redhat's PAM patch on -current. It works
well and does not seem to have the bugs w/ csh's suspend or kill -STOP $$
that I complained about earlier.
This means that either our su is broken, or the different way Redhat
has implemented it is managing to avoid a kernel bug of ours.
I've extracted Redhat's patch from the RPM to make it easier to get:
http://people.freebsd.org/~tjr/sh-utils-1.16-pam.patch
The patch applies cleanly to sh-utils-1.16 (find it on a GNU mirror),
and su gets built - the build process dies at `test'.
The key differences with our implementation seem to be that they block
all allowed signals except SIGALRM and SIGTERM with sigprocmask() after the
fork on the parent side (race?), and they don't mess around with
tc[gs]etpgrp().
Tim
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/kern kern_sig.c (fwd)
David Xu wrote: > following is patch for su, I can type "suspend" and stop $$ without the > problem you described, I have tested it under tcsh and bash, all works > for me. [ ... ] Looks like a patch to a user space program to deal with POSIX non-compliance of the host OS. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/kern kern_sig.c (fwd)
--- David Xu <[EMAIL PROTECTED]> wrote:
>
> --- "Andrey A. Chernov" <[EMAIL PROTECTED]> wrote:
> > On Sun, Aug 11, 2002 at 17:41:20 +0400, Andrey A. Chernov wrote:
> > > On Sun, Aug 11, 2002 at 06:28:54 -0700, David Xu wrote:
> > > > does anyone believe that su behaviours correctly?
> > >
> > > I not believe in that first, so why I remove tcsetpgrg() in my initial
> > > commit. It fix suspend/fg, but break stop $$/fg those times. I not test,
> > > is it break stop $$/fg now too (I'll do it a bit later and send result).
> > > fork/wait seems to be needed here just for PAM_END.
> >
> > Yes, still there. If tcsetpgrp() removed, suspend/fg fixed, but "stop
> > $$/fg" kills login shell. It means that neither variant is correct, unless
> > there is a kernel bug. To be 100% sure, we need to test su with old
> > -current kernel without KSE. Anybody have that thing? I can cvsup early
> > kernel sources and build from them, but I don't know exact KSE changes
> > data. Other way is to build su statically and test on -stable. I don't
> > have any -stable machines around.
> >
> > --
> > Andrey A. Chernov
> > http://ache.pp.ru/
>
> Sorry, Andrey, current su's job control mode does not work under STABLE too,
> I have tested, it has same result as under CURRENT. the following piece of
> code does not work under STABLE, it mimics what su is doing in CURRENT
> source tree.
>
> #include
> #include
> #include
> #include
> #include
> #include
>
> int main()
> {
> pid_t ret_pid, statusp, child_pid, child_pgrp;
> struct sigaction sa, sa_int, sa_quit, sa_tstp;
> char buf[64];
> char* sargv[3];
>
> sa.sa_flags = SA_RESTART;
> sa.__sigaction_u.__sa_handler = SIG_IGN;
> sigemptyset(&sa.sa_mask);
> sigaction(SIGINT, &sa, &sa_int);
> sigaction(SIGQUIT, &sa, &sa_quit);
> sigaction(SIGTSTP, &sa, &sa_tstp);
>
> child_pid = fork();
> switch (child_pid) {
> default:
> while ((ret_pid = waitpid(child_pid, &statusp, WUNTRACED)) != -1) {
> if (WIFSTOPPED(statusp)) {
> child_pgrp = tcgetpgrp(1);
> kill(getpid(), SIGSTOP);
> tcsetpgrp(1, child_pgrp);
> kill(child_pid, SIGCONT);
> statusp = 1;
> continue;
> }
> break;
> }
> if (ret_pid == -1)
> err(1, "waitpid");
> exit(statusp);
> case -1:
> err(1, "fork");
> exit(1);
> case 0:
> sigaction(SIGINT, &sa_int, NULL);
> sigaction(SIGQUIT, &sa_quit, NULL);
> sigaction(SIGTSTP, &sa_tstp, NULL);
> sargv[0] = "csh";
> sargv[1] = NULL;
> execv("/bin/csh", sargv);
> printf("hi, there!\n");
> break;
> }
> return 0;
> }
>
following is patch for su, I can type "suspend" and stop $$ without the
problem you described, I have tested it under tcsh and bash, all works
for me.
--- su.cMon Aug 12 13:08:01 2002
+++ su.c.newMon Aug 12 13:16:14 2002
@@ -329,10 +329,13 @@
default:
while ((ret_pid = waitpid(child_pid, &statusp, WUNTRACED)) != -1) {
if (WIFSTOPPED(statusp)) {
- child_pgrp = tcgetpgrp(1);
kill(getpid(), SIGSTOP);
- tcsetpgrp(1, child_pgrp);
- kill(child_pid, SIGCONT);
+ child_pgrp = getpgid(child_pid);
+ if (tcgetpgrp(1) == getpgrp())
+ {
+ tcsetpgrp(1, child_pgrp);
+ kill(child_pid, SIGCONT);
+ }
statusp = 1;
continue;
}
__
Do You Yahoo!?
HotJobs - Search Thousands of New Jobs
http://www.hotjobs.com
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/kern kern_sig.c (fwd)
--- "Andrey A. Chernov" <[EMAIL PROTECTED]> wrote:
> On Sun, Aug 11, 2002 at 17:41:20 +0400, Andrey A. Chernov wrote:
> > On Sun, Aug 11, 2002 at 06:28:54 -0700, David Xu wrote:
> > > does anyone believe that su behaviours correctly?
> >
> > I not believe in that first, so why I remove tcsetpgrg() in my initial
> > commit. It fix suspend/fg, but break stop $$/fg those times. I not test,
> > is it break stop $$/fg now too (I'll do it a bit later and send result).
> > fork/wait seems to be needed here just for PAM_END.
>
> Yes, still there. If tcsetpgrp() removed, suspend/fg fixed, but "stop
> $$/fg" kills login shell. It means that neither variant is correct, unless
> there is a kernel bug. To be 100% sure, we need to test su with old
> -current kernel without KSE. Anybody have that thing? I can cvsup early
> kernel sources and build from them, but I don't know exact KSE changes
> data. Other way is to build su statically and test on -stable. I don't
> have any -stable machines around.
>
> --
> Andrey A. Chernov
> http://ache.pp.ru/
Sorry, Andrey, current su's job control mode does not work under STABLE too,
I have tested, it has same result as under CURRENT. the following piece of
code does not work under STABLE, it mimics what su is doing in CURRENT
source tree.
#include
#include
#include
#include
#include
#include
int main()
{
pid_t ret_pid, statusp, child_pid, child_pgrp;
struct sigaction sa, sa_int, sa_quit, sa_tstp;
char buf[64];
char* sargv[3];
sa.sa_flags = SA_RESTART;
sa.__sigaction_u.__sa_handler = SIG_IGN;
sigemptyset(&sa.sa_mask);
sigaction(SIGINT, &sa, &sa_int);
sigaction(SIGQUIT, &sa, &sa_quit);
sigaction(SIGTSTP, &sa, &sa_tstp);
child_pid = fork();
switch (child_pid) {
default:
while ((ret_pid = waitpid(child_pid, &statusp, WUNTRACED)) != -1) {
if (WIFSTOPPED(statusp)) {
child_pgrp = tcgetpgrp(1);
kill(getpid(), SIGSTOP);
tcsetpgrp(1, child_pgrp);
kill(child_pid, SIGCONT);
statusp = 1;
continue;
}
break;
}
if (ret_pid == -1)
err(1, "waitpid");
exit(statusp);
case -1:
err(1, "fork");
exit(1);
case 0:
sigaction(SIGINT, &sa_int, NULL);
sigaction(SIGQUIT, &sa_quit, NULL);
sigaction(SIGTSTP, &sa_tstp, NULL);
sargv[0] = "csh";
sargv[1] = NULL;
execv("/bin/csh", sargv);
printf("hi, there!\n");
break;
}
return 0;
}
David
__
Do You Yahoo!?
HotJobs - Search Thousands of New Jobs
http://www.hotjobs.com
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/kern kern_sig.c (fwd)
> David Xu wrote: > > want, and all job control gets weird. I suguest this job control > > assumption should be removed, strange thing is why su calls fork()? > > why doesn't call directly execvl()? I don't see su calls fork() in > > OpenBSD. This has to do with PAM, AFAIK. Someone has to call PAM session cleanup hooks, that's why another process for the command is forked. -- Alexander Kabaev To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/kern kern_sig.c (fwd)
I am forwarding this to -current as I think it needs more neurons on it..
I am presently unable to spend any due to work commitments, and due to a sort-of
personal confusion about tis stuff anyhow..
David Xu wrote:
>
> does anyone believe that su behaviours correctly?
> we are talking that kernel has bug to handle job control
> but I found that the issue may not related to signal handling
> problem, but related to su or csh's job control.
> I see this piece of code in su.c:
>
> switch (child_pid) {
> default:
> while ((ret_pid = waitpid(child_pid, &statusp, WUNTRACED)) != eca-1)
>{
> if (WIFSTOPPED(statusp)) {
> child_pgrp = tcgetpgrp(1);
> kill(getpid(), SIGSTOP);
> tcsetpgrp(1, child_pgrp);
> kill(child_pid, SIGCONT);
> statusp = 1;
> continue;
> }
> break;
> }
>
> I have traced down su. In my test, the su process forked a
> child process, child process pid is 873 while parent pid is 872.
> these code are in question, I found that tcgetpgrp(1) really
> returns parent su pid, it is 872, parent su process
> then suspends itself until login shell unsuspends it,
> when it resumes, I have inserted another tcgetpgrp(1) after it resumes,
> and found that it was 873, it was child su process pid! not 872,
> because parent su was not in foreground group, when it called tcsetpgrp(1, 872),
> it got a SIGTTOU and suspended there, the SIGCONT was not sent out.
> so the code's behaviour is not what the author's want, and all job
> control gets weird. I suguest this job control assumption should be removed,
> strange thing is why su calls fork()? why doesn't call directly execvl()?
> I don't see su calls fork() in OpenBSD.
>
> --- "Andrey A. Chernov" <[EMAIL PROTECTED]> wrote:
> > On Sat, Aug 10, 2002 at 13:36:32 +0400, Andrey A. Chernov wrote:
> > > On Fri, Aug 09, 2002 at 18:23:05 -0700, Julian Elischer wrote:
> > > >
> > > > Andrey.. we need you to also ktrace the child as well..
> > > > (together with the su) use ktrace -d -i {YOURSHELL}
> > > > to capture everything...
> > > >
> > >
> > > Here it is (starting from the moment, when su exec'ed)
> >
> > I notice that no 'su' section here, it because that su have s-bit and not
> > traced. I try to do the same thing from root and get very strange
> > behaviour, summarized in the following table:
> >
> > -
> > root login csh> su
> > suspend
> > fg
> > (got bug)
> > -
> > root login csh> ktrace -d -i /bin/csh
> > su
> > suspend
> > fg
> > (NO BUG)
> > -
> > user login csh> su
> > suspend
> > fg
> > (got bug)
> > -
> > user login csh> ktrace -d -i /bin/csh
> > su
> > suspend
> > fg
> > (got bug)
> >
> > It means I can't ktrace _both_ csh and su in the same time, since bug
> > dissapearse just for that variant.
> >
> > --
> > Andrey A. Chernov
> > http://ache.pp.ru/
>
> __
> Do You Yahoo!?
> HotJobs - Search Thousands of New Jobs
> http://www.hotjobs.com
--
++ __ _ __
| __--_|\ Julian Elischer | \ U \/ / hard at work in
| / \ [EMAIL PROTECTED] +-->x USA\ a very strange
| ( OZ)\___ ___ | country !
+- X_.---._/presently in San Francisco \_/ \\
v
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
