A Process that's irritating me. 'A stop job is running for..."

10 réponses [Dernière contribution]
Geshmy
Hors ligne
A rejoint: 04/23/2015

I have four devices running on trisquel and the one still on version ten doesn't do this to me. The other three all at random times but consistently take up to two minutes to shutdown because of some 'stop job' Think how much data could be upladed to who knows where in two minutes! Meanwhile I am locked out.

I gather it's a systemd thing and there are proper steps to make shutdown just shut down. Last night I did 'systemctl list-jobs' and it said there are no jobs. How can I track down what the job is and configure it so it doesn't cause this delay?

Avron

I am a translator!

Hors ligne
A rejoint: 08/18/2020

When and how do you see that in the stop process? Graphical screen? Console screen after graphical screen has disappeared?

On my side, I have a really irritating problem with Trisquel on Libreboot machines (or somehow derivatives, but the problem is exactly the same on all): the time for the graphical screen to type the encryption password to appear is randomely long (can be several minutes), sometimes I do something else and when I am back it is still not there and I finally switch it off and on again. This makes using these machines to lookup something quickly absolutely not possible.

When it took that long but I finally started the sytem, when I want to later switch off, I am often stuck on the Trisquel background and I finally power off with the power button. This happens on all machines with Libreboot derivatives. On machines with proprietary boot software, the graphical screen shows up in perhaps 10 seconds always. On machines with Libreboot derivatives, if I boot Parabola, there is no such problem at all, the problem is only with Trisquel.

prospero
Hors ligne
A rejoint: 05/20/2022

"If you hit C-A-D more than 7 times within 2s the system will instantly reboot".

https://github.com/systemd/systemd/issues/12262#issuecomment-747307960

There are also several actual clues and some suggested solutions in that thread, depending on which service is causing the timeout.

Geshmy
Hors ligne
A rejoint: 04/23/2015

Thank you guys for your input. I appreciate it.

Alice, I have logged out and in twice and so from session c5 I get regarding c1:

gsmyli@littlesmyli:~$ loginctl session-status c1
c1 - gsmyli (1000)
Since: Sun 2023-10-29 19:00:33 PDT; 58min ago
Leader: 809
Seat: seat0; vc7
Display: :0
Service: lightdm-autologin; type x11; class user
Desktop: Trisquel-mini
State: closing
Unit: session-c1.scope
├─1017 /usr/libexec/geoclue-2.0/demos/agent
├─1022 /usr/bin/ssh-agent -s
└─1067 xscreensaver-systemd

Oct 29 19:00:33 littlesmyli systemd[1]: Started Session c1 of User gsmyli.
Oct 29 19:00:34 littlesmyli spice-vdagent[1032]: vdagent virtio channel /dev/virtio-ports/com.redhat.spice.0 does not exist, Oct 29 19:18:27 littlesmyli lightdm[809]: pam_unix(lightdm-autologin:session): session closed for user gsmyli

re c3 I get:

gsmyli@littlesmyli:~$ loginctl session-status c3
c3 - gsmyli (1000)
Since: Sun 2023-10-29 19:18:44 PDT; 39min ago
Leader: 2270
Seat: seat0; vc7
Display: :0
Service: lightdm; type x11; class user
Desktop: Trisquel-mini
State: closing
Unit: session-c3.scope
├─2425 /usr/bin/ssh-agent -s
└─2427 /usr/libexec/geoclue-2.0/demos/agent

Oct 29 19:18:44 littlesmyli systemd[1]: Started Session c3 of User gsmyli.
Oct 29 19:18:45 littlesmyli spice-vdagent[2435]: vdagent virtio channel /dev/virtio-ports/com.redhat.spice.0 does not exist, exiting
Oct 29 19:40:12 littlesmyli pkexec[2916]: pam_unix(polkit-1:session): session opened for user root(uid=0) by (uid=1000)
Oct 29 19:40:12 littlesmyli pkexec[2916]: gsmyli: Executing command [USER=root] [TTY=unknown] [CWD=/home/gsmyli] [COMMAND=/usr/sbin/synaptic]
Oct 29 19:40:12 littlesmyli dbus-daemon[2936]: [session uid=0 pid=2934] AppArmor D-Bus mediation is enabled
Oct 29 19:51:51 littlesmyli lightdm[2270]: pam_unix(lightdm:session): session closed for user gsmyli

Do these results show show the process systemd unable to close?
Is this the part?

Unit: session-c3.scope
├─2425 /usr/bin/ssh-agent -s
└─2427 /usr/libexec/geoclue-2.0/demos/agent

Prospero, Thanks for the link. I will study that too.

Geshmy
Hors ligne
A rejoint: 04/23/2015

Haven't given up yet...
sudo apt purge geoclue-2.0
Used synaptic to remove ssh-agent
sudo apt purge gnome-online-accounts
sudo apt purge spice-vdagent
sudo apt purge evolution-data-server

After logging out
gsmyli@littlesmyli:~$ loginctl list-sessions
SESSION UID USER SEAT TTY
c1 1000 gsmyli seat0
c3 1000 gsmyli seat0

2 sessions listed.
gsmyli@littlesmyli:~$ loginctl session-status c1
c1 - gsmyli (1000)
Since: Mon 2023-10-30 20:33:19 PDT; 12min ago
Leader: 806
Seat: seat0; vc7
Display: :0
Service: lightdm-autologin; type x11; class user
Desktop: Trisquel-mini
State: closing
Unit: session-c1.scope
└─1022 xscreensaver-systemd

Oct 30 20:33:20 littlesmyli systemd[1]: Started Session c1 of User gsmyli.
Oct 30 20:43:39 littlesmyli lightdm[806]: pam_unix(lightdm-autologin:session): >
lines 1-13/13 (END)

sudo apt purge xscreensaver

After logging out and in once more I get:

gsmyli@littlesmyli:~$ loginctl list-sessions
SESSION UID USER SEAT TTY
c3 1000 gsmyli seat0

1 sessions listed.

So I would guess everything closed in c1.
But still no joy. 'A stop job is running for User Manager ...' - says for user 1000

Oh well there's always tomorrow.

prospero
Hors ligne
A rejoint: 05/20/2022

I feel sorry not to be able to fully sympathize with you, but these annoying "stop job running" timeout situations have all but stopped happening on my Trisquel 11 system for a while. Not sure what I did exactly to deserve that.

It was seemingly related to the sound card, the wifi card or a torrent client, or possibly a combination of those. All three have often been reported as culprits. I may have been running Transmission as a startup application at the time, since Trisquel 11 was newly released. If it was to bother me again, I believe I would try to implement Lillecarl's suggestion and search for "timed out. Killing" in journalctl after rebooting.

Else, if reducing the timeout is an acceptable workaround for you: https://unix.stackexchange.com/a/297318.

Geshmy
Hors ligne
A rejoint: 04/23/2015

- I believe I would try to implement Lillecarl's suggestion and search for "timed out. Killing" in journalctl after rebooting.

Thanks for that tip, prospero. Was good as it led me to the only app being killed so

sudo apt purge fluidsynth

But that dang User Manager is still running a stop job when I shutdown. He's a shadowy character. I try a search for "Linux 'User Manager'" and it seems he doesn't have any online presence to speak of. Could even be a she these days. Do they keep any logs?

In /etc/init.d I did
sudo chmod -x on whoopsie, lvm2 and lvm2-lvmpolld - do not have lvm2 file system nor want to send crash reports to Ubuntu.

So I can find it I'll put that work around here:

In /etc/systemd/system.conf down from 90s to for example 10s:

DefaultTimeoutStopSec=10s

and run the following command in terminal after making changes

$ systemctl daemon-reload

Geshmy
Hors ligne
A rejoint: 04/23/2015

In /etc/init.d I did
sudo chmod -x on whoopsie, lvm2 and lvm2-lvmpolld - do not have lvm2 file system nor want to send crash reports to Ubuntu.

Perhaps that did it. Shutdown seems to go smoothly now.

(Edit) I put the executable bit back on those three and shutdown did not lag so I am assuming it was fluidsynth. I installed trisquel-mini 11 on this device a month or so ago but have downloaded a lot of music production software in the past week or ten days and I am pretty sure it started as a result of that.

Anyway, I learned a lot (till I forget) and cleaned up a lot of stuff not wanted or needed. Thanks Alice and Prospero.

Geshmy
Hors ligne
A rejoint: 04/23/2015

OK, I followed through on your suggestion (+xed them and then disabled them using systemctl)

Whoopsie never showed when I did a
systemctl | grep service > Desktop/services.txt

First I noticed the user in /etc/passwd.

Ark74

I am a member!

I am a translator!

Hors ligne
A rejoint: 07/15/2009

IIRC, whoopsie is no longer part of current Aramo's stack software, right?

Early adopters might have it from earlier it was removed from dependencies.
But you should be free to remove it with,
sudo apt remove whoopsie

Regards.

Geshmy
Hors ligne
A rejoint: 04/23/2015

I can confirm whoopsie wasn't here after a fresh install.