Re: a stop job is running for user manager
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.)
Cheers,
David.
Reply to: