Bug 766877

Summary:	systemd cgroups vs. yum update openssh kills previous sshd connections & prior children
Product:	[Fedora] Fedora	Reporter:	Frank Ch. Eigler <fche>
Component:	systemd	Assignee:	systemd-maint
Status:	CLOSED CURRENTRELEASE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	16	CC:	johannbg, lpoetter, metherid, mschmidt, notting, plautrba, systemd-maint
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2011-12-13 16:17:13 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

Description Frank Ch. Eigler 2011-12-12 18:21:03 UTC

Description of problem:
systemd conspires to kill old processes from detached openssh sessions
just because of a yum update / service restart.

Version-Release number of selected component (if applicable):
systemd-36-3.fc16.x86_64
systemd-37-3.fc16.x86_64
openssh-5.8p2-16.fc16.1.x86_64
openssh-5.8p2-22.fc16.x86_64

(The confusing version situation is because of bug #722625, where
systemd killed ssh and its inferior yum during the update, corrupting stuff.)

How reproducible:
Probably always.

Steps to Reproduce:
1. Log into a machine with ssh.
2. Do important work.  Launch background processes.  Detach.
3. update openssh with yum. Probably it's enough to service restart openssh.
  
Actual results:
Important work & background processes dead.

Expected results:
Not dead.

Additional info:
It would be nice if systemd's helpful (?) cgroup management code could be
overridden, for example in the case of openssh-server, so that prior lawful
processes are not summarily executed for the crime of having been useful too
long.

Comment 1 Michal Schmidt 2011-12-13 14:42:40 UTC

Check if you have pam_systemd called in the PAM config files:
system-auth:-session     optional      pam_systemd.so
password-auth:-session     optional      pam_systemd.so

(see also bug 753160)

Check your UsePAM settings in sshd_config (see bug 757545).

Comment 2 Frank Ch. Eigler 2011-12-13 14:55:53 UTC

Thanks for the suggestions.  On this machine:

[root@super]/etc/pam.d# grep UsePAM /etc/ssh/sshd_config
UsePAM yes

[root@super]/etc/pam.d# grep systemd *                         
fingerprint-auth:-session     optional      pam_systemd.so
fingerprint-auth-ac:-session     optional      pam_systemd.so
password-auth:-session     optional      pam_systemd.so
password-auth-ac:-session     optional      pam_systemd.so
smartcard-auth:-session     optional      pam_systemd.so
smartcard-auth-ac:-session     optional      pam_systemd.so
system-auth:-session     optional      pam_systemd.so
system-auth-ac:-session     optional      pam_systemd.so

Comment 3 Michal Schmidt 2011-12-13 15:16:09 UTC

That looks OK. What systemd cgroup is your ssh session running in?:
grep systemd /proc/self/cgroup

Comment 4 Frank Ch. Eigler 2011-12-13 15:35:13 UTC

[10:27:20] % grep systemd /proc/self/cgroup
1:name=systemd:/user/fche/15167

Looking at the timestamps of 
-rw-r--r--. 1 root root 922 Dec 12 12:56 /etc/pam.d/password-auth-ac
-rw-r--r--. 1 root root 922 Dec 12 12:56 /etc/pam.d/system-auth-ac
it is possible that the pam_systemd.so changes were freshly added during the
interrupted yum session, and therefore the system might currently work.
However, I cant risk interrupting all my work right now on that hunch
by doing a systemctl sshd try-restart or whatnot.

Comment 5 Michal Schmidt 2011-12-13 16:17:13 UTC

OK, I will assume optimistically that with the current pam configuration files your ssh sessions won't be killed anymore. Closing this bug.
Please reopen if it happens again.