CentOS - May 2019 - Bypassing 'A stop job is running' when rebooting CentOS 7

On Wed, May 22, 2019 at 09:07:32AM -0600, James Szinger
wrote:
> On Wed, May 22, 2019 at 7:44 AM mark <m.roth at 5-cent.us> wrote:
> >
> > The joys of systemd....
> 
> I'm not sure it's right to blame systemd.  Systemd asked nicely for
> the service to shutdown.  
But we can blame systemd for the cryptic message

  A stop job is running

Surely systemd knows what service it is waiting for,
why doesn't it tell us?

  The stop job XYZ is running

jon
-- 
Jon H. LaBadie                 jcu at jgcomp.com
 11226 South Shore Rd.          (703) 787-0688 (H)
 Reston, VA  20190              (703) 935-6720 (C)

On Wed, May 22, 2019 at 03:41:24PM -0400, Jon LaBadie
wrote:
> On Wed, May 22, 2019 at 09:07:32AM -0600, James Szinger wrote:
> > On Wed, May 22, 2019 at 7:44 AM mark <m.roth at 5-cent.us>
wrote:
> > >
> > > The joys of systemd....
> > 
> > I'm not sure it's right to blame systemd.  Systemd asked
nicely for
> > the service to shutdown.  
> 
> But we can blame systemd for the cryptic message
> 
>   A stop job is running
I didn't read this thread all that carefully, but has anyone mentioned
editing /etc/systemd/system.conf and changing DefaultTimeoutStartSec and
DefaultTimeoutStopSec to a lower value? 

--
Scott Robbins
PGP keyID EB3467D6
( 1B48 077D 66F6 9DB0 FDC2 A409 FA54 EB34 67D6 )
gpg --keyserver pgp.mit.edu --recv-keys EB3467D6

Scott Robbins wrote:
> ** WARNING: This mail is from an external source **
> 
> 
> On Wed, May 22, 2019 at 03:41:24PM -0400, Jon LaBadie wrote:
>> On Wed, May 22, 2019 at 09:07:32AM -0600, James Szinger wrote:
>>> On Wed, May 22, 2019 at 7:44 AM mark <m.roth at 5-cent.us>
wrote:
>>>>
>>>> The joys of systemd....
>>>
>>> I'm not sure it's right to blame systemd.  Systemd asked
nicely for
>>> the service to shutdown.
>>
>> But we can blame systemd for the cryptic message
>>
>>    A stop job is running
> 
> I didn't read this thread all that carefully, but has anyone mentioned
> editing /etc/systemd/system.conf and changing DefaultTimeoutStartSec and
> DefaultTimeoutStopSec to a lower value?
All the entries in /etc/systemd/system.conf are commented out - and as 
the systemd-system.conf man page states:

  By default the configuration file in /etc/systemd/ contains
  commented out entries showing the defaults as a guide to the
  administrator

The DefaultTimeoutStopSec line in /etc/systemd/system.conf is:

  #DefaultTimeoutStartSec=90s

In my case, the 'timeout' on whatever it was trying to do was 90 seconds
- but it kept being increased by ~90 secs until it finally gave up at 30 
minutes ...

So I don't think changing DefaultTimeoutStartSec will help here ?

There is no mention of 30 minutes in /etc/systemd/system.conf, that is 
why I'm guessing it has something to do with the JobTimeoutSec in 
/usr/lib/systemd/system/reboot.target

A bit of (more) googling seems to suggest that this is the setting that 
needs to be changed. I believe this means something like 'after 30 
minutes from starting the reboot process, force a reboot regardless'

Personally, I think 30 minutes is far too long to wait, especially in 
the case of servers where no console access is available ...

James Pearson

On Wed, May 22, 2019 at 1:41 PM Jon LaBadie <jcu at labadie.us>
wrote:
> But we can blame systemd for the cryptic message
>
>   A stop job is running
>
> Surely systemd knows what service it is waiting for,
> why doesn't it tell us?
>
>   The stop job XYZ is running
The message reported by the OP and the message I see is 'A stop job is
running for ...' where the ellipses stand in for the unit that systemd
is waiting for.  It seems pretty clear IMHO.  Actually debugging it is
harder since the system is not available during shutdown, but that's a
generic problem and the systemd docs do provide debugging tips.

Jim