To reproduce: 1. Install a clean Fedora 21 2. Open a terminal, open two tabs, 'su' in one 3. Run 'test01' in one terminal, 'test02' in the other 4. Reboot (by running 'reboot' in either terminal or using the GNOME 'Restart' button, it doesn't seem to matter) 5. Open a terminal, check history for both user and root and see if you see 'test01' and 'test02' 6. Open two tabs, su in one, run 'test03' in one, 'test04' in the other 7. GOTO 4 (at step 5 check for 'test03' and 'test04', obviously) Loop as much as you like. Quite often, the history from one or both of the sessions running at reboot time is lost. I ran through six iterations of the test in an F20 install and didn't lose the history from either session one time. elad confirmed this on IRC, and in one case, he found the bash history file was completely wiped; we theorized that bash's code for writing the file isn't safe and if you get particularly unlucky with the timing this can happen, but we didn't check. My guess is this may be another bug caused by https://bugzilla.redhat.com/show_bug.cgi?id=1141137 , but I thought I'd file it separately to start with just in case. The time frame seems to work; I recall starting to notice this last year, and systemd 209 did come out just after F20 was released, so it makes sense that it affects 21 but not 20.
I had raised this upstream a little while back: http://lists.freedesktop.org/archives/systemd-devel/2014-November/025544.html . Didn't get any traction on it though. I'm pretty sure it affects all scope units (which logind sessions are). It's easy enough to demonstrate: $ systemd-run --user --scope /usr/bin/perl -e '$SIG{TERM} = sub { print "SIGTERM\n" }; sleep' Running as unit run-5205.scope. Then in another terminal do "systemctl --user stop run-5205.scope". It should print out "SIGTERM", since that's being handled by the inner command. Instead it's simply SIGKILLed immediately.
Unless someone has a good reason not to I'll add some pertinent information from this BZ to 1170765 and then close this as a dup of 1170765 since it was opened a month prior.
Bug 1141137 is even older, and it's about the same problem as well. :-)
Michael: I did explicitly mention that one, and explain why I was opening a new bug, in the initial comment. It seems reasonable to guess that that bug is the cause of this one, but it's not entirely proven yet. There are also possibilities for fixing this particular case outside of systemd, by making bash store its history on every command or whatever (there's some discussion of this in bash upstream).
*** This bug has been marked as a duplicate of bug 1170765 ***