Bug 1183194

Summary:	Bash history from sessions running at shutdown/reboot sometimes lost
Product:	[Fedora] Fedora	Reporter:	DO NOT USE account not monitored (old adamwill) <adamw+fedora>
Component:	systemd	Assignee:	systemd-maint
Status:	CLOSED DUPLICATE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	rawhide	CC:	awilliam, bugzilla.redhat.com, dustymabe, elad, johannbg, jsynacek, kparal, lnykryn, mrmazda, msekleta, myroslav, ooprala, ppisar, redhat-bugzilla, rhughes, s, systemd-maint, vpavlin, zbyszek
Target Milestone:	---
Target Release:	---
Hardware:	x86_64
OS:	All
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2015-02-18 19:15:36 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description DO NOT USE account not monitored (old adamwill) 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 ***