a stop job is running....

[François Patte]

And it takes ages to shutdown....

Why theses messages?

today I started rc.local compatibility then I stopped it and at
shutdown, I get the message: "a stop job is running for this
service".... which has been stopped one hour before.... morever I was
threatenned with a "no limit" menace!

Thanks for helping

[Tom Horsley]

On Thu, 15 Sep 2016 23:40:19 +0200
François Patte wrote:
> Why theses messages?

Because systemd has a gazillion bugs like this and they
are having so much fun introducing yet more bugs that
they aren't remotely interested in making what they have
actually work correctly.

I have noticed that sometimes you can get it to stop
waiting by holding down Ctrl-Alt-Del. If it repeats
long enough, systemd eventually gets the idea you'd
like it to stop.

[Terry Polzin]

I've noticed an issue trying to shutdown when there are NFS and CIFS mounts

On Thu, Sep 15, 2016 at 5:50 PM, Tom Horsley  wrote:
> On Thu, 15 Sep 2016 23:40:19 +0200
> François Patte wrote:
> > Why theses messages?
>
> Because systemd has a gazillion bugs like this and they
> are having so much fun introducing yet more bugs that
> they aren't remotely interested in making what they have
> actually work correctly.
>
> I have noticed that sometimes you can get it to stop
> waiting by holding down Ctrl-Alt-Del. If it repeats
> long enough, systemd eventually gets the idea you'd
> like it to stop.
> --
> users mailing list
> [e-mail]
> To unsubscribe or change subscription options:
> https://lists.fedoraproject.org/admin/lists/[e-mail]
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
> Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
> Have a question? Ask away: http://ask.fedoraproject.org

[Tom Horsley]

On Thu, 15 Sep 2016 19:42:00 -0400
Terry Polzin wrote:
> I've noticed an issue trying to shutdown when there are NFS and CIFS mounts

I've developed my own reboot alias that kills off all the
things I've been able to track down as sources of hangs
before asking systemd to reboot. It works pretty well,
but the problems always start when something new makes
reboot hang and you have to track it down.

Read about it here: http://tomhorsley.com/game/punch.html

[Peter G.]

Tom Horsley wrote:
> Read about it here: http://tomhorsley.com/game/punch.html

LOL

Actually, I'm pretty happy with systemd h/t To think of the 
hours I used to spend finding out about daemons I never used 
and what they were for, setting them all up to either run or 
not run, etc... Sure, I suppose I learned a lot about the 
system, but I like that systemd just does it all for me and I 
don't need to waste my time on pointless tasks that a modern 
OS should be able to deal with on its own.

My old computers were afflicted with pesky stop job problem, 
too. I'm not sure if it is on my new one? I didn't realize 
that it was only on reboots and not shutdowns: perhaps that's 
why I haven't seen it lately? Or could it be fixed :-O

I dealt with it by making an espresso and then it was timed 
out. They go for 1'30". But, yes, it is frustrating when 
working on something and having to wait for the timeout.

[Saint Michael]

I filed this bug in Fedora years ago. Unhappy to see it still is not fixed

On Thu, Sep 15, 2016 at 7:42 PM, Terry Polzin  wrote:
> I've noticed an issue trying to shutdown when there are NFS and CIFS mounts
>
> On Thu, Sep 15, 2016 at 5:50 PM, Tom Horsley 
> wrote:
> > On Thu, 15 Sep 2016 23:40:19 +0200
> > François Patte wrote:
> > > Why theses messages?
> >
> > Because systemd has a gazillion bugs like this and they
> > are having so much fun introducing yet more bugs that
> > they aren't remotely interested in making what they have
> > actually work correctly.
> >
> > I have noticed that sometimes you can get it to stop
> > waiting by holding down Ctrl-Alt-Del. If it repeats
> > long enough, systemd eventually gets the idea you'd
> > like it to stop.
> > --
> > users mailing list
> > [e-mail]
> > To unsubscribe or change subscription options:
> > https://lists.fedoraproject.org/admin/lists/[e-mail]
> > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
> > Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
> > Have a question? Ask away: http://ask.fedoraproject.org
>
> --
> users mailing list
> [e-mail]
> To unsubscribe or change subscription options:
> https://lists.fedoraproject.org/admin/lists/[e-mail]
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
> Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
> Have a question? Ask away: http://ask.fedoraproject.org

[Sylvia Sánchez]

In my case, when it shows up, it never last more than a couple of
minutes.  But yeah, it's been ages with this problem.

Cheers,
Sylvia

[Rex Dieter]

Tom Horsley wrote:
> On Thu, 15 Sep 2016 23:40:19 +0200
> François Patte wrote:
> > Why theses messages?
>
> Because systemd has a gazillion bugs like this

In cases like this in general, it's not systemd, but the individual services 
that have bugs.

In this particular case, it's the user session that has processes still 
running, and not quiting after logout.  systemd is waiting for them to 
gracefully exit before timeout (120 seconds?) and focefully killing them.

-- Rex

[Tom Horsley]

On Sat, 17 Sep 2016 11:34:54 -0500
Rex Dieter wrote:
> In this particular case, it's the user session that has processes still 
> running, and not quiting after logout.

There were no "user daemons" till systemd invented them.
Every login creates at least a "systemd --user" process
which never goes away. If systemd is going to invent
user daemons, it should also invent a way to make them exit,
but so far the only way that works for me is to force kill
off all the "systemd --user" process trees on the system
before trying to reboot.

[Jon LaBadie]

On Sat, Sep 17, 2016 at 11:34:54AM -0500, Rex Dieter wrote:
> Tom Horsley wrote:
> > Because systemd has a gazillion bugs like this
>
> In cases like this in general, it's not systemd,
> but the individual services that have bugs.

Does anyone else tire of hearing
"its not systemd, its ..."

jon

[François Patte]

Le 17/09/2016 22:53, Jon LaBadie a écrit :
> On Sat, Sep 17, 2016 at 11:34:54AM -0500, Rex Dieter wrote:
> > Tom Horsley wrote:
> > > Because systemd has a gazillion bugs like this
> >
> > In cases like this in general, it's not systemd,
> > but the individual services that have bugs.
>
> Does anyone else tire of hearing
> "its not systemd, its ..."

I have no idea about this and systemd in general.... I have four
computers running under fedora systemd: a desktop under f21, no problem
of the like; sometimes I get this message: "a start job is running"
about some partitions installed on two disks in a raid-1 array, that I
added to the main system after the install. I suspect that it is an fsck
check but, systemd gives no info on the boot screen about this and I did
not check in the huge journal...

two laptops under f23 with no problems abo some running jobs (start or stop)

and one laptop under f24 which has these problems. What can we say?
there are bugs in fc 24 installation of systemd? These stop problems can
come from the way journalctl write in the /var partition: both partition
/var and /usr fail to be unmounted at shutdown (they are separate
partitions from /), is it because journalctl wants to write the logs
until the last second and the shutdown process wants to umount these two
partitions too earlier? I am not able to answer and solve these
problems... But are they systemd problems or a fedora configuration of
systemd problem?

Who knows?

[Chris Murphy]

On Sun, Sep 18, 2016 at 9:58 AM, François Patte
 wrote:
> Le 17/09/2016 22:53, Jon LaBadie a écrit :
> > On Sat, Sep 17, 2016 at 11:34:54AM -0500, Rex Dieter wrote:
> > > Tom Horsley wrote:
> > > > Because systemd has a gazillion bugs like this
> > >
> > > In cases like this in general, it's not systemd,
> > > but the individual services that have bugs.
> >
> > Does anyone else tire of hearing
> > "its not systemd, its ..."
>
> I have no idea about this and systemd in general.... I have four
> computers running under fedora systemd: a desktop under f21, no problem
> of the like; sometimes I get this message: "a start job is running"
> about some partitions installed on two disks in a raid-1 array, that I
> added to the main system after the install. I suspect that it is an fsck
> check but, systemd gives no info on the boot screen about this and I did
> not check in the huge journal...
>
> two laptops under f23 with no problems abo some running jobs (start or stop)
>
> and one laptop under f24 which has these problems. What can we say?
> there are bugs in fc 24 installation of systemd? These stop problems can
> come from the way journalctl write in the /var partition: both partition
> /var and /usr fail to be unmounted at shutdown (they are separate
> partitions from /), is it because journalctl wants to write the logs
> until the last second and the shutdown process wants to umount these two
> partitions too earlier? I am not able to answer and solve these
> problems... But are they systemd problems or a fedora configuration of
> systemd problem?
>
> Who knows?

The problem is there is some process in the user session that isn't
quitting, and systemd doesn't force quit it for 1m30s at which time it
obliterates the user session and everything running in it. You can use
loginctl to list the contents of the user session, but in my
experience I often can't get to a different tty to check on this.

You can try one of two things:

1. Log out, then restart or shutdown. For whatever reason this works
for me maybe 1/2 the time or more.
2. Edit /etc/systemd/logind.conf such that
KillUserProcesses=yes

i.e. remove the # that's currently there by default. This was slated
to be the default for Fedora 25 but the feature has other
consequences, namely it would kill screen and tmux in your user
session also and so there are some unfinished work arounds to make
those things use different scopes or sessions or whatever they're
called.

Just realize with this option set to use, literally everything running
in your user session will get killed off. There is a way to use
systemd-run blah blah you'll have to read about it, to launch tmux in
a different session that doesn't get killed off. I have no idea how
you reconnect to it, if anything else is different other than just
running it that way because I haven't tried it. I have found some
other things like btrfs balance and scrub, which can take hours or
days, will get killed off also and I'm working with upstream Btrfs
folks on a work around for that also, because the real work is done by
the kernel so the operation isn't killed so much as the user process.
So the user process needs to be killable and then able to reconnect to
check status, pause or cancel correctly.

[Doug H.]

On Thu, 2016-09-15 at 23:40 +0200, François Patte wrote:
> And it takes ages to shutdown....
>
> Why theses messages?
>
> today I started rc.local compatibility then I stopped it and at
> shutdown, I get the message: "a stop job is running for this
> service".... which has been stopped one hour before.... morever I was
> threatenned with a "no limit" menace!
>
> Thanks for helping

May just be coincidence, or maybe...

A couple of days ago you were advised to enable "akmods-
shutdown.service". I stopped using that one since I noticed a "stop
job" slowdown with it.

For myself I just keep:
> systemctl -a | grep akmods

akmods.service                                                         
                   loaded    active   exited    Builds and install new
kmods from akmod packages