Re: a stop job is running for user manager

[Richmond <richmond@criptext.com>]

Richmond <richmond@criptext.com> writes:

> David Wright <deblis@lionunicorn.co.uk> writes:
>
>> On Fri 18 Feb 2022 at 21:13:16 (+0000), Richmond wrote:
>>> Махно <mindaugasceliesius@gmail.com> writes:
>>> > 2022-02-18, pn, 03:28 David Wright rašė:
>>> >> On Thu 17 Feb 2022 at 13:44:46 (+0000), Richmond wrote:
>>> >> > David Wright <deblis@lionunicorn.co.uk> writes:
>>> >> > > On Thu 17 Feb 2022 at 01:00:30 (+0000), Richmond wrote:
>>> >> > >> Since upgrading to Debian 11 I sometimes see "a stop job is running for
>>> >> > >> user manager..." on shutdown and it waits 90 seconds. The last comment
>>> >> > >> in this thread says "Installing systemd from backsports solved this issue."
>>> >> > >>
>>> >> > >> https://forums.debian.net/viewtopic.php?t=150080
>>> >> > >>
>>> >> > >> I guess that means a backport from testing. Is that a good idea?
>>> >> > >
>>> >> > > No, it's not.
>>> >> > >
>>> >> > > testing: 250.3-2
>>> >> > >
>>> >> > > BULLSEYE backports: 250.3-2~bpo11+1
>>> >> > >
>>> >> > > The latter is lovingly crafted to suit your installed libraries.
>>> >> > > The former depends on bookworm/testing's libraries.
>>> >> >
>>> >> > Thanks, I see my mistake, I thought bullseye-backports meant backports
>>> >> > from bullseye, but it means *to* bullseye. However when I tried it, apt
>>> >> > says it will remove 92 packages which doesn't sound right to me. Is it
>>> >> > supposed to do that? I had to include libsystemd0 for dependencies.
>>> >> >
>>> >> > sudo apt install libsystemd0/bullseye-backports systemd/bullseye-backports
>>> >> >
>>> >> > The following packages will be upgraded:
>>> >> >   libsystemd0 systemd
>>> >> > 2 upgraded, 0 newly installed, 92 to remove and 0 not upgraded.
>>> >> > Need to get 5,167 kB of archives.
>>> >> > After this operation, 383 MB disk space will be freed.
>>> >> > Do you want to continue? [Y/n] n
>>> >> > Abort.
>>> >>
>>> >> For me, the effect is very much smaller, and I don't think I'd miss
>>> >> most of what it wants to remove. The difference may be because you run
>>> >> a DE and I don't. (I've made no attempt to analyse the output below.)
>>> >>
>>> >> The obvious alternative is either put up with the delay, or research
>>> >> what might be causing it. There's a link near the top of the page you
>>> >> referenced, with discussions that might help, though bear in mind that
>>> >> shortening the timeout or hammering the three finger salute aren't solutions.
>>> >>
>>> >> Perhaps backports isn't really a solution, either. There's no
>>> >> explanation or justification given by ddebbb.
>>> >>
>>> >> $ apt-get -s install systemd/bullseye-backports
>>> >> [ … ]
>>> >> 2 upgraded, 1 newly installed, 9 to remove and 0 not upgraded.
>>> >> [ … ]
>>> >> $
>>> 
>>> > Hello! I would suggest that you report this issue to Debian BTS by
>>> > using the reportbug program. Also, i think you should wait for a
>>> > person, responsible for the maintenance of this package and wait for
>>> > an answer.
>>> 
>>> Perhaps. Yesterday I found a site that suggested removing entries from
>>> ~/.config/autostart/
>>> 
>>> There were a few in there for applications I no longer have installed,
>>> so I removed them, and I am monitoring to see if I see the shutdown
>>> delay again. It maybe relates to a gnome bug which was not fixed in
>>> Mate. It is hard to tell from journalctl which error if any relates to
>>> the delay.
>>
>> That seems like a step in the right direction. A quick question:
>> do you logout before you shutdown or not? It might be possible to
>> observe whether the delay is during logoff or shutdown.
>>
>> (It's not directly relevant, but when running bullseye in 512MB,
>> it helps to kill the browser, terminate X, logout, and shutdown
>> in turn, because the agressive parallelism of systemd works against
>> you with such limited memory.)
>>
>
> That autostart removal didn't work.
>
> So far this problem has occured only when shutting down an open session,
> although I don't think there necessarily needs to be any application
> open.
>
> Next I will try what you say (logoff) and see if there is any
> delay. Another option is to use startx rather than a display manager,
> although I think I may have tried that. Another option is to use a
> different, or no, desktop env. and try to close in by the process of
> elimination, Dr Watson.

For some time I used the procedure: log off Mate, then shut down from
the display manager. I didn't get any delays. Then for some time I used
icewm manager without any desktop environment and didn't get any delay
in shutdown, even if I shutdown by pressing the power button without
logout.

I think the bug is somewhere in Mate therefore. Maybe it is caused by
the ufw - uncomplicated firewall, as someone reported it causing
problems at startup.