Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #209817 > unrolled thread

Systemd waiting forever on a job start/stop

Back to article view | Back to linux.debian.user

Contents

  Systemd waiting forever on a job start/stop Marc Franquesa <marc.franquesa@gmail.com> - 2019-06-11 19:20 +0200
    Re: Systemd waiting forever on a job start/stop Greg Wooledge <wooledg@eeg.ccf.org> - 2019-06-11 20:00 +0200

#209817 — Systemd waiting forever on a job start/stop

[Multipart message — attachments visible in raw view] — view raw

I faced this problem many times, on booting/start or shutting down/stopping
different services (iptables, NFS, ...).

[    **] A start job is running for Packet F…ramework (4d 30min 32s / no
limit)

I have some unbootable systems (like you see above) and some that hangs on
shutting-down while waiting for stop job (requiring a hard reset)

>From my point of view, despite being an issue on the related service not
properly starting/stopping in timely fashion, is systemd responsability to
either timeout and abort and continue the system boot process to be able to
troubleshoot the service. But all the stuff I find on research (forums,
google, ...) are specific problems/solutions for specific services.

While systemd is waiting, I have no SSH or even console access (well, only
to see the above message), so I cannot do anything even interactively. Note
that some of the systems like Pi don't have a normal BIOS/Bootloader, so
passing boot arguments in commandline is not always practical or even
possible).

As per the man page systemd-system.conf (5), the default is 90s, but as you
can see on above line it says 'no limit'. Without looking for a flame-war,
I don't remember this happened with old-init, when if a service failed it
simply failed that unique service.

Any ideas?

[toc] | [next] | [standalone]

#209821

On Tue, Jun 11, 2019 at 06:58:51PM +0200, Marc Franquesa wrote:
> [    **] A start job is running for Packet F…ramework (4d 30min 32s / no
> limit)
> 
> I have some unbootable systems (like you see above) and some that hangs on
> shutting-down while waiting for stop job (requiring a hard reset)
> 
> >From my point of view, despite being an issue on the related service not
> properly starting/stopping in timely fashion, is systemd responsability to
> either timeout and abort and continue the system boot process to be able to
> troubleshoot the service. But all the stuff I find on research (forums,
> google, ...) are specific problems/solutions for specific services.

Well, yes.  Fixing your issues is a matter of fixing each individual
service, one by one.

> While systemd is waiting, I have no SSH or even console access (well, only
> to see the above message), so I cannot do anything even interactively.

If you suspect this is going to be an ongoing issue, you can activate
the emergency debug-shell.service on tty9, as described at
<https://freedesktop.org/wiki/Software/systemd/Debugging/#earlydebugshell>.

If you enable that service, a terminal session running as root will be
available on tty9 very early in the boot process.  No password will be
required, so make sure the box is physically secure, or disable the
service when you're done with it.

> As per the man page systemd-system.conf (5), the default is 90s, but as you
> can see on above line it says 'no limit'.

Again, this is configured (or not configured) by individual services.
You'll need to figure out which service is causing the problem, and
reconfigure it.

You can create local overrides in /etc/systemd/system on a per-service
basis, setting TimeoutStartSec to whatever value you like.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web