I'm using Debian 9. When turning off my computer, many times (more than 50%, I think) I get the following message:

A stop job is running for Session 3 of user rodrigo (Xs / 1min 30s)

X increments till the time is through, then the computer finally turns off. Sometimes there are two different "stop jobs" whose messages and timers alternate on this same line. Googling it ("a stop job is running for" debian 9), I've found many similar bugs in different distros (47 results only in bugs.debian.org), some more than 4 years old.

My question is: aren't most of these errors coming from the same package? Hasn't it been fixed yet? (Most solutions are only workarounds.) Isn't the source code developed by a single person or team, and compiled separately to the different Linux distros? If the error has been fixed in the source code (I think it should by now), then why this error still appears four years later? Isn't that too long? Or maybe it's been fixed in other distros, but not yet on Debian?

  • I think you're a witch because you can predict things just by thinking. Dec 10, 2018 at 5:17
  • 5
    This is not an error message and generated by the famous systemd. Dec 10, 2018 at 5:21
  • @IporSircer To me it seems an error, because if Firefox (for instance) is open when I turn the machine off, Firefox is automatically closed. Which program is this that systemd apparently is unable to close? And why should it be there? I'm proud of Debian being much faster than Windows, both to turn on and to turn off. So if I have to wait 90s to turn it off, at unpredictable moments, then it seems an error to me. And since this is listed as a "bug" so many times, I ask if you mean the "infamous" systemd?
    – Rodrigo
    Dec 10, 2018 at 19:12
  • 2
    This is a message printed by systemd when there is an application/service/process that does not terminate itself after being receiving a polite kill signal. aren't most of these errors coming from the same package? Hasn't it been fixed yet? Probably not, there are many reasons services may get into an unkillable state. New system services come and go all the time, so even if you fix one chances are a different service may introduce new features that produces the same message, and in many cases, they only get into this state because of your specific system's configuration.
    – Lie Ryan
    Dec 15, 2018 at 10:09

1 Answer 1


There's no "automatic" spread of of patches. Neither for the Linux kernel, nor of any other OS component like libraries, programs etc.

This happens for a number of reasons, that mainly boil down to these ones:

  1. Almost all distributions apply their very own patches to the "official sources" before creating binary packages. This leads to a non-trivial amount of work to apply possible official, unofficial and out-of-branch security and bug-fix patches. And some of those patches aren't just fixes: they can be needed in order for a package to comply to the distribution policies (like adding a mandatory --help or --long-help and the likes).

  2. The timing those "official patches" get to a distribution can vary widely, depending upon a number of reasons like human resources, patch review policies and the likes. Sometimes there are distributions that won't apply some patches.

  3. Distributions like Ubuntu have "support" policies that can slow down and even block any update to a distribution once it gets "end of life". On the other side, rolling distributions tend to keep up with the "official" patches and new releases.

For general updates about patches, bug-fixes and security pathces, I'd like to suggest you websites like Linux Weekly News and Phoronix.

All that said, the error you are reporting clearly says that there's some process of yours still running while shutting down the system. I'd suggest you to run some tests right before doing the shutdown, just to know which process is hanging.

In my opinion, ps is your friend and you could run it straigth from a vty (virtual console tty).

  1. Press Ctrl+Alt+F1 (or F2 or F3) to get a vty. It's the non-GUI login.
  2. Login with your username and password.
  3. Run PS_FORMAT='ruser,pid,ppid,s,%cpu,rss,cmd' ps x (my personal favorite). It will show you the all the process running as "you" along with some details. Replace ps x with ps ax to see all processes.
  4. Take note of those processes: PID is the process ID, PPID is the parent process ID, that of the process who spawned that process, CMD is the command being run.
  5. Try closing/killing them before doing the shutdown.
  • Thank you. From one comment, let's suppose the problem is in systemd. About your point 1 above, wouldn't it be wiser to patch the original code once and for all, instead of each distribution applying a different patch? That sounds like do the same work again... About number 3, I'm using Debian 9, so no "end of life" here. About ps isn't it the same as see the process listing in System Monitor? How can I know which process is blocking my turn off? And should I be closing/killing this process by myself every time? That's not a solution!
    – Rodrigo
    Dec 10, 2018 at 19:22
  • 1
    I added some more explanation about patching. For debian, you'd better check the documentation like en.wikipedia.org/wiki/Debian_version_history#Release_table . Again, you have to investigate with tools like ps and lsof for example. Dabian Handbook can be of help (debian-handbook.info).
    – EnzoR
    Dec 15, 2018 at 9:58

Not the answer you're looking for? Browse other questions tagged .