Bug 1743416

Summary: Open SSH connections lost when switching runlevels
Product: Red Hat Enterprise Linux 7 Reporter: Skip Wyatt <awyatt>
Component: systemdAssignee: systemd-maint
Status: CLOSED DUPLICATE QA Contact: Frantisek Sumsal <fsumsal>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 7.7CC: dtardon, ngarrett, systemd-maint-list
Target Milestone: rc   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-08-27 13:49:51 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:
Attachments:
Description Flags
var log secure showing log outs. none

Description Skip Wyatt 2019-08-19 21:26:10 UTC
Created attachment 1605895 [details]
var log secure showing log outs.

Description of problem:
When there are open SSH connections to a RHEL 7.7 device and the run level is changed between multi-user and graphical in either direction, the SSH connections are lost.

Version-Release number of selected component (if applicable):
systemd-219-67.el7_7.1.x86_64
systemd-libs-219-67.el7_7.1.x86_64

How reproducible:
Every Time

Steps to Reproduce:
1. Spin up RHEL 7.7 system
2. open one or more SSH connections to above system.
3. change the runlevel from 5 to 3 or vice versa (systemctl isolate multi-user.target

Actual results:
Any SSH connections opened prior to runlevel change are closed

Expected results:
Any SSH connections opened prior to runlevel change should remain open

Additional info:
I'm able to re-open SSH connections after the runlevel change, but any that are open during the change are closed.

I'll attach the /var/log/secure from the rhel 7.7 VM that was created that this was replicated on. Please let me know if anything else is needed for troubleshooting this.

Comment 2 David Tardon 2019-08-27 13:49:51 UTC

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