Bug 1183194 - Bash history from sessions running at shutdown/reboot sometimes lost
Summary: Bash history from sessions running at shutdown/reboot sometimes lost
Keywords:
Status: CLOSED DUPLICATE of bug 1170765
Alias: None
Product: Fedora
Classification: Fedora
Component: systemd
Version: rawhide
Hardware: x86_64
OS: All
unspecified
medium
Target Milestone: ---
Assignee: systemd-maint
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-01-17 00:46 UTC by Adam Williamson (Fedora)
Modified: 2015-07-29 12:39 UTC (History)
19 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-02-18 19:15:36 UTC
Type: Bug


Attachments (Terms of Use)

Description Adam Williamson (Fedora) 2015-01-17 00:46:20 UTC
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.

Comment 1 Michael Chapman 2015-01-17 03:29:39 UTC
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.

Comment 2 Dusty Mabe 2015-02-16 19:26:23 UTC
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.

Comment 3 Michael Chapman 2015-02-17 13:26:34 UTC
Bug 1141137 is even older, and it's about the same problem as well. :-)

Comment 4 Adam Williamson 2015-02-18 19:15:11 UTC
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).

Comment 5 Adam Williamson 2015-02-18 19:15:36 UTC

*** This bug has been marked as a duplicate of bug 1170765 ***


Note You need to log in before you can comment on or make changes to this bug.