[systemd-devel] multi-user.target -> rescue.target and back to multi-user issues

Michal Soltys soltys at ziu.info
Tue Jun 21 20:23:53 UTC 2016


Hi,

This was tested with recent stock arch distro. I'm not sure if it's 
intended to be able to isolare rescue.target from multi-user, but I 
noticed two issues:

1) getty service and IgnoreOnIsolate option

This beautifully conflicts for console access with sulogin on whichever 
console systemctl isolate was called on. Remaining consoles keep logins 
active and functional as well.

On whichever console we call 'systemctl isolate multi-user' or 
'systemctl default' later, I often have to interrupt systemctl before 
logout (target change "seems" to complete correctly though)

Simply removing that option (why is it used for gettys in the first 
place ?) solves all those issues.

2) pam_system timeouts and stuff

Back to multi-user, getty console prompts are delayed for few seconds 
(whether due to logout or spawning new ones on unused terminals). Actual 
logins are delayed for 20-30s. Logs have pam_systemd complaining:

Jun 21 22:01:57 hoard login[2699]: pam_unix(login:session): session 
opened for user root by LOGIN(uid=0)
Jun 21 22:01:57 hoard login[2699]: pam_systemd(login:session): 
pam-systemd initializing
Jun 21 22:01:57 hoard login[2699]: pam_systemd(login:session): Asking 
logind to create session: uid=0 pid=2699 service=login type=tty 
class=user desktop= seat= vtnr=0 tty=tty3 display= remote=no 
remote_user= remote_host=
Jun 21 22:01:57 hoard systemd-logind[2685]: New session c7 of user root.
Jun 21 22:02:22 hoard login[2699]: pam_systemd(login:session): Failed to 
create session: Connection timed out
Jun 21 22:02:22 hoard login[2699]: ROOT LOGIN ON tty3

(systemd-logind is running as per ps)

After some more time:

Jun 21 22:03:12 hoard systemd[1]: systemd-logind.service: Start 
operation timed out. Terminating.
Jun 21 22:03:12 hoard systemd[1]: Failed to start Login Service.
Jun 21 22:03:12 hoard systemd[1]: systemd-logind.service: Unit entered 
failed state.
Jun 21 22:03:12 hoard systemd[1]: systemd-logind.service: Failed with 
result 'timeout'.
Jun 21 22:03:12 hoard systemd[1]: systemd-logind.service: Service has no 
hold-off time, scheduling restart.
Jun 21 22:03:12 hoard systemd[1]: Stopped Login Service.
Jun 21 22:03:12 hoard systemd[1]: Starting Login Service...
Jun 21 22:03:12 hoard systemd-logind[2708]: New seat seat0.

This "solves" login delays on vcs:
Jun 21 22:17:57 hoard login[2764]: pam_systemd(login:session): Cannot 
create session: Already occupied by a session

But not remotely through e.g. ssh and does nothing about getty delays.

But at the same time:

'systemctl daemon-reload' seems to solve all problems. No more weird 
delays, clean logs - it seems it somehow manages to finish incomplete 
isolate:

Jun 21 21:59:04 hoard systemd[1]: Reloading.
Jun 21 21:59:04 hoard systemd[1]: Started Login Service.
Jun 21 21:59:04 hoard systemd[1]: Reached target Multi-User System.

(pid of systemd-logind is the same despite 'started' line suggesting 
otherwise)



More information about the systemd-devel mailing list