https://bugzilla.novell.com/show_bug.cgi?id=652633 https://bugzilla.novell.com/show_bug.cgi?id=652633#c2 Kay Sievers changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kasievers@novell.com AssignedTo|kasievers@novell.com |kukuk@novell.com Summary|systemd: shutdown doesn't |login: killing login does |properly kill shell |not properly kill forked | |child/shell --- Comment #2 from Kay Sievers 2011-02-15 23:55:36 UTC --- It actually is SUSE-only. Sorry. We send SIGTERM to login and login terminates, but the shell stays around and gets re-parented to pid 1. The login from util-linux does kill the forked child when it is killed itself. It actually needs to send SIGHUP to the shell when it gets SIGTERM, or just use the login from util-linux like Fedora. Here is the signal handler from util-linux's login: http://git.kernel.org/?p=utils/util-linux/util-linux.git;a=blob;f=login-util... Thanks! -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=652633 https://bugzilla.novell.com/show_bug.cgi?id=652633#c4 Dr. Werner Fink changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |NEEDINFO CC| |werner@novell.com InfoProvider| |kasievers@novell.com --- Comment #4 from Dr. Werner Fink 2011-02-16 08:47:12 UTC --- Hmmm ... AFAICS from source of util-linux-2.19-rc1 from factory the signal handler at http://git.kernel.org/ is identical with those of util-linux-2.19-rc1 static void sig_handler(int signal) { if(child_pid) kill(-child_pid, signal); else got_sig = 1; if(signal == SIGTERM) kill(-child_pid, SIGHUP); /* because the shell often ignores SIGTERM */ } .. and AFAICR this does not happen with sysvinit. The question rises: is it possible for the shell to save its history. Or do you have an strace around to see if the signals will reach the shell in the correct order (SIGTERM, SIGHUP) and the shell has the possiblity and enough time to save its history to disk *before* the final SIGKILL and umounting the file system. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=652633 https://bugzilla.novell.com/show_bug.cgi?id=652633#c6 --- Comment #6 from Jiri Slaby 2011-02-16 09:19:19 UTC --- (In reply to comment #5)

And only TERM is printed. Then KILL probably happens. How fast do you send KILL after TERM in systemd?

Oh, got it. 'kill -TERM' does nothing to bash. Only 'kill -HUP' shuts it down gracefully... -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=652633 https://bugzilla.novell.com/show_bug.cgi?id=652633#c8 --- Comment #8 from Dr. Werner Fink 2011-02-16 09:55:41 UTC --- AFAIK the bash will ignore the signal with trap on SIGHUP ... nevertheless as sysvinit stops all processes (e.g. mingetty and login) before switching to runlevel 0, 1, and 6 the shells on the consoles will be exit before the system will shutdown or reboot (compare with /etc/inittab). This is shown by sysvinit by the well known lines: Sending processes the TERM signal Sending processes the KILL signal before executing the scripts for runlevel 0, 1, or 6. This holds true for every runlevel switch, that is all process within the process group 1 not part of the next runlevel will be terminated and if this does not help simply killed *before* entering the next runlevel. I'm wondering why the signal USR2 is send to the bash, this will cause the shell to exit without a trap. You may try out if a simple trap on USR2 may help to save the history. Btw: What does the command reboot do on systemd based systems? On sysvinit the similar command tells the init process to switch from current level to runlevel 6 (`reboot' == `shutdown -r now'). -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=652633 https://bugzilla.novell.com/show_bug.cgi?id=652633#c10 --- Comment #10 from Dr. Werner Fink 2011-02-16 10:15:24 UTC --- (In reply to comment #9)

I don't understand this...

You may try out trap 'history -a' SIGURS2 to see if this does help. Beside this: what does test -w $HISTFILE || echo $HISTFILE not writable show? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=652633 https://bugzilla.novell.com/show_bug.cgi?id=652633#c12 --- Comment #12 from Jiri Slaby 2011-02-16 10:56:10 UTC --- (In reply to comment #10)

trap 'history -a' SIGURS2

This makes no difference.

to see if this does help. Beside this: what does

test -w $HISTFILE || echo $HISTFILE not writable

show?

Nothing... -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=652633 https://bugzilla.novell.com/show_bug.cgi?id=652633#c14 --- Comment #14 from Dr. Werner Fink 2011-02-16 11:23:29 UTC --- Just submitted a pam-login with added signal handler to forward SIGTERM as well as SIGHUP to the shell, see request id 61439. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=652633 https://bugzilla.novell.com/show_bug.cgi?id=652633#c16 Dr. Werner Fink changed: What |Removed |Added ---------------------------------------------------------------------------- InfoProvider|lnussel@novell.com |jslaby@novell.com --- Comment #16 from Dr. Werner Fink 2011-02-16 11:26:59 UTC --- Jiri? Could you give this new version of pam login a try? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=652633 https://bugzilla.novell.com/show_bug.cgi?id=652633#c18 Thorsten Kukuk changed: What |Removed |Added ---------------------------------------------------------------------------- InfoProvider|jslaby@novell.com |kasievers@novell.com --- Comment #18 from Thorsten Kukuk 2011-02-16 12:14:30 UTC --- Kay, why should the new signal handler be correct? login explicit creates a new session for the child so that the signals will not be forwarded. Now we do everything to make that useless. Some expectations are wrong here. And with the people I spoke now, everyboday says that login should NOT forward that signals. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=652633 https://bugzilla.novell.com/show_bug.cgi?id=652633#c20 --- Comment #20 from Dr. Werner Fink 2011-02-16 12:33:42 UTC --- Created an attachment (id=414401) --> (http://bugzilla.novell.com/attachment.cgi?id=414401) bnc652633.patch My patch only works upto the point where sigset() is called, nothing more and nothing less. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=652633 https://bugzilla.novell.com/show_bug.cgi?id=652633#c22 --- Comment #22 from Thorsten Kukuk 2011-02-16 12:38:34 UTC --- (In reply to comment #19)

If "login" is killed, it should kill its child, easy at that.

Why should it? Please come with real arguments, not only because you think it should so. login, especially the one from util-linux, did create a new session so that this does not happen.

Yeah, just use the login from util-linux, and forget about everything. :)

Only because it got a patch with matches with what you like? That it is from util-linux does not mean it is correct ... Looking at the login sources of BSD and other: nobody is forwarding the signal and killing the shell. The only implemenation I found is the one from util-linux ... -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=652633 https://bugzilla.novell.com/show_bug.cgi?id=652633#c24 Kay Sievers changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |NEW InfoProvider|kasievers@novell.com | --- Comment #24 from Kay Sievers 2011-02-16 12:44:07 UTC --- (In reply to comment #22)

(In reply to comment #19)

...

If "login" is killed, it should kill its child, easy at that.

Why should it? Please come with real arguments, not only because you think it should so. login, especially the one from util-linux, did create a new session so that this does not happen.

It does here. How about trying it?

...

Yeah, just use the login from util-linux, and forget about everything. :)

Only because it got a patch with matches with what you like? That it is from util-linux does not mean it is correct ...

Looking at the login sources of BSD and other: nobody is forwarding the signal and killing the shell. The only implemenation I found is the one from util-linux ...

Sure, and that's what makes the most sense to me. I guess, instead you should justify what's the gain for SUSE not to use the maintained version in util-linux like others, but maintain their own code instead. And also what's so nice about leaving and orphaned bash hanging around. :) -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=652633 https://bugzilla.novell.com/show_bug.cgi?id=652633#c26 Kay Sievers changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |NEW InfoProvider|lnussel@novell.com | --- Comment #26 from Kay Sievers 2011-02-16 12:48:11 UTC ---

(In reply to comment #19)

There is no lastlog tool found in util-linux which is a major feature of pam-login.

If that's useful and not already covered, please just add it to util-linux instead of a SUSE package. We really should stop playing these games here. At a larger scale, we do nobody a favor with all these SUSE-only patches and packages. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=652633 https://bugzilla.novell.com/show_bug.cgi?id=652633#c29 --- Comment #29 from Dr. Werner Fink 2011-02-16 13:01:22 UTC --- Kay: My question is why is login able to signal a session leader, that is that login is able to send SIGHUP *after* setsid(). -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=652633 https://bugzilla.novell.com/show_bug.cgi?id=652633#c31 --- Comment #31 from Kay Sievers 2011-02-16 13:10:00 UTC --- As mentioned earlier, we usually use: prctl(PR_SET_PDEATHSIG, SIGHUP); for that. Anyway I'm out here now, I have real problems to fix. :) -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=652633 https://bugzilla.novell.com/show_bug.cgi?id=652633#c33 --- Comment #33 from Dr. Werner Fink 2011-02-17 09:08:37 UTC --- Created an attachment (id=414623) --> (http://bugzilla.novell.com/attachment.cgi?id=414623) 0002-Add-vhangup-for-sending-HUP-to-all-procs-on-tty.patch I'd like to know if this patch will work. That is to use vhangup(8) to send SIGHUP to all processes on the tty. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=652633 https://bugzilla.novell.com/show_bug.cgi?id=652633#c35 Kay Sievers changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |NEW CC| |gregkh@novell.com InfoProvider|kasievers@novell.com | --- Comment #35 from Kay Sievers 2011-02-17 13:16:30 UTC --- Yeah, I guess that would work, but this tool seems not available on Fedora, and the systemd goal is to get rid of all the needless differences between the distros here. So we can not do that now. The real fix for this bug is still to let services on service-shutdown take care of cleaning up the stuff they started, and not let orphaned process hanging around until the final cleanup. As it seems generally useful, not only for this issue, to do a cleanup for all ttys, we are currently working with Greg, to get something like TIOCVHANGUP that can be issued to any tty, not only from the controlling one, and we will call that directly from systemd, without the need to fork and steal the tty. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=652633 https://bugzilla.novell.com/show_bug.cgi?id=652633#c40 --- Comment #40 from Dr. Werner Fink 2011-02-17 14:14:12 UTC --- I've submitted this patch to Base:System/systemd -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=652633 https://bugzilla.novell.com/show_bug.cgi?id=652633#c45 --- Comment #45 from Dr. Werner Fink 2011-02-17 14:31:32 UTC --- Beside this would you please respect private mode during discussions! -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=652633 https://bugzilla.novell.com/show_bug.cgi?id=652633#c47 Dr. Werner Fink changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |radmanic@novell.com --- Comment #47 from Dr. Werner Fink 2011-02-18 09:30:50 UTC --- (In reply to comment #46) Then read from my lips: if a comment/question/needinfo was marked as private you may not cite such comments nor answer to such comments in public mode. Beside this I'll nor accept that our crown jewels will thrown away as this will cause a lot of regressions at the next SLES. E.g. support of e.g. Japanese names at login. If required I'll escalate to get a decision from product management. http://rudin.suse.de:8888/show_bug.cgi?id=49520 http://rudin.suse.de:8888/show_bug.cgi?id=52367 -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.