Arghh- a stop job is running for session 1

Organelle Hacking
1

Hi Guys,

Does anyone else see this when using ~/scripts/reboot.sh I get a 1.5 minute timeout with this message.

I thought it might be something to do with remote logins but it isn’t.

Anyone any ideas?

Andy

2

actually it may be to do with ssh…

3

i don’t think it is to do with remote, as i added as an option for ‘installs’ to reboot and saw also a very long pause (~1min) so that was without ssh etc.
(or at least i think i wasn’t ssh’d in at the time, id need to double check)

i think the issue is to do with the shutdown procedure, as even a normal shutdown is slow, compared to the ‘menu shutdown’

but, ive also noticed when the Organelle is shutdown is done from the ‘menu’, this shutdown is actually kernel faulting… so i think that’s why its faster, as its not going thru a full shutdown.
(not really an issue, since its sync’d and the rootfs is ro)

4

Yeah, I’m not sure it is to do with ssh either, I don’t know it always does it if you have a ssh connected and nearly always does it if you don’t. If you just start the organelle, load a patch and reboot it from the keyboard/hdmi it never seems to do it, for me anyway!

I noticed the kernel fault on shutdown and just went with the old “They know what they are doing so I can ignore that” type of thinking.

I guess for nearly all users this is not an issue, I might well spend some time tomorrow trying to track it down…

5

I think I’ve only experienced it with WiFi adapter attached (don’t recall if ssh session made a difference) I always thought it was something to do with WiFi at hardware level. The kernel panic at very end of shutdown is nothing to worry about (everything else already completed), but the “job running” bit is real annoying. in OS 3 (which I assume you are running) the shutdown script was updated to shut down WiFi properly, and I hoped it would go away…

6

Yep os3, I’m going to have a look tomorrow to see if I can track it down. It is something owned by systemd so I will start there…

7

Ok I have been playing around a bit with this and can see no rhyme or reason about when it does this.

Is there a simple way of setting up the jounrnalctl logs to be persistent between boots? I have been flaffing around with it a while with no success!

8

Ok I bodged it, not sure if its the right way to do it but I have persistent logs now…

9

Ok, its maybe the time sync daemon:

Dec 30 08:59:09 organelle systemd[1]: Started Generate shutdown-ramfs.
Dec 30 08:59:09 organelle dhcpcd[430]: wlan0: soliciting a DHCP lease
Dec 30 08:59:09 organelle dhcpcd[430]: wlan0: soliciting an IPv6 router
Dec 30 08:59:17 organelle systemd-timesyncd[228]: Timed out waiting for reply from 145.239.118.233:123 (2.arch.pool.ntp.org).
Dec 30 08:59:21 organelle dhcpcd[430]: wlan0: no IPv6 Routers available
Dec 30 09:00:37 organelle systemd[1]: session-1.scope: Stopping timed out. Killing.
Dec 30 09:00:37 organelle systemd[1]: Stopped Session 1 of user root.
Dec 30 09:00:37 organelle systemd[1]: session-1.scope: Unit entered failed state.

It looks like dhcpd is starting up the network system just before as well, weird.

Now to try to fix it…

10

Ok that time sync timeout is a red herring it isn’t causing the 1:30 timeout.

Interestingly while trying to get to the bottom of this I removed the kill of the network stuff and logged out what was running under root and waited for a key:

#killall wpa_supplicant
#killall dhcpcd
loginctl user-status root
read -p "1. Press any key to continue... " -n1 -s

gives:

root (0)
           Since: Sat 2015-10-17 01:07:25 UTC; 2 years 2 months ago
           State: active
        Sessions: 3 *1
            Unit: user-0.slice
                  |-session-3.scope
                  | |-510 sshd: root@pts/0   
                  | |-512 -bash
                  | |-517 /bin/sh /root/scripts/reboot.sh
                  | |-561 loginctl user-status root
                  | `-562 loginctl user-status root
                  |-session-1.scope
                  | |-248 login -- root     
                  | |-260 -bash
                  | |-429 wpa_supplicant -B -D nl80211,wext -i wlan0 -c /dev/fd/63
                  | `-432 dhcpcd -b wlan0
                  `-user@0.service
                    `-init.scope
                      |-253 /usr/lib/systemd/systemd --user
                      `-255 (sd-pam)

With this waiting for keystroke you do not get the 1:30 timeout!

So it looks like we need some pause before issuing the reboot.

11

Putting in a pause doesn’t work.

Waiting for a keystroke works 100% of the time, even when pressing a key immediately.

Madness.