[opensuse] Stop Jobs taking too long
Today, I started seeing stop jobs taking too long on my 42.2 system. For example Samba NMB counted down the entire 1:30 seconds before system[some letter we dare not mention] killed it. There are no actual stop job defined for nmb.service The prior shutdown wanted to count down 5 minutes to shutdown modemmanager.service. (the service file shows no stop job defined). There's no configuration specifying a 5 minute timeout on anything. (Side issue: why is modemmanager wanted by multiuser.target?) What is up with the stop jobs suddenly taking so long? I wasn't aware this was changed in any recent update. -- After all is said and done, more is said than done. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
John Andersen composed on 2017-07-21 11:58 (UTC-0700):
Today, I started seeing stop jobs taking too long on my 42.2 system.
For example Samba NMB counted down the entire 1:30 seconds before system[some letter we dare not mention] killed it. There are no actual stop job defined for nmb.service
The prior shutdown wanted to count down 5 minutes to shutdown modemmanager.service. (the service file shows no stop job defined). There's no configuration specifying a 5 minute timeout on anything.
(Side issue: why is modemmanager wanted by multiuser.target?)
If like most users you are on broadband behind a firewall/router, why is modemmanager even installed?
What is up with the stop jobs suddenly taking so long? I wasn't aware this was changed in any recent update.
I've often found that stop jobs delay shutdown on various installations. Figuring out exactly why I've never pursued, but NAICT it is a typical result of network start jobs that never took place that systemd thinks need stopping. NMB is one I particularly remember seeing far too often. Does 'umount -a' prior to attempting shutdown help? -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 07/21/2017 01:39 PM, Felix Miata wrote:
If like most users you are on broadband behind a firewall/router, why is modemmanager even installed?
Good question. At one time it was required, and attempting to remove it wanted to remove all of Plasma5. I see that dependency has been fixed. I haven't used a modem (even though this machine has one) in 15 years. I'll try the uninstall. The NMB issue did not re-occur after reboot and re-shutdown. -- After all is said and done, more is said than done. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 07/21/2017 04:44 PM, John Andersen wrote:
I see that dependency has been fixed. I haven't used a modem (even though this machine has one) in 15 years. I'll try the uninstall.
Let us know how it goes. I had such a problem with the following file: /usr/share/dbus-1/system-services/org.freedesktop.ModemManager1.service I would move it to a /sav dir in .profile and restore it on logout. I can't for the life of me recall why, I'll have to search the list, but I think it was causing an issue with gvfs, but that may just be senility creeping in. Or there was an error with a value of '0' instead of '1' generated in the journal?? I no longer move/restore it, so the issue must have been fixed. I think it may have been a question to the gphoto list the Mr. Meissner helped with, but since switching Tbird to imap instead of pop, I no longer have the old messages. I think I looked into removing ModemManager (even not having Plasma installed), and at the time it would have been a dependency fiasco. (thus my interest in how your attempt goes :) -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2017-07-21 22:39, Felix Miata wrote:
John Andersen composed on 2017-07-21 11:58 (UTC-0700):
(Side issue: why is modemmanager wanted by multiuser.target?)
If like most users you are on broadband behind a firewall/router, why is modemmanager even installed?
I think it is used for some network connections, like using an USB cable to tether to an android mobile phone. If I remember to do it I can verify with my laptop one day.
What is up with the stop jobs suddenly taking so long? I wasn't aware this was changed in any recent update.
I've often found that stop jobs delay shutdown on various installations. Figuring out exactly why I've never pursued, but NAICT it is a typical result of network start jobs that never took place that systemd thinks need stopping. NMB is one I particularly remember seeing far too often. Does 'umount -a' prior to attempting shutdown help?
Sometimes the network is killed and then systemd decides to umount some remote filesystem, which of course will fail (timeout). -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
On Saturday, 22 July 2017 22:57:09 ACST Carlos E. R. wrote:
On 2017-07-21 22:39, Felix Miata wrote:
John Andersen composed on 2017-07-21 11:58 (UTC-0700):
(Side issue: why is modemmanager wanted by multiuser.target?)
If like most users you are on broadband behind a firewall/router, why is modemmanager even installed?
I think it is used for some network connections, like using an USB cable to tether to an android mobile phone.
If I remember to do it I can verify with my laptop one day.
What is up with the stop jobs suddenly taking so long? I wasn't aware this was changed in any recent update.
I've often found that stop jobs delay shutdown on various installations. Figuring out exactly why I've never pursued, but NAICT it is a typical result of network start jobs that never took place that systemd thinks need stopping. NMB is one I particularly remember seeing far too often. Does 'umount -a' prior to attempting shutdown help?
Sometimes the network is killed and then systemd decides to umount some remote filesystem, which of course will fail (timeout).
Yes, this was an issue during the transition from the older network infrastructure to wicked - the wicked network services were being shut down before all remote filesystems were unmounted - but this was supposed to be fixed over a year ago. I haven’t seen this happen for at least that long. -- ============================================================== Rodney Baker VK5ZTV rodney.baker@iinet.net.au ============================================================== -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
John Andersen wrote:
Today, I started seeing stop jobs taking too long on my 42.2 system.
TBH, for this is one of the most annoying features of systemd: Quite sometimes I have issues like a forgotten login on another console, or a (manually mounted) NFS directory. Then the reboot stops. Which is OK. BUT: You can do absolutely NOTHING. all login is already disabled, both on other ttys or via ssh. It's abolutely pointless to wait for something to happen that cures the issue. As a consequence I've reduced the wait time for stop jobs...
For example Samba NMB counted down the entire 1:30 seconds before system[some letter we dare not mention] killed it. There are no actual stop job defined for nmb.service
Sounds like a case similar to my NFS mount above - was there some remote samba access still active?
What is up with the stop jobs suddenly taking so long? I wasn't aware this was changed in any recent update.
Haven't noticed this on my Leap systems, so I rather think there's something changed in your local (network) setup that is triggering it... -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Additional question: Does anybody know where the waittime of this stopjobs is defined ? Op 25-07-17 14:05, Peter Suetterlin schreef:
John Andersen wrote:
Today, I started seeing stop jobs taking too long on my 42.2 system. TBH, for this is one of the most annoying features of systemd: Quite sometimes I have issues like a forgotten login on another console, or a (manually mounted) NFS directory.
Then the reboot stops. Which is OK. BUT: You can do absolutely NOTHING. all login is already disabled, both on other ttys or via ssh. It's abolutely pointless to wait for something to happen that cures the issue.
As a consequence I've reduced the wait time for stop jobs...
For example Samba NMB counted down the entire 1:30 seconds before system[some letter we dare not mention] killed it. There are no actual stop job defined for nmb.service Sounds like a case similar to my NFS mount above - was there some remote samba access still active?
What is up with the stop jobs suddenly taking so long? I wasn't aware this was changed in any recent update. Haven't noticed this on my Leap systems, so I rather think there's something changed in your local (network) setup that is triggering it...
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Hit 7 times alt-ctrl-del, the shutdown will continue. On 07/25/2017 03:07 PM, Hans de Faber wrote:
Additional question:
Does anybody know where the waittime of this stopjobs is defined ?
Op 25-07-17 14:05, Peter Suetterlin schreef:
John Andersen wrote:
Today, I started seeing stop jobs taking too long on my 42.2 system. TBH, for this is one of the most annoying features of systemd: Quite sometimes I have issues like a forgotten login on another console, or a (manually mounted) NFS directory.
Then the reboot stops. Which is OK. BUT: You can do absolutely NOTHING. all login is already disabled, both on other ttys or via ssh. It's abolutely pointless to wait for something to happen that cures the issue.
As a consequence I've reduced the wait time for stop jobs...
For example Samba NMB counted down the entire 1:30 seconds before system[some letter we dare not mention] killed it. There are no actual stop job defined for nmb.service Sounds like a case similar to my NFS mount above - was there some remote samba access still active?
What is up with the stop jobs suddenly taking so long? I wasn't aware this was changed in any recent update. Haven't noticed this on my Leap systems, so I rather think there's something changed in your local (network) setup that is triggering it...
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Carlos E. R. composed on 2017-07-25 17:54 (UTC+0200):
Marco Brignoli wrote:
Hit 7 times alt-ctrl-del, the shutdown will continue.
Has to be seven? I never knew about this "feature".
7 or more, but it only works sometimes, and often far short of instantly as it claims when keyed. If the shutdown obstacles include failing to write sound card config or stopping various services that never started in the first place, then it doesn't help at all. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
I have to systematically use this "feature" on a server is not willing to shut-down an lvm partition (no idea why), and it works. However I fully agree that where hardware is involved the results are unpredictable. Marco On 07/25/2017 07:30 PM, Felix Miata wrote:
Carlos E. R. composed on 2017-07-25 17:54 (UTC+0200):
Marco Brignoli wrote:
Hit 7 times alt-ctrl-del, the shutdown will continue. Has to be seven? I never knew about this "feature". 7 or more, but it only works sometimes, and often far short of instantly as it claims when keyed. If the shutdown obstacles include failing to write sound card config or stopping various services that never started in the first place, then it doesn't help at all.
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2017-07-26 09:10, Marco Brignoli wrote:
On 07/25/2017 07:30 PM, Felix Miata wrote:
Carlos E. R. composed on 2017-07-25 17:54 (UTC+0200):
Hit 7 times alt-ctrl-del, the shutdown will continue. Has to be seven? I never knew about this "feature". 7 or more, but it only works sometimes, and often far short of instantly as it claims when keyed. If the shutdown obstacles include failing to write sound card config or stopping various services that never started in the first
Marco Brignoli wrote: place, then it doesn't help at all.
I have to systematically use this "feature" on a server is not willing to shut-down an lvm partition (no idea why), and it works.
However I fully agree that where hardware is involved the results are unpredictable.
I'll try next time if I remember. Till now I pulled the cable. Or the main power switch, and endure the long fsck afterwards. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" (Minas Tirith))
On 07/26/2017 05:13 AM, Carlos E. R. wrote:
On 2017-07-26 09:10, Marco Brignoli wrote:
On 07/25/2017 07:30 PM, Felix Miata wrote:
Carlos E. R. composed on 2017-07-25 17:54 (UTC+0200):
Hit 7 times alt-ctrl-del, the shutdown will continue. Has to be seven? I never knew about this "feature". 7 or more, but it only works sometimes, and often far short of instantly as it claims when keyed. If the shutdown obstacles include failing to write sound card config or stopping various services that never started in the first
Marco Brignoli wrote: place, then it doesn't help at all.
I have to systematically use this "feature" on a server is not willing to shut-down an lvm partition (no idea why), and it works.
However I fully agree that where hardware is involved the results are unpredictable.
I'll try next time if I remember. Till now I pulled the cable. Or the main power switch, and endure the long fsck afterwards.
Alt-SysRq reisub doesn't work? -- -Gerry Makaro aka Fraser_Bell on the forums, IRC, and mail at openSUSE.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2017-07-26 22:42, Fraser_Bell wrote:
On 07/26/2017 05:13 AM, Carlos E. R. wrote:
On 2017-07-26 09:10, Marco Brignoli wrote:
On 07/25/2017 07:30 PM, Felix Miata wrote:
Carlos E. R. composed on 2017-07-25 17:54 (UTC+0200):
Hit 7 times alt-ctrl-del, the shutdown will continue. Has to be seven? I never knew about this "feature". 7 or more, but it only works sometimes, and often far short of instantly as it claims when keyed. If the shutdown obstacles include failing to write sound card config or stopping various services that never started in the first
Marco Brignoli wrote: place, then it doesn't help at all.
I have to systematically use this "feature" on a server is not willing to shut-down an lvm partition (no idea why), and it works.
However I fully agree that where hardware is involved the results are unpredictable.
I'll try next time if I remember. Till now I pulled the cable. Or the main power switch, and endure the long fsck afterwards.
Alt-SysRq reisub doesn't work?
I never managed to do it. I need to write the procedure in a paper stuck to the machine near the button :-p or I'll never remember how to do it. I think I tried once, did not work, years ago. Doesn't it have to be enabled? -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" (Minas Tirith))
On 07/26/2017 02:28 PM, Carlos E. R. wrote:
Alt-SysRq reisub doesn't work?
I never managed to do it. I need to write the procedure in a paper stuck to the machine near the button :-p or I'll never remember how to do it. I think I tried once, did not work, years ago. Doesn't it have to be enabled?
Check: cat /proc/sys/kernel/sysrq *returns 0 if not enabled In openSUSE, probably returns 184 or similar, partially enabled, This does not allow control of keyboard, but it *does* allow sync, remount read-only, and signalling of processes (term, kill, oom-kill). However, it also *does not* allow reboot/poweroff (the "b" in "reisub"). To get full SysRq features, issue (as root): echo 1 > /proc/sys/kernel/sysrq I understand the reasoning to the default, but on a machine that I allow no physical access to anyone else, I set that to full features after I install openSUSE. Much more convenient and cleaner when it is required. -- -Gerry Makaro aka Fraser_Bell on the forums, IRC, and mail at openSUSE.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2017-07-28 03:30, Fraser_Bell wrote:
On 07/26/2017 02:28 PM, Carlos E. R. wrote:
Alt-SysRq reisub doesn't work?
I never managed to do it. I need to write the procedure in a paper stuck to the machine near the button :-p or I'll never remember how to do it. I think I tried once, did not work, years ago. Doesn't it have to be enabled?
Check: cat /proc/sys/kernel/sysrq *returns 0 if not enabled
In openSUSE, probably returns 184 or similar, partially enabled,
...
Much more convenient and cleaner when it is required.
Thanks, I'll save this :-) -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" (Minas Tirith))
On 07/26/2017 02:28 PM, Carlos E. R. wrote:
On 2017-07-26 22:42, Fraser_Bell wrote:
On 07/26/2017 05:13 AM, Carlos E. R. wrote:
On 2017-07-26 09:10, Marco Brignoli wrote:
On 07/25/2017 07:30 PM, Felix Miata wrote:
Carlos E. R. composed on 2017-07-25 17:54 (UTC+0200):
Marco Brignoli wrote: > Hit 7 times alt-ctrl-del, the shutdown will continue. Has to be seven? I never knew about this "feature". 7 or more, but it only works sometimes, and often far short of instantly as it claims when keyed. If the shutdown obstacles include failing to write sound card config or stopping various services that never started in the first place, then it doesn't help at all.
I have to systematically use this "feature" on a server is not willing to shut-down an lvm partition (no idea why), and it works.
However I fully agree that where hardware is involved the results are unpredictable.
I'll try next time if I remember. Till now I pulled the cable. Or the main power switch, and endure the long fsck afterwards.
Alt-SysRq reisub doesn't work?
I never managed to do it. I need to write the procedure in a paper stuck to the machine near the button :-p or I'll never remember how to do it. I think I tried once, did not work, years ago. Doesn't it have to be enabled?
BTW: Instead of the "b" in "reisub", you can use an "o", which is "poweroff". -- -Gerry Makaro aka Fraser_Bell on the forums, IRC, and mail at openSUSE.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Hans de Faber wrote:
Additional question:
Does anybody know where the waittime of this stopjobs is defined ?
/etc/systemd/system.conf Look for DefaultTimeout -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On July 25, 2017 7:05:31 AM PDT, Peter Suetterlin
Hans de Faber wrote:
Additional question:
Does anybody know where the waittime of this stopjobs is defined ?
/etc/systemd/system.conf
Look for DefaultTimeout
Yes, I've found and adjusted that, since the machine in question has an SSD, all wait times were trimmed to a minute or less. Also each service can specific it's own timeout in the .service file. Nothing about that had changed to suddenly recently. And nmb.service had no stop job on the .service file. There is no reason you would have to wait when shutting down nmb, it has nothing to do with open files. Yet it did wait. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (9)
-
Carlos E. R. -
David C. Rankin -
Felix Miata -
Fraser_Bell -
Hans de Faber -
John Andersen -
Marco Brignoli -
Peter Suetterlin -
Rodney Baker