Re: a stop job is running for user manager

[Richmond]

David Wright  writes:

> On Fri 18 Feb 2022 at 21:13:16 (+), Richmond wrote:
>> Махно  writes:
>> > 2022-02-18, pn, 03:28 David Wright rašė:
>> >> On Thu 17 Feb 2022 at 13:44:46 (+), Richmond wrote:
>> >> > David Wright  writes:
>> >> > > On Thu 17 Feb 2022 at 01:00:30 (+), 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.

Re: a stop job is running for user manager

[David Wright]

On Fri 18 Feb 2022 at 21:13:16 (+), Richmond wrote:
> Махно  writes:
> > 2022-02-18, pn, 03:28 David Wright rašė:
> >> On Thu 17 Feb 2022 at 13:44:46 (+), Richmond wrote:
> >> > David Wright  writes:
> >> > > On Thu 17 Feb 2022 at 01:00:30 (+), 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.

Re: a stop job is running for user manager

[Richmond]

Махно  writes:

> 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.

>
> 2022-02-18, pn, 03:28 David Wright  rašė:
>>
>> On Thu 17 Feb 2022 at 13:44:46 (+), Richmond wrote:
>> > David Wright  writes:
>> > > On Thu 17 Feb 2022 at 01:00:30 (+), 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
>> NOTE: This is only a simulation!
>>   apt-get needs root privileges for real execution.
>>   Keep also in mind that locking is deactivated,
>>   so don't depend on the relevance to the real current situation!
>> Reading package lists... Done
>> Building dependency tree... Done
>> Reading state information... Done
>> Selected version '250.3-2~bpo11+1' (Debian Backports:bullseye-backports 
>> [amd64]) for 'systemd'
>> Selected version '250.3-2~bpo11+1' (Debian Backports:bullseye-backports 
>> [amd64]) for 'libsystemd0' because of 'systemd'
>> The following packages were automatically installed and are no longer 
>> required:
>>   colord-data gparted-common libcolorhug2 libgusb2 libjim0.79 libmbim-glib4 
>> libmbim-proxy libpipewire-0.3-0
>>   libpipewire-0.3-modules libqmi-glib5 libqmi-proxy libspa-0.2-modules 
>> pipewire pipewire-bin usb-modeswitch
>>   usb-modeswitch-data xdg-desktop-portal
>> Use 'apt autoremove' to remove them.
>> The following additional packages will be installed:
>>   dbus-x11 libsystemd0
>> Suggested packages:
>>   systemd-container libtss2-esys-3.0.2-0 libtss2-mu0 libtss2-rc0 policykit-1
>> Recommended packages:
>>   systemd-timesyncd | time-daemon
>> The following packages will be REMOVED:
>>   colord dbus-user-session gparted libnss-systemd libpam-systemd 
>> modemmanager policykit-1 systemd-timesyncd
>>   xdg-desktop-portal-gtk
>> The following NEW packages will be installed:
>>   dbus-x11
>> The following packages will be upgraded:
>>   libsystemd0 systemd
>> 2 upgraded, 1 newly installed, 9 to remove and 0 not upgraded.
>> Remv colord [1.4.5-3]
>> Remv xdg-desktop-portal-gtk [1.8.0-1]
>> Remv dbus-user-session [1.12.20-2] [audacious:amd64 dconf-service:amd64 
>> xdg-desktop-portal:amd64 ]
>> Inst dbus-x11 (1.12.20-2 Debian:11.2/stable [amd64])
>> Remv gparted [1.2.0-1]
>> Remv libnss-systemd [247.3-6]
>> Remv modemmanager [1.14.12-0.2]
>> Remv policykit-1 [0.105-31+deb11u1]
>> Remv libpam-systemd [247.3-6]
>> Remv systemd-timesyncd [247.3-6] [systemd:amd64 ]
>> Inst systemd [247.3-6] (250.3-2~bpo11+1 Debian Backports:bullseye-backports 
>> [amd64]) []
>> Inst libsystemd0 

Re: a stop job is running for user manager

[Махно]

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.

2022-02-18, pn, 03:28 David Wright  rašė:
>
> On Thu 17 Feb 2022 at 13:44:46 (+), Richmond wrote:
> > David Wright  writes:
> > > On Thu 17 Feb 2022 at 01:00:30 (+), 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
> NOTE: This is only a simulation!
>   apt-get needs root privileges for real execution.
>   Keep also in mind that locking is deactivated,
>   so don't depend on the relevance to the real current situation!
> Reading package lists... Done
> Building dependency tree... Done
> Reading state information... Done
> Selected version '250.3-2~bpo11+1' (Debian Backports:bullseye-backports 
> [amd64]) for 'systemd'
> Selected version '250.3-2~bpo11+1' (Debian Backports:bullseye-backports 
> [amd64]) for 'libsystemd0' because of 'systemd'
> The following packages were automatically installed and are no longer 
> required:
>   colord-data gparted-common libcolorhug2 libgusb2 libjim0.79 libmbim-glib4 
> libmbim-proxy libpipewire-0.3-0
>   libpipewire-0.3-modules libqmi-glib5 libqmi-proxy libspa-0.2-modules 
> pipewire pipewire-bin usb-modeswitch
>   usb-modeswitch-data xdg-desktop-portal
> Use 'apt autoremove' to remove them.
> The following additional packages will be installed:
>   dbus-x11 libsystemd0
> Suggested packages:
>   systemd-container libtss2-esys-3.0.2-0 libtss2-mu0 libtss2-rc0 policykit-1
> Recommended packages:
>   systemd-timesyncd | time-daemon
> The following packages will be REMOVED:
>   colord dbus-user-session gparted libnss-systemd libpam-systemd modemmanager 
> policykit-1 systemd-timesyncd
>   xdg-desktop-portal-gtk
> The following NEW packages will be installed:
>   dbus-x11
> The following packages will be upgraded:
>   libsystemd0 systemd
> 2 upgraded, 1 newly installed, 9 to remove and 0 not upgraded.
> Remv colord [1.4.5-3]
> Remv xdg-desktop-portal-gtk [1.8.0-1]
> Remv dbus-user-session [1.12.20-2] [audacious:amd64 dconf-service:amd64 
> xdg-desktop-portal:amd64 ]
> Inst dbus-x11 (1.12.20-2 Debian:11.2/stable [amd64])
> Remv gparted [1.2.0-1]
> Remv libnss-systemd [247.3-6]
> Remv modemmanager [1.14.12-0.2]
> Remv policykit-1 [0.105-31+deb11u1]
> Remv libpam-systemd [247.3-6]
> Remv systemd-timesyncd [247.3-6] [systemd:amd64 ]
> Inst systemd [247.3-6] (250.3-2~bpo11+1 Debian Backports:bullseye-backports 
> [amd64]) []
> Inst libsystemd0 [247.3-6] (250.3-2~bpo11+1 Debian 
> Backports:bullseye-backports [amd64])
> Conf libsystemd0 (250.3-2~bpo11+1 Debian Backports:bullseye-backports [amd64])
> Conf dbus-x11 (1.12.20-2 Debian:11.2/stable [amd64])
> Conf systemd (250.3-2~bpo11+1 Debian Backports:bullseye-backports [amd64])
> $
>
> Cheers,
> David.
>

Re: a stop job is running for user manager

[David Wright]

On Thu 17 Feb 2022 at 13:44:46 (+), Richmond wrote:
> David Wright  writes:
> > On Thu 17 Feb 2022 at 01:00:30 (+), 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
NOTE: This is only a simulation!
  apt-get needs root privileges for real execution.
  Keep also in mind that locking is deactivated,
  so don't depend on the relevance to the real current situation!
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Selected version '250.3-2~bpo11+1' (Debian Backports:bullseye-backports 
[amd64]) for 'systemd'
Selected version '250.3-2~bpo11+1' (Debian Backports:bullseye-backports 
[amd64]) for 'libsystemd0' because of 'systemd'
The following packages were automatically installed and are no longer required:
  colord-data gparted-common libcolorhug2 libgusb2 libjim0.79 libmbim-glib4 
libmbim-proxy libpipewire-0.3-0
  libpipewire-0.3-modules libqmi-glib5 libqmi-proxy libspa-0.2-modules pipewire 
pipewire-bin usb-modeswitch
  usb-modeswitch-data xdg-desktop-portal
Use 'apt autoremove' to remove them.
The following additional packages will be installed:
  dbus-x11 libsystemd0
Suggested packages:
  systemd-container libtss2-esys-3.0.2-0 libtss2-mu0 libtss2-rc0 policykit-1
Recommended packages:
  systemd-timesyncd | time-daemon
The following packages will be REMOVED:
  colord dbus-user-session gparted libnss-systemd libpam-systemd modemmanager 
policykit-1 systemd-timesyncd
  xdg-desktop-portal-gtk
The following NEW packages will be installed:
  dbus-x11
The following packages will be upgraded:
  libsystemd0 systemd
2 upgraded, 1 newly installed, 9 to remove and 0 not upgraded.
Remv colord [1.4.5-3]
Remv xdg-desktop-portal-gtk [1.8.0-1]
Remv dbus-user-session [1.12.20-2] [audacious:amd64 dconf-service:amd64 
xdg-desktop-portal:amd64 ]
Inst dbus-x11 (1.12.20-2 Debian:11.2/stable [amd64])
Remv gparted [1.2.0-1]
Remv libnss-systemd [247.3-6]
Remv modemmanager [1.14.12-0.2]
Remv policykit-1 [0.105-31+deb11u1]
Remv libpam-systemd [247.3-6]
Remv systemd-timesyncd [247.3-6] [systemd:amd64 ]
Inst systemd [247.3-6] (250.3-2~bpo11+1 Debian Backports:bullseye-backports 
[amd64]) []
Inst libsystemd0 [247.3-6] (250.3-2~bpo11+1 Debian Backports:bullseye-backports 
[amd64])
Conf libsystemd0 (250.3-2~bpo11+1 Debian Backports:bullseye-backports [amd64])
Conf dbus-x11 (1.12.20-2 Debian:11.2/stable [amd64])
Conf systemd (250.3-2~bpo11+1 Debian Backports:bullseye-backports [amd64])
$ 

Cheers,
David.

Re: a stop job is running for user manager

[Richmond]

David Wright  writes:

> On Thu 17 Feb 2022 at 01:00:30 (+), 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.
>
> Cheers,
> David.

Here are the packages it says it wants to remove. Note: 
mate-desktop-environment:

The following packages will be REMOVED:
  baloo-kf5 dbus-user-session dolphin gnome-software 
gstreamer1.0-plugins-good:i386 gufw
  kaccounts-providers kactivitymanagerd kde-cli-tools kdeconnect keditbookmarks 
kinit kio
  kio-extras kpackagelauncherqml libasound2-plugins:i386 libavahi-client3:i386 
libcups2:i386
  libdbus-1-3:i386 libfaudio0:i386 libkf5auth-dev libkf5auth5 libkf5authcore5
  libkf5baloowidgets-bin libkf5baloowidgets5 libkf5bookmarks-dev 
libkf5bookmarks5
  libkf5configwidgets-dev libkf5configwidgets5 libkf5declarative5 
libkf5iconthemes-bin
  libkf5iconthemes-dev libkf5iconthemes5 libkf5kcmutils-dev libkf5kcmutils5 
libkf5kio-dev
  libkf5kiocore5 libkf5kiofilewidgets5 libkf5kiogui5 libkf5kiowidgets5 
libkf5newstuff5
  libkf5newstuffcore5 libkf5notifyconfig-dev libkf5notifyconfig5 
libkf5parts-plugins libkf5parts5
  libkf5plasma5 libkf5plasmaquick5 libkf5purpose-bin libkf5purpose-dev 
libkf5purpose5
  libkf5quickaddons5 libkf5textwidgets5 libkf5wallet-bin libkf5xmlgui-dev 
libkf5xmlgui5
  libnss-systemd libpam-systemd libpcap0.8:i386 libpolkit-qt5-1-1 
libpulse0:i386 libsane1:i386
  libsdl2-2.0-0:i386 libsystemd0:i386 libwine:i386 lightdm 
mate-applet-brisk-menu mate-applets
  mate-control-center mate-desktop-environment mate-desktop-environment-core 
mate-panel mate-polkit
  mate-power-manager mate-settings-daemon modemmanager network-manager 
network-manager-gnome
  packagekit packagekit-tools plasma-framework policykit-1 
qml-module-org-kde-kconfig
  qml-module-org-kde-kquickcontrols qml-module-org-kde-kquickcontrolsaddons
  qml-module-org-kde-newstuff qml-module-org-kde-purpose rtkit synaptic 
systemd-timesyncd
  task-mate-desktop wine32:i386

Re: a stop job is running for user manager

[Richmond]

David Wright  writes:

> On Thu 17 Feb 2022 at 01:00:30 (+), 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.

Re: a stop job is running for user manager

[David Wright]

On Thu 17 Feb 2022 at 01:00:30 (+), 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.

Cheers,
David.

Re: A stop job is running for...

[Jape Person]

On 12/05/2015 01:21 AM, Himanshu Shekhar wrote:

Well, Google shall help! The two articles seem much technical for a kid
like me. Still, the content made me feel that there shall be something
convincing, which is why I posted it on this mail.

1.
https://lists.fedoraproject.org/pipermail/users/2014-February/446722.html
  # for NTP


This post supplies two "fixes" for the NTP problem, but only by not 
allowing the service to start in the first place, or by doing what has 
been suggested earlier in the thread -- forcing the system to shut down 
without waiting. I do want my systems to benefit from syncrhonization 
with time sources. And the purpose of all of the discussion is to 
actually find out what's wrong with what component(s) of the system 
that's causing the problem in the first place.



2. https://bugzilla.redhat.com/show_bug.cgi?id=1044602
 # for CUPS



I actually posted that link earlier in the thread in my reply of 12/02 
to Don Armstrong. The indication is that CUPS was interacting with the 
avahi daemon both directly and indirectly (via systemd configuration). 
Especially if the problem is caused by the direct interaction, there's 
not much of anything that an end user could do to fix the problem -- 
except report it. And that would require a lot of work to figure out 
what really is the culprit. That's something that's well beyond my skill 
level, but Michael Biebl had been pursuing the matter offline by 
providing the monkey (me) with step-by-step instructions to help him 
suss out the issues.


Unfortunately, I have discovered a separate interfering issue on my 
systems which may have muddied the waters. I'm not sure whether or not 
Michael will be continuing to work on my particular problem since 
eliminating the interfering issue has essentially fixed both the CUPS 
and NTP problems for me.



The message may be irrelevant due to lack of knowledge. So you may
ignore it if it is so.

Regards
Himanshu Shekhar


Not at all. I appreciate your interest, and I would certainly not ignore 
you. I intend to report back with the findings in my particular case 
when I know a little more.


In the meantime, we should remember that others have reported the same 
issue with CUPS and NTP. I suspect that those others are unlikely (IMO) 
to be running systems with the same configuration as mine. So the 
problem with CUPS and NTP vs. systemd is probably real -- even if it 
might only be a corner case.


Regards,
JP

Re: A stop job is running for...

[David Wright]

On Wed 02 Dec 2015 at 18:17:18 (+0100), Michael Biebl wrote:
> Am 02.12.2015 um 18:05 schrieb Jape Person:
> > On 12/02/2015 10:49 AM, David Wright wrote:
> >> I have observed behaviour where, when the time limit of 90 seconds is
> >> reached, the limit increases by another 90 seconds and nothing else
> >> happens (for hours). eg
> >>
> >> [ <*> ] A stop job is running for Manage, Install and Generate Color
> >> Profiles (34min 54s / 36min)_
> >>
> >> Fortunately, that hasn't happened for a few months. It's very
> >> embarrassing when my laptop takes longer to close down than my
> >> wife's W10.
> 
> Sounds like it could be hard to reproduce indeed.
> 
> > Now *that* would be annoying.
> 
> In case you run into such a situation again, where a service is blocking
> the shutdown you can of course just use force and pull the plug or use
> sysrq b.
> But there is a nicer alternative: just hit ctrl+alt+del quickly 7 times.
> systemd then will initiate a forced shutdown. See [1].

[...]

> http://www.freedesktop.org/software/systemd/man/systemd.html#SIGINT

I presume that this facility was added between versions 215 (jessie)
and 228 (this web page) so I'm hoping not to need it. Thanks anyway.

Cheers,
David.

Systemd debugging (was ... Re: A stop job is running for...)

[Chris Bannister]

On Thu, Dec 03, 2015 at 10:07:01PM +0100, Michael Biebl wrote:
> Two issues that come to mind here:
> a/ cups-browsed.service declares a dependency on avahi-daemon.service.
> So it should be stopped before avahi-daemon. But apparently you don't
> have any avahi-daemon process anymore.
> Would be interesting to find out, why avahi-daemon.service is stopped
> before cups-browsed.
> Can you paste the systemctl cat avahi-daemon.service cups-browsed.service
> output
> 
> b/ you use wicd. I suspect wicd is stopped (too) early during shutdown
> and tears down the network connection. Maybe that's related as well.
> 
> I wonder if we should take this off list now. Not sure if our debugging
> session is interesting to the readers of this mailing list.

Au contraire, not knowing much about systemd myself, and having wrestled
with a postgreSQL upgrade on a raspberry PI running raspbian, I'm keen
on any troubleshooting/bug hunting tips I can get.

This may have had something to do it.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=755894

-- 
"If you're not careful, the newspapers will have you hating the people
who are being oppressed, and loving the people who are doing the 
oppressing." --- Malcolm X

Re: A stop job is running for...

[Himanshu Shekhar]

Well, Google shall help! The two articles seem much technical for a kid
like me. Still, the content made me feel that there shall be something
convincing, which is why I posted it on this mail.

1. https://lists.fedoraproject.org/pipermail/users/2014-February/446722.html
   # for NTP
2. https://bugzilla.redhat.com/show_bug.cgi?id=1044602
  # for CUPS

The message may be irrelevant due to lack of knowledge. So you may ignore
it if it is so.

Regards
Himanshu Shekhar

Re: A stop job is running for...

[Don Armstrong]

On Thu, 03 Dec 2015, David Wright wrote:
> Which data do you mean?

For example, a database server[1] which has a transaction outstanding or
needs a long time to write to disk for an orderly shutdown.

> By the time these Stop jobs start running, there are just system
> processes running. I don't really care about them as long as the
> filesystems get unmounted.

The issue here are the system processes, which in some cases need more
time to shut down.


1: To the best of my knowledge, the sysv init scripts for postgresql and
mysql actually handle this properly, so this is more of a theoretical
example.
-- 
Don Armstrong  http://www.donarmstrong.com

I leave the show floor, but not before a pack of caffeinated Jolt gum
is thrust at me by a hyperactive girl screaming, "Chew more! Do more!"
The American will to consume more and produce more personified in a
stick of gum. I grab it.
 -- Chad Dickerson

Re: A stop job is running for...

[Himanshu Shekhar]

Hey!

On Dec 1, 2015 7:42 AM, "Jape Person" <jap...@comcast.net> wrote: > > Make
remote CUPS printers available locally > Network Time Synchronization > >
For several weeks I've been seeing this stop job notification for these two
items frequently when rebooting or shutting down two of my four testing
systems. > > The first notification counts all the way up to 1 min 30 sec
before the shutdown scroll restarts. The second notification only counts
for a few seconds before terminating. > > I'm a patient guy, but adding
almost two minutes to almost every restart or shutdown procedure gets a bit
tedious after a while. >

Can you please annoy yourself once more and exactly tell what that
start/stop job is for.

I had a friend with same problem recently. He had the start/stop job for
some uuidd... I found that he was missing the swap partition that he
created while installation. There would definitely be a legitimate reason
for that message to appear.

> Suggestions, anyone? The complete message is really important. Perhaps, I
would investigate.

> I'm grateful for your time and any ideas you might provide.

We love to gain experience. So thanks to you too. Good luck!

Hima… irm20…

3 Dec 3:47pm To: irm2015...@iiita.ac.in Show details

Delivery to the following recipient failed permanently:

debian-u...@lists.debian.com

Technical details of permanent failure: DNS Error: Address resolution of
lists.debian.com. failed: Domain name not found

- Original message -

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
iiita-ac-in.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:
references:date:message-id:subject:from:to :content-type;
bh=mWJbLhjU2yuTzrRErSrHU3g2qROIOcCIFX/tyvssJVg=;
b=KSV8UNGTTaggQPv4/CdT8WrU7VQfdpneOVQRCayXJvBs4pZ u+mNEzfjHujjy8N5vdx
j6aX6Y+vFYF5VxcjO6pAU7OO9Ieg3e+ GaB43Fra+2IJ0ZeO+WajkpmV7f8v0MRX8TPQ+
X7Ae/3hXdFyt7TvdntFWJBk69pkESWp6fuK/qrEMsjc/ESPs9IRVYw6d9Gexb+t3cv5W
ILvS1Utseo6jySEDgw07TmZDHMzbiE matljuEAi8rMyOIU5Zbhi91R+FoA1ETKakCLiQ
9g4hBeStvm3VtTBd+ VULmAvSSdO1AGr87VuY3i1nOU1+ MCYoxxihPiplJQkRw7zvBqTV
G2SQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
1e100.net; s=20130820;
h=x-gm-message-state:mime-version:in-reply-to:references:date
:message-id:subject:from:to:content-type;
bh=mWJbLhjU2yuTzrRErSrHU3g2qROIOcCIFX/tyvssJVg=;
b=fRj4O68J4ZK/YqoKLcsSqm4LGSm+
KwoW0MdbticMdgIf2Q/D50+wU98WMRUH4ZXOR/22jQiOUUdNqn3VtRae3FpuoxPFiW5A
NwsYJnWtHlc6e6+PfCX66XQXNxSj0smrx+HNDK
vPPMyT0SMMGUmiVW2cCfTKyzGD2wPRAo/gWzvV5MdWtqhZ91VEm29ALu8Esf4vWUauQy
wnsNOPAbfjWKA6K5NBpu5aZ4yFeufy CoS02Ldt1k/Ydmbn6Jhg6z80PEmHMed6tAPtaM
jR0idGoFJLX9wOmg5ZJwJ/tv5/ZmxqeBvGUyaOASFuIKcjIvGoQN5U+ OPCSHtbcBG7hX
qzbw== X-Gm-Message-State: ALoCoQn1GZhA/+9+ AGK1Y6SK43GAmRAtVaPrUMWoyH7K7i
G1D9EuVFMjX7C8S7+xEpkcm+7CZBhS MIME-Version: 1.0 X-Received: by
10.182.131.194 with SMTP id oo2mr5264759obb.84.1449137833287; Thu, 03 Dec
2015 02:17:13 -0800 (PST) Received: by 10.202.67.66 with HTTP; Thu, 3 Dec
2015 02:17:13 -0800 (PST) Received: by 10.202.67.66 with HTTP; Thu, 3 Dec
2015 02:17:13 -0800 (PST) In-Reply-To: <565d0045.4040...@comcast.net>
References: <565d0045.4040...@comcast.net> Date: Thu, 3 Dec 2015 15:47:13
+0530 Message-ID:  Subject: Re: A stop job is running
for... From: Himanshu Shekhar <irm2015...@iiita.ac.in> To: Jape Person <
jap...@comcast.net>, "debian-u...@lists.debian.com" <
debian-u...@lists.debian.com> Content-Type: multipart/alternative;
boundary= 089e01634b8ac8be000525fbb15f ▶ Show quoted text

M

Re: A stop job is running for...

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Thu, Dec 03, 2015 at 05:50:09AM -0500, Gene Heskett wrote:
> On Thursday 03 December 2015 02:41:57 Nicolas George wrote:

[...]

> > Libre Software development is a meritocracy, not a democracy [...]

Hm. Somehow I feel that while true, this is just part of the truth.

> Well, for me that coding oar is quite large, but I write the huge 
> majority of the code I write these days in RS274c, aka g-code to run cnc 
> machines.  I have a lathe and 2 milling machines, all run by LinuxCNC.

[...]

> But I am quite cognizant of the difference in importance to the linux 
> community [...]

This. There are many philosophies in all that spectrum Free Software,
Libre, Open Source. It can be "all about the user", it can be "all
about the developer" (and many other things not fitting in this simple
dipole I just sketched). Developers are users all the time. And so
on.

But one of the things that make us greater than the sum of our parts
is definitely the "caring for the user" part. Oftentimes it's what
get people on board, but also what makes new things possible (those
"new things" start often as "just consumers" and are contributing
to totally different areas. Do not trample on the young saplings :-)

Regards
- -- tomás
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlZgJtwACgkQBcgs9XrR2kY7rQCcC+DrM96JhOrNgNeM/SK3Gzv6
C2YAn2/5HzeICjo5KPQX6njsk7yyRN+o
=nLf3
-END PGP SIGNATURE-

Re: A stop job is running for...

[Gene Heskett]

On Thursday 03 December 2015 02:41:57 Nicolas George wrote:

> Le duodi 12 frimaire, an CCXXIV, Gene Heskett a écrit :
> >But it bugs the heck out of me that the guy/gal
> > doing the codeing doesn't watch the user lists, so it all has to
> > wait on someone qualified enough to wade thru the bug reporter forms
> > and actually file the bug.
>
> Developer time is valuable.
>
> >   Thats quite often a week or more additional
> > delay before they are aware that there really is a problem.
>
> Regarding support with guaranteed reaction time, you get exactly your
> money's worth: 0.
>
> > In the meantime, its hit another 200 users, discouraging them from
> > ever touching linux again.
>
> If these people are so easily discouraged, and especially definitively
> discouraged, they probably belong to the kind of people who only ever
> complain and never contribute back. Maybe the community is better
> without them.
>
> >   Unfortunately, the oar I steer this ship with could be swapped
> > for a toothpick and have exactly the same result.
>
> Libre Software development is a meritocracy, not a democracy. Your oar
> is exactly how large you make it. That means Linus' is larger than
> yours, of course, and that is only right. I am still writing about
> steering oar.
>
> Regards,

Well, for me that coding oar is quite large, but I write the huge 
majority of the code I write these days in RS274c, aka g-code to run cnc 
machines.  I have a lathe and 2 milling machines, all run by LinuxCNC.

You would be amazed at what can be done in 200 lines of g-code.  The good 
stuff I'll put up on my web site from time to time, but generally, I'll 
never see a 100 count in the total downloads column in the logs.

But I am quite cognizant of the difference in importance to the linux 
community.  To you, we are at best fringe users.  And thats ok. But we 
are here, and we appreciate the stability of linux.

Amazingly, because I do share the experience on that mailing list, 
frustrations and all, I am apparently well read there, picking up an 
occasional order of flowers from some of the rest because I'm 
so "colorfull".  Makes this old fart think he is appreciated.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Re: A stop job is running for...

[Jape Person]

On 12/03/2015 05:22 AM, Himanshu Shekhar wrote:

The complete message is really important. Perhaps, I
would investigate.


Hello!

I did give the complete messages. Both start with

A stop job is running for...

The endings are

Make remote CUPS printers available locally

and

Network Time Synchronization

I've checked for CUPS and NTP errors in the logs and have found nothing. 
I presume that's because this happens during shutdown, but haven't done 
enough research to be sure.




Let me take this reply as an opportunity to ask two favors of you.

First, please don't reply directly to me or CC me. I'm subscribed to the 
list, so I get all replies. Replies to messages here should be responses 
to the list -- unless a poster specifically asks to be copied.


Second, please don't post html messages. They're very hard for people 
using textual interfaces to deal with, and the message I'm replying to 
was really hard to parse when creating a reply, even with Icedove, the 
mail client I'm using. (I do have Icedove set to display plain text. I 
could have it display html, but that would fly in the face of using it 
on this list.)


Regards,
JP

Re: A stop job is running for...

[David Wright]

On Wed 02 Dec 2015 at 16:59:23 (-0600), Don Armstrong wrote:
> On Wed, 02 Dec 2015, Jape Person wrote:
> > It's occurred to me that, though I have occasionally seen service
> > shutown issues with sysv-init, they were never as pervasive or
> > repetitve as it has been since switching to systemd as the init
> > system.
> 
> This is generally because sysv-init tends to not pay attention to
> whether a particular service has actually stopped. Many init scripts
> just send an appropriate signal, hope for the best, and return control.
>  
> If your goal is just to shutdown the system regardless of what is
> actually going on, that's great... but if you value your data, that's
> not really a workable solution.

Which data do you mean? By the time I instigate a shutdown, I've saved
my data and, if at home, copied to my server. So I'm hoping that's safe.

By the time these Stop jobs start running, there are just system
processes running. I don't really care about them as long as the
filesystems get unmounted. Almost anything is better than a forced
poweroff followed by fscking saying things at the next boot.

> That said, most of these cases are bugs, not really cases where the
> daemon is actually doing something; reporting the bugs when you run into
> them will help them get fixed.

At the time I had the timeout-increasing problem, I was still focussed
on getting Start jobs to succeed, particularly when the kernel
"forgot" to load binfmt_misc (for help on which, I thank you again).

Cheers,
David.

Re: A stop job is running for...

[Jape Person]

On 12/03/2015 01:00 PM, Michael Biebl wrote:

Am 03.12.2015 um 18:18 schrieb Jape Person:

A stop job is running for...

The endings are

Make remote CUPS printers available locally

and

Network Time Synchronization

I've checked for CUPS and NTP errors in the logs and have found nothing.
I presume that's because this happens during shutdown, but haven't done
enough research to be sure.


I would try the following as next steps.
Before shutting down, start the debug shell on tty9
# systemctl start debug-shell.service


Okay, this didn't go as I expected. When I tried to switch to tty9 I got 
a blank screen with a flashing underline cursor in the upper left corner.


I don't remember ever having looked at tty8 or tty9 before.

I tried to follow your directions as closely as possible by issuing the 
above command from the root account on tty6.


After I switched back to the GUI on tty7 and initiated the shutdown I 
was able to switch to tty9 where I was greeted by a root prompt from 
which I issued the commands below.




Then on shutdown switch to tty9 and save the output of
ps aux


USER   PID %CPU %MEMVSZ   RSS TTY  STAT START   TIME COMMAND
root 1  0.0  0.0 137820  5580 ?Ss   11:37   0:01 /sbin/init
root 2  0.0  0.0  0 0 ?S11:37   0:00 [kthreadd]
root 3  0.0  0.0  0 0 ?S11:37   0:00 
[ksoftirqd/0]
root 5  0.0  0.0  0 0 ?S<   11:37   0:00 
[kworker/0:0H]

root 7  0.0  0.0  0 0 ?S11:37   0:07 [rcu_sched]
root 8  0.0  0.0  0 0 ?S11:37   0:00 [rcu_bh]
root 9  0.0  0.0  0 0 ?S11:37   0:00 
[migration/0]
root10  0.0  0.0  0 0 ?S11:37   0:00 
[watchdog/0]
root11  0.0  0.0  0 0 ?S11:37   0:00 
[watchdog/1]
root12  0.0  0.0  0 0 ?S11:37   0:00 
[migration/1]
root13  0.0  0.0  0 0 ?S11:37   0:00 
[ksoftirqd/1]
root15  0.0  0.0  0 0 ?S<   11:37   0:00 
[kworker/1:0H]
root16  0.0  0.0  0 0 ?S11:37   0:00 
[watchdog/2]
root17  0.0  0.0  0 0 ?S11:37   0:00 
[migration/2]
root18  0.0  0.0  0 0 ?S11:37   0:00 
[ksoftirqd/2]
root20  0.0  0.0  0 0 ?S<   11:37   0:00 
[kworker/2:0H]
root21  0.0  0.0  0 0 ?S11:37   0:00 
[watchdog/3]
root22  0.0  0.0  0 0 ?S11:37   0:00 
[migration/3]
root23  0.0  0.0  0 0 ?S11:37   0:00 
[ksoftirqd/3]
root25  0.0  0.0  0 0 ?S<   11:37   0:00 
[kworker/3:0H]

root26  0.0  0.0  0 0 ?S<   11:37   0:00 [khelper]
root27  0.0  0.0  0 0 ?S11:37   0:00 [kdevtmpfs]
root28  0.0  0.0  0 0 ?S<   11:37   0:00 [netns]
root29  0.0  0.0  0 0 ?S<   11:37   0:00 [perf]
root30  0.0  0.0  0 0 ?S11:37   0:00 
[khungtaskd]

root31  0.0  0.0  0 0 ?S<   11:37   0:00 [writeback]
root33  0.0  0.0  0 0 ?SN   11:37   0:00 [ksmd]
root34  0.0  0.0  0 0 ?SN   11:37   0:00 
[khugepaged]

root35  0.0  0.0  0 0 ?S<   11:37   0:00 [crypto]
root36  0.0  0.0  0 0 ?S<   11:37   0:00 
[kintegrityd]

root37  0.0  0.0  0 0 ?S<   11:37   0:00 [bioset]
root38  0.0  0.0  0 0 ?S<   11:37   0:00 [kblockd]
root39  0.0  0.0  0 0 ?S<   11:37   0:00 
[devfreq_wq]

root41  0.0  0.0  0 0 ?S11:37   0:00 [kswapd0]
root42  0.0  0.0  0 0 ?S11:37   0:00 
[fsnotify_mark]

root48  0.0  0.0  0 0 ?S<   11:37   0:00 [kthrotld]
root50  0.0  0.0  0 0 ?S<   11:37   0:00 
[ipv6_addrconf]

root51  0.0  0.0  0 0 ?S<   11:37   0:00 [deferwq]
root82  0.0  0.0  0 0 ?S<   11:37   0:00 
[acpi_thermal_pm]
root83  0.0  0.0  0 0 ?S11:37   0:00 
[irq/16-mmc0]

root86  0.0  0.0  0 0 ?S<   11:37   0:00 [ata_sff]
root92  0.0  0.0  0 0 ?S11:37   0:00 [scsi_eh_0]
root93  0.0  0.0  0 0 ?S<   11:37   0:00 
[scsi_tmf_0]

root94  0.0  0.0  0 0 ?S11:37   0:00 [scsi_eh_1]
root95  0.0  0.0  0 0 ?S<   11:37   0:00 
[scsi_tmf_1]

root96  0.0  0.0  0 0 ?S11:37   0:00 [scsi_eh_2]
root97  0.0  0.0  0 0 ?S<   11:37   0:00 
[scsi_tmf_2]

root98  0.0  0.0  0 0 ?S11:37   0:00 [scsi_eh_3]
root99  0.0  0.0  0 0 ?S<   11:37   0:00 

Re: A stop job is running for...

[Michael Biebl]

Am 03.12.2015 um 21:21 schrieb Jape Person:

> /usr/sbin/cupsd -l
> root   715  0.0  0.1 250812  8680 ?Ssl  11:37   0:00
> /usr/sbin/cups-browsed
> lp 993  0.0  0.0  78772  5584 ?S11:38   0:00
> /usr/lib/cups/notifier/dbus dbus://
> root  1114  0.0  0.0  43828  3048 ?Ss   11:38   0:00
> wpa_supplicant -B -i wlan0 -c /var/lib/wicd/configurations/586d8facceba
> -Dwext
> lp1188  0.0  0.0  78772  5584 ?S11:38   0:00
> /usr/lib/cups/notifier/dbus dbus://
> root  1234  0.0  0.0  15020  1720 ?Ss   11:38   0:00
> /sbin/dhclient -v wlan0

That process output is interesting.

Two issues that come to mind here:
a/ cups-browsed.service declares a dependency on avahi-daemon.service.
So it should be stopped before avahi-daemon. But apparently you don't
have any avahi-daemon process anymore.
Would be interesting to find out, why avahi-daemon.service is stopped
before cups-browsed.
Can you paste the systemctl cat avahi-daemon.service cups-browsed.service
output

b/ you use wicd. I suspect wicd is stopped (too) early during shutdown
and tears down the network connection. Maybe that's related as well.

I wonder if we should take this off list now. Not sure if our debugging
session is interesting to the readers of this mailing list.

Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: A stop job is running for...

[Jape Person]

On 12/03/2015 01:23 PM, Rick Thomas wrote:

Hi JP

On Dec 3, 2015, at 9:18 AM, Jape Person  wrote:


On 12/03/2015 05:22 AM, Himanshu Shekhar wrote:

The complete message is really important. Perhaps, I would
investigate.


Hello!

I did give the complete messages. Both start with

A stop job is running for...

The endings are

Make remote CUPS printers available locally

and

Network Time Synchronization

I've checked for CUPS and NTP errors in the logs and have found
nothing. I presume that's because this happens during shutdown, but
haven't done enough research to be sure.




One thing that might help (you may already have done it, but it can’t
hurt to ask) is to make the systemd journal persistent.  This way you
can examine after the fact the log messages and other journal stuff
that occur during a system shutdown/restart.  You do that by doing

sudo mkdir /var/log/journal  # make the journal persistent

Then reboot.  After that you can do

sudo journalctl —list-boots

To see a list of boot numbers (32-digit hex IDs) for which the entire
journal is available along with the date/times of start and end.

To examine the journal for a particular boot number, use

sudo journalctl —boot=

This is all covered in the journalctl man page, which you’ve probably
read, but you might have missed those details.

Another hint about the systemd Journal (and log files in general):
when searching for messages relating to, for example, the ntp daemon,
it helps to use the “-i” (Ignore case) option.  Sometimes ntp is
spelled NTP in log messages.  Same goes for CUPS.

Enjoy! Rick



Thanks, Rick. I knew about the issue searching for different cases, and 
was vaguely aware that the journal could be made persistent. I don't 
actually see that particular info in the man page. Maybe I'll try to get 
some sleep and reread it more carefully.


Thanks again.

Re: A stop job is running for...

[Michael Biebl]

Am 03.12.2015 um 18:18 schrieb Jape Person:
> A stop job is running for...
> 
> The endings are
> 
> Make remote CUPS printers available locally
> 
> and
> 
> Network Time Synchronization
> 
> I've checked for CUPS and NTP errors in the logs and have found nothing.
> I presume that's because this happens during shutdown, but haven't done
> enough research to be sure.

I would try the following as next steps.
Before shutting down, start the debug shell on tty9
# systemctl start debug-shell.service

Then on shutdown switch to tty9 and save the output of
ps aux
systemctl list-jobs
systemctl status ntp cups-browsed

and maybe attach an strace to the process(es) which don't want to die.



-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: A stop job is running for...

[Rick Thomas]

Hi JP

On Dec 3, 2015, at 9:18 AM, Jape Person  wrote:

> On 12/03/2015 05:22 AM, Himanshu Shekhar wrote:
>> The complete message is really important. Perhaps, I
>> would investigate.
> 
> Hello!
> 
> I did give the complete messages. Both start with
> 
> A stop job is running for...
> 
> The endings are
> 
> Make remote CUPS printers available locally
> 
> and
> 
> Network Time Synchronization
> 
> I've checked for CUPS and NTP errors in the logs and have found nothing. I 
> presume that's because this happens during shutdown, but haven't done enough 
> research to be sure.
> 
> 

One thing that might help (you may already have done it, but it can’t hurt to 
ask) is to make the systemd journal persistent.  This way you can examine after 
the fact the log messages and other journal stuff that occur during a system 
shutdown/restart.  You do that by doing

sudo mkdir /var/log/journal  # make the journal persistent

Then reboot.  After that you can do

sudo journalctl —list-boots

To see a list of boot numbers (32-digit hex IDs) for which the entire journal 
is available along with the date/times of start and end.

To examine the journal for a particular boot number, use

sudo journalctl —boot=

This is all covered in the journalctl man page, which you’ve probably read, but 
you might have missed those details.

Another hint about the systemd Journal (and log files in general): when 
searching for messages relating to, for example, the ntp daemon, it helps to 
use the “-i” (Ignore case) option.  Sometimes ntp is spelled NTP in log 
messages.  Same goes for CUPS.

Enjoy!
Rick

Re: A stop job is running for...

[James P. Wallen]

On 12/02/2015 06:06 AM, Martin Read wrote:

On 02/12/15 03:07, James P. Wallen wrote:

Thanks for your response, Sven. It's nice to know that someone else has
seen this type of problem. I was thinking that this could be
self-inflicted. Perhaps that's a little less likely now.

So, is this behavior controlled by systemd?

I'm not trying to start a fracas. I'm really interested. What I'm asking
is, do I need to start poring over systemd documentation to see if there
might be a way to control this behavior?


If a stop job is taking two minutes, that suggests that the service has
one or more ExecStop lines defined in its service unit and that one of
those commands is taking an unduly long time to complete for some reason.

The default and per-service timeout values for stopping a service (after
which systemd gives up and sends fatal signals to all of the service's
processes) are configurable; see the systemd-system.conf(5) and
systemd.service(5) man pages for details.




I'm going to look into this right away and do some testing to see if I 
can fix the problems on my system.


Thanks!

Re: A stop job is running for...

[David Wright]

On Wed 02 Dec 2015 at 11:06:09 (+), Martin Read wrote:
> On 02/12/15 03:07, James P. Wallen wrote:
> >Thanks for your response, Sven. It's nice to know that someone else has
> >seen this type of problem. I was thinking that this could be
> >self-inflicted. Perhaps that's a little less likely now.
> >
> >So, is this behavior controlled by systemd?
> >
> >I'm not trying to start a fracas. I'm really interested. What I'm asking
> >is, do I need to start poring over systemd documentation to see if there
> >might be a way to control this behavior?
> 
> If a stop job is taking two minutes, that suggests that the service
> has one or more ExecStop lines defined in its service unit and that
> one of those commands is taking an unduly long time to complete for
> some reason.
> 
> The default and per-service timeout values for stopping a service
> (after which systemd gives up and sends fatal signals to all of the
> service's processes) are configurable; see the
> systemd-system.conf(5) and systemd.service(5) man pages for details.

I have observed behaviour where, when the time limit of 90 seconds is
reached, the limit increases by another 90 seconds and nothing else
happens (for hours). eg

[ <*> ] A stop job is running for Manage, Install and Generate Color Profiles 
(34min 54s / 36min)_

Fortunately, that hasn't happened for a few months. It's very
embarrassing when my laptop takes longer to close down than my
wife's W10.

Cheers,
David.

Re: A stop job is running for...

[Jape Person]

On 12/02/2015 06:06 AM, Martin Read wrote:

The default and per-service timeout values for stopping a service (after
which systemd gives up and sends fatal signals to all of the service's
processes) are configurable; see the systemd-system.conf(5) and
systemd.service(5) man pages for details.




This could be useful. Time to wade into the man pages. I'm grateful.

Re: A stop job is running for...

[Gene Heskett]

On Wednesday 02 December 2015 06:06:09 Martin Read wrote:

> On 02/12/15 03:07, James P. Wallen wrote:
> > Thanks for your response, Sven. It's nice to know that someone else
> > has seen this type of problem. I was thinking that this could be
> > self-inflicted. Perhaps that's a little less likely now.
> >
> > So, is this behavior controlled by systemd?
> >
> > I'm not trying to start a fracas. I'm really interested. What I'm
> > asking is, do I need to start poring over systemd documentation to
> > see if there might be a way to control this behavior?
>
> If a stop job is taking two minutes, that suggests that the service
> has one or more ExecStop lines defined in its service unit and that
> one of those commands is taking an unduly long time to complete for
> some reason.
>
> The default and per-service timeout values for stopping a service
> (after which systemd gives up and sends fatal signals to all of the
> service's processes) are configurable; see the systemd-system.conf(5)
> and systemd.service(5) man pages for details.

'scuse me, but shouldn't the errant process be fixed so it can stop and 
clean up after itself?  Thats the real bug here.


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Re: A stop job is running for...

[Jape Person]

On 12/02/2015 10:49 AM, David Wright wrote:

On Wed 02 Dec 2015 at 11:06:09 (+), Martin Read wrote:

On 02/12/15 03:07, James P. Wallen wrote:

Thanks for your response, Sven. It's nice to know that someone else has
seen this type of problem. I was thinking that this could be
self-inflicted. Perhaps that's a little less likely now.

So, is this behavior controlled by systemd?

I'm not trying to start a fracas. I'm really interested. What I'm asking
is, do I need to start poring over systemd documentation to see if there
might be a way to control this behavior?


If a stop job is taking two minutes, that suggests that the service
has one or more ExecStop lines defined in its service unit and that
one of those commands is taking an unduly long time to complete for
some reason.

The default and per-service timeout values for stopping a service
(after which systemd gives up and sends fatal signals to all of the
service's processes) are configurable; see the
systemd-system.conf(5) and systemd.service(5) man pages for details.


I have observed behaviour where, when the time limit of 90 seconds is
reached, the limit increases by another 90 seconds and nothing else
happens (for hours). eg

[ <*> ] A stop job is running for Manage, Install and Generate Color Profiles 
(34min 54s / 36min)_

Fortunately, that hasn't happened for a few months. It's very
embarrassing when my laptop takes longer to close down than my
wife's W10.

Cheers,
David.



Now *that* would be annoying.

It's interesting that I have been unable to find bug reports about this. 
I guess it might be kind of hard to figure which packages to file a 
report against. I can imagine there might be a bit of finger-pointing 
between the systemd folks and the developers and maintainers of the 
various packages services when unfortunate interactions via the service 
units are hard to tease out.


It is at least nice to have a way to force an errant service to shut 
down -- assuming the scheme works. I haven't experimented yet, but 
that's on the schedule for later today. I suppose it's unlikely that 
forcing a service like CUPS or NTP to shut down will lead to other 
problems. I hope.

Re: A stop job is running for...

[Jape Person]

On 12/02/2015 12:17 PM, Michael Biebl wrote:

Am 02.12.2015 um 18:05 schrieb Jape Person:

On 12/02/2015 10:49 AM, David Wright wrote:

I have observed behaviour where, when the time limit of 90 seconds is
reached, the limit increases by another 90 seconds and nothing else
happens (for hours). eg

[ <*> ] A stop job is running for Manage, Install and Generate Color
Profiles (34min 54s / 36min)_

Fortunately, that hasn't happened for a few months. It's very
embarrassing when my laptop takes longer to close down than my
wife's W10.


Sounds like it could be hard to reproduce indeed.


Now *that* would be annoying.


In case you run into such a situation again, where a service is blocking
the shutdown you can of course just use force and pull the plug or use
sysrq b.
But there is a nicer alternative: just hit ctrl+alt+del quickly 7 times.
systemd then will initiate a forced shutdown. See [1].

Regards,
Michael


http://www.freedesktop.org/software/systemd/man/systemd.html#SIGINT



Seven times. How lucky!

Heh.

Thank you, Michael.

Do you think it's better just force the shutdown than to rummage around 
in the service unit files? I'm loath to edit system configuration files 
unless it's to configure something like smartmontools or some such -- 
you know, something that is more ordinarily edited in order to get it to 
do some specific job.


I guess that argument could apply to service units, but I'm not used to 
this stuff, yet.


Thanks again,
JP

Re: A stop job is running for...

[Michael Biebl]

Am 02.12.2015 um 18:05 schrieb Jape Person:
> On 12/02/2015 10:49 AM, David Wright wrote:
>> I have observed behaviour where, when the time limit of 90 seconds is
>> reached, the limit increases by another 90 seconds and nothing else
>> happens (for hours). eg
>>
>> [ <*> ] A stop job is running for Manage, Install and Generate Color
>> Profiles (34min 54s / 36min)_
>>
>> Fortunately, that hasn't happened for a few months. It's very
>> embarrassing when my laptop takes longer to close down than my
>> wife's W10.

Sounds like it could be hard to reproduce indeed.

> Now *that* would be annoying.

In case you run into such a situation again, where a service is blocking
the shutdown you can of course just use force and pull the plug or use
sysrq b.
But there is a nicer alternative: just hit ctrl+alt+del quickly 7 times.
systemd then will initiate a forced shutdown. See [1].

Regards,
Michael


http://www.freedesktop.org/software/systemd/man/systemd.html#SIGINT
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: A stop job is running for...

[Jape Person]

On 12/02/2015 01:21 PM, Gene Heskett wrote:

On Wednesday 02 December 2015 06:06:09 Martin Read wrote:


On 02/12/15 03:07, James P. Wallen wrote:

Thanks for your response, Sven. It's nice to know that someone else
has seen this type of problem. I was thinking that this could be
self-inflicted. Perhaps that's a little less likely now.

So, is this behavior controlled by systemd?

I'm not trying to start a fracas. I'm really interested. What I'm
asking is, do I need to start poring over systemd documentation to
see if there might be a way to control this behavior?


If a stop job is taking two minutes, that suggests that the service
has one or more ExecStop lines defined in its service unit and that
one of those commands is taking an unduly long time to complete for
some reason.

The default and per-service timeout values for stopping a service
(after which systemd gives up and sends fatal signals to all of the
service's processes) are configurable; see the systemd-system.conf(5)
and systemd.service(5) man pages for details.


'scuse me, but shouldn't the errant process be fixed so it can stop and
clean up after itself?  Thats the real bug here.


Cheers, Gene Heskett



It's occurred to me that, though I have occasionally seen service 
shutown issues with sysv-init, they were never as pervasive or repetitve 
as it has been since switching to systemd as the init system. And the 
issue seems to be happening with several different types of services. 
That at least begs the question as to whether the problem is really with 
the services themselves or with the way they are controlled by systemd.


I'm guessing that this is just a sort of shakedown cruise problem, where 
it may be that those who develop and maintain some packages will have to 
customize those packages' service units to work properly with systemd OR 
that there are problems with systemd itself OR both.


Or maybe end users like me just need to learn to deal with systemd. 
However, the idea of having end users edit service units hardly seems 
like an ideal routine.


Regards,
JP

Re: A stop job is running for...

[Michael Biebl]

Am 02.12.2015 um 18:58 schrieb Jape Person:
> On 12/02/2015 12:17 PM, Michael Biebl wrote:
>> In case you run into such a situation again, where a service is blocking
>> the shutdown you can of course just use force and pull the plug or use
>> sysrq b.
>> But there is a nicer alternative: just hit ctrl+alt+del quickly 7 times.
>> systemd then will initiate a forced shutdown. See [1].

..

> Do you think it's better just force the shutdown than to rummage around
> in the service unit files? I'm loath to edit system configuration files
> unless it's to configure something like smartmontools or some such --
> you know, something that is more ordinarily edited in order to get it to
> do some specific job.
> 
> I guess that argument could apply to service units, but I'm not used to
> this stuff, yet.

In your case it seems to happen much more often, that the service does
not shutdown in a timely manner. So this should actually be investigated
properly.

My remark regarding using a forced shutdown via ctrl+alt+-del is only
supposed to be a fix for very rare cases.

I also wouldn't consider it a proper fix to simply decrease the shutdown
timeout of the affected service. That's a hack at best.

Michael


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: A stop job is running for...

[Jape Person]

On 12/02/2015 02:04 PM, Michael Biebl wrote:

Am 02.12.2015 um 18:58 schrieb Jape Person:

On 12/02/2015 12:17 PM, Michael Biebl wrote:

In case you run into such a situation again, where a service is blocking
the shutdown you can of course just use force and pull the plug or use
sysrq b.
But there is a nicer alternative: just hit ctrl+alt+del quickly 7 times.
systemd then will initiate a forced shutdown. See [1].


..


Do you think it's better just force the shutdown than to rummage around
in the service unit files? I'm loath to edit system configuration files
unless it's to configure something like smartmontools or some such --
you know, something that is more ordinarily edited in order to get it to
do some specific job.

I guess that argument could apply to service units, but I'm not used to
this stuff, yet.


In your case it seems to happen much more often, that the service does
not shutdown in a timely manner. So this should actually be investigated
properly.



Aye, there's the rub!

The phrase "investigated properly" would seem to indicate that someone 
who knows what s/he's doing would be performing the analysis.


How about me doing my usual thumb-fingered job on it, and then coming 
back here for advice when I have enough bruises on my forehead to prove 
that I have indeed been to the wall?


;-)


My remark regarding using a forced shutdown via ctrl+alt+-del is only
supposed to be a fix for very rare cases.

I also wouldn't consider it a proper fix to simply decrease the shutdown
timeout of the affected service. That's a hack at best.

Michael




Yes, I was beginning to be dimly aware. I don't like futzing around with 
files in system or root owned areas unless they are designed to be 
futzed with. Not only because I don't like having my modifications 
overwritten during upgrades (and I do always choose to write the 
maintainer's upgrade over my modification and then change it again as 
necessary), but also because I don't like knowing that all sorts of 
weird stuff might happen if I do something particularly stupid.


I am, after all, very experienced and accomplished at being particularly 
stupid. It's why I run testing. I like having a plausible explanation, 
other than my own ineptitude, for having things go wrong.


Have a nice day!

JP

Re: A stop job is running for...

[Don Armstrong]

On Wed, 02 Dec 2015, Jape Person wrote:
> It's occurred to me that, though I have occasionally seen service
> shutown issues with sysv-init, they were never as pervasive or
> repetitve as it has been since switching to systemd as the init
> system.

This is generally because sysv-init tends to not pay attention to
whether a particular service has actually stopped. Many init scripts
just send an appropriate signal, hope for the best, and return control.
 
If your goal is just to shutdown the system regardless of what is
actually going on, that's great... but if you value your data, that's
not really a workable solution.

That said, most of these cases are bugs, not really cases where the
daemon is actually doing something; reporting the bugs when you run into
them will help them get fixed.

-- 
Don Armstrong  http://www.donarmstrong.com

"You know," said Arthur, "it's at times like this, when I'm trapped in
a Vogon airlock with a man from Betelgeuse, and about to die from
asphyxiation in deep space that I really wish I'd listened to what my
mother told me when I was young."
"Why, what did she tell you?"
"I don't know, I didn't listen."
 –- Douglas Adams _The Hitchhikers Guide To The Galaxy_

Re: A stop job is running for...

[Gene Heskett]

On Wednesday 02 December 2015 14:02:50 Jape Person wrote:

> On 12/02/2015 01:21 PM, Gene Heskett wrote:
> > On Wednesday 02 December 2015 06:06:09 Martin Read wrote:
> >> On 02/12/15 03:07, James P. Wallen wrote:
> >>> Thanks for your response, Sven. It's nice to know that someone
> >>> else has seen this type of problem. I was thinking that this could
> >>> be self-inflicted. Perhaps that's a little less likely now.
> >>>
> >>> So, is this behavior controlled by systemd?
> >>>
> >>> I'm not trying to start a fracas. I'm really interested. What I'm
> >>> asking is, do I need to start poring over systemd documentation to
> >>> see if there might be a way to control this behavior?
> >>
> >> If a stop job is taking two minutes, that suggests that the service
> >> has one or more ExecStop lines defined in its service unit and that
> >> one of those commands is taking an unduly long time to complete for
> >> some reason.
> >>
> >> The default and per-service timeout values for stopping a service
> >> (after which systemd gives up and sends fatal signals to all of the
> >> service's processes) are configurable; see the
> >> systemd-system.conf(5) and systemd.service(5) man pages for
> >> details.
> >
> > 'scuse me, but shouldn't the errant process be fixed so it can stop
> > and clean up after itself?  Thats the real bug here.
> >
> >
> > Cheers, Gene Heskett
>
> It's occurred to me that, though I have occasionally seen service
> shutown issues with sysv-init, they were never as pervasive or
> repetitve as it has been since switching to systemd as the init
> system. And the issue seems to be happening with several different
> types of services. That at least begs the question as to whether the
> problem is really with the services themselves or with the way they
> are controlled by systemd.
>
> I'm guessing that this is just a sort of shakedown cruise problem,
> where it may be that those who develop and maintain some packages will
> have to customize those packages' service units to work properly with
> systemd OR that there are problems with systemd itself OR both.
>
> Or maybe end users like me just need to learn to deal with systemd.
> However, the idea of having end users edit service units hardly seems
> like an ideal routine.
>
> Regards,
> JP

I can agree with that. I can hack up a bash script now & then, but 
wholesale patching really is the sources problem once he/she is aware 
there is a problem.  But it bugs the heck out of me that the guy/gal 
doing the codeing doesn't watch the user lists, so it all has to wait on 
someone qualified enough to wade thru the bug reporter forms and 
actually file the bug.  Thats quite often a week or more additional 
delay before they are aware that there really is a problem.

In the meantime, its hit another 200 users, discouraging them from ever 
touching linux again.  In that regard, we are our own worst enemy at 
times.  Unfortunately, the oar I steer this ship with could be swapped 
for a toothpick and have exactly the same result.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Re: A stop job is running for...

[Neal P. Murphy]

On Thu, 3 Dec 2015 15:48:07 +1300
Chris Bannister  wrote:

> On Wed, Dec 02, 2015 at 08:12:24PM -0500, Gene Heskett wrote:
> > 
> > In the meantime, its hit another 200 users, discouraging them from ever 
> > touching linux again.  In that regard, we are our own worst enemy at 
> > times.  Unfortunately, the oar I steer this ship with could be swapped 
> > for a toothpick and have exactly the same result.
> 
> Or you could be in the Windoze world ' stuck up *cough* *cough* 
> *whistle* *whistle* ... with no paddle.' :)
> 

And half a gnu.

Re: A stop job is running for...

[Gene Heskett]

On Wednesday 02 December 2015 21:48:07 Chris Bannister wrote:

> On Wed, Dec 02, 2015 at 08:12:24PM -0500, Gene Heskett wrote:
> > In the meantime, its hit another 200 users, discouraging them from
> > ever touching linux again.  In that regard, we are our own worst
> > enemy at times.  Unfortunately, the oar I steer this ship with could
> > be swapped for a toothpick and have exactly the same result.
>
> Or you could be in the Windoze world ' stuck up *cough* *cough*
> *whistle* *whistle* ... with no paddle.' :)

Why the heck to do think I'm here Chris?  I don't allow winderz on the 
property unless I get suckered into trying to fix a box full of viri and 
keyloggers they picked up while trolling for good porn or the next get 
rich quick scheme?  I've already been there, done that, skipped the 
T-shirt, and swore I'd never do that again.  I have come to the 
conclusion that winderz lusers deserve what they get.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Re: A stop job is running for...

[Gene Heskett]

On Wednesday 02 December 2015 22:05:10 Neal P. Murphy wrote:

> On Thu, 3 Dec 2015 15:48:07 +1300
>
> Chris Bannister  wrote:
> > On Wed, Dec 02, 2015 at 08:12:24PM -0500, Gene Heskett wrote:
> > > In the meantime, its hit another 200 users, discouraging them from
> > > ever touching linux again.  In that regard, we are our own worst
> > > enemy at times.  Unfortunately, the oar I steer this ship with
> > > could be swapped for a toothpick and have exactly the same result.
> >
> > Or you could be in the Windoze world ' stuck up *cough* *cough*
> > *whistle* *whistle* ... with no paddle.' :)
>
> And half a gnu.

And how is that best done on the barbie?

Sorry, couldn't resist, must do better.  Or do I get the Senior Citizen 
discount on this stuff?  As probably the oldest subscriber to this list 
at 81, does that count?  Or is there someone older yet?  ;-)

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Re: A stop job is running for...

[Nicolas George]

Le duodi 12 frimaire, an CCXXIV, Gene Heskett a écrit :
>  But it bugs the heck out of me that the guy/gal 
> doing the codeing doesn't watch the user lists, so it all has to wait on 
> someone qualified enough to wade thru the bug reporter forms and 
> actually file the bug.

Developer time is valuable.

> Thats quite often a week or more additional 
> delay before they are aware that there really is a problem.

Regarding support with guaranteed reaction time, you get exactly your
money's worth: 0.

> In the meantime, its hit another 200 users, discouraging them from ever 
> touching linux again.

If these people are so easily discouraged, and especially definitively
discouraged, they probably belong to the kind of people who only ever
complain and never contribute back. Maybe the community is better without
them.

> Unfortunately, the oar I steer this ship with could be swapped 
> for a toothpick and have exactly the same result.

Libre Software development is a meritocracy, not a democracy. Your oar is
exactly how large you make it. That means Linus' is larger than yours, of
course, and that is only right. I am still writing about steering oar.

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature

Re: A stop job is running for...

[Chris Bannister]

On Wed, Dec 02, 2015 at 08:12:24PM -0500, Gene Heskett wrote:
> 
> In the meantime, its hit another 200 users, discouraging them from ever 
> touching linux again.  In that regard, we are our own worst enemy at 
> times.  Unfortunately, the oar I steer this ship with could be swapped 
> for a toothpick and have exactly the same result.

Or you could be in the Windoze world ' stuck up *cough* *cough* 
*whistle* *whistle* ... with no paddle.' :)

-- 
"If you're not careful, the newspapers will have you hating the people
who are being oppressed, and loving the people who are doing the 
oppressing." --- Malcolm X

Re: A stop job is running for...

[Jape Person]

On 12/02/2015 05:59 PM, Don Armstrong wrote:

On Wed, 02 Dec 2015, Jape Person wrote:

It's occurred to me that, though I have occasionally seen service
shutown issues with sysv-init, they were never as pervasive or
repetitve as it has been since switching to systemd as the init
system.


This is generally because sysv-init tends to not pay attention to
whether a particular service has actually stopped. Many init scripts
just send an appropriate signal, hope for the best, and return control.



Yes, that was my understanding. Sysv-init worked just fine for my my use 
cases, but I can easily see that the arrangement might not work so well 
for something like, say, a print server.



If your goal is just to shutdown the system regardless of what is
actually going on, that's great... but if you value your data, that's
not really a workable solution.

That said, most of these cases are bugs, not really cases where the
daemon is actually doing something; reporting the bugs when you run into
them will help them get fixed.



I finally found this older thread(1) which gave me some ideas as to how 
to proceed in trying to find the cause of the issue.


I want to be useful, but it takes a bit of time for those of us who 
fumble about in darkness to find the walls. We have to find one of those 
before we stand a chance of getting to the cave entrance. I may return 
if I don't first impale myself on a stalagmite.


;-)

JP

(1) https://bugzilla.redhat.com/show_bug.cgi?id=1044602

Re: A stop job is running for...

[Martin Read]

On 02/12/15 03:07, James P. Wallen wrote:

Thanks for your response, Sven. It's nice to know that someone else has
seen this type of problem. I was thinking that this could be
self-inflicted. Perhaps that's a little less likely now.

So, is this behavior controlled by systemd?

I'm not trying to start a fracas. I'm really interested. What I'm asking
is, do I need to start poring over systemd documentation to see if there
might be a way to control this behavior?


If a stop job is taking two minutes, that suggests that the service has 
one or more ExecStop lines defined in its service unit and that one of 
those commands is taking an unduly long time to complete for some reason.


The default and per-service timeout values for stopping a service (after 
which systemd gives up and sends fatal signals to all of the service's 
processes) are configurable; see the systemd-system.conf(5) and 
systemd.service(5) man pages for details.

Re: A stop job is running for...

[James P. Wallen]

On 12/01/2015 09:47 AM, Sven Arvidsson wrote:

On Mon, 2015-11-30 at 21:04 -0500, Jape Person wrote:

Make remote CUPS printers available locally
Network Time Synchronization

For several weeks I've been seeing this stop job notification for
these
two items frequently when rebooting or shutting down two of my four
testing systems.

The first notification counts all the way up to 1 min 30 sec before
the
shutdown scroll restarts. The second notification only counts for a
few
seconds before terminating.

I'm a patient guy, but adding almost two minutes to almost every
restart
or shutdown procedure gets a bit tedious after a while.


Yes, I have noticed this too, but with different services. So it's
probably not specific to CUPS or NTP.

Unfortunately it seems to always happen when I need to shutdown quickly
(thunderstorms). Would be great if it was possible to configure the
countdown to simply kill the service after a few seconds and proceed
with shutdown/reboot.



Thanks for your response, Sven. It's nice to know that someone else has 
seen this type of problem. I was thinking that this could be 
self-inflicted. Perhaps that's a little less likely now.


So, is this behavior controlled by systemd?

I'm not trying to start a fracas. I'm really interested. What I'm asking 
is, do I need to start poring over systemd documentation to see if there 
might be a way to control this behavior?

Re: A stop job is running for...

[Sven Arvidsson]

On Mon, 2015-11-30 at 21:04 -0500, Jape Person wrote:
> Make remote CUPS printers available locally
> Network Time Synchronization
> 
> For several weeks I've been seeing this stop job notification for
> these 
> two items frequently when rebooting or shutting down two of my four 
> testing systems.
> 
> The first notification counts all the way up to 1 min 30 sec before
> the 
> shutdown scroll restarts. The second notification only counts for a
> few 
> seconds before terminating.
> 
> I'm a patient guy, but adding almost two minutes to almost every
> restart 
> or shutdown procedure gets a bit tedious after a while.

Yes, I have noticed this too, but with different services. So it's
probably not specific to CUPS or NTP.

Unfortunately it seems to always happen when I need to shutdown quickly
(thunderstorms). Would be great if it was possible to configure the
countdown to simply kill the service after a few seconds and proceed
with shutdown/reboot.

-- 
Cheers,
Sven Arvidsson
http://www.whiz.se
PGP Key ID 6FAB5CD5





signature.asc
Description: This is a digitally signed message part