537
No Mercy (files.catbox.moe)
submitted 4 months ago by sag@lemm.ee to c/linuxmemes@lemmy.world
you are viewing a single comment's thread
view the rest of the comments
[-] SpaceCadet@feddit.nl 5 points 4 months ago

That’s what systemd’s dreaded “a stop job is running” is

The worst part of that is that you can't quickly login to check what it is (so maybe you can prevent it in the future?), or kill it anyway because it's likely to be something stupid and unimportant. And if it actually was important, well... it's gonna be shot in the head in a minute anyway, and there's nothing you can do to prevent it, so what's the point of delaying?

[-] bjoern_tantau@swg-empire.de 13 points 4 months ago

so what's the point of delaying?

In the best case the offending process actually does shut down cleanly before the time is up. Like, some databases like redis keep written data in memory for fast access before actually writing the data to disc. If you were to kill such a process before all the data is written you'd lose it.

So, admins of servers like these might even opt to increase the timeout, depending on their configuration and disc speed.

[-] SpaceCadet@feddit.nl 12 points 4 months ago* (last edited 4 months ago)

I know what it theoretically is for, I still think it's a bad implementation.

  1. It often doesn't tell you clearly what it is waiting for.
  2. It doesn't allow you to checkout what's going on with the process that isn't responding, because logins are already disabled
  3. It doesn't allow you to cancel the wait and terminate the process anyway. 9/10 when I get it, it has been because of something stupid like a stale NFS mount or a bug in a unit file.
  4. If it is actually something important, like your Redis example, it doesn't allow you to cancel the shutdown, or to give it more time. Who's to say that your Redis instance will be able to persist its state to disk within 90 seconds, or any arbitrary time?

Finally, I think that well written applications should be resilient to being terminated unexpectedly. If, like in your Redis example, you put data in memory without it being backed by persistent storage, you should expect to lose it. After all, power outages and crashes do happen as well.

this post was submitted on 07 Jul 2024
537 points (93.0% liked)

linuxmemes

21282 readers
284 users here now

Hint: :q!


Sister communities:


Community rules (click to expand)

1. Follow the site-wide rules

2. Be civil
  • Understand the difference between a joke and an insult.
  • Do not harrass or attack members of the community for any reason.
  • Leave remarks of "peasantry" to the PCMR community. If you dislike an OS/service/application, attack the thing you dislike, not the individuals who use it. Some people may not have a choice.
  • Bigotry will not be tolerated.
  • These rules are somewhat loosened when the subject is a public figure. Still, do not attack their person or incite harrassment.
  • 3. Post Linux-related content
  • Including Unix and BSD.
  • Non-Linux content is acceptable as long as it makes a reference to Linux. For example, the poorly made mockery of sudo in Windows.
  • No porn. Even if you watch it on a Linux machine.
  • 4. No recent reposts
  • Everybody uses Arch btw, can't quit Vim, and wants to interject for a moment. You can stop now.
  •  

    Please report posts and comments that break these rules!


    Important: never execute code or follow advice that you don't understand or can't verify, especially here. The word of the day is credibility. This is a meme community -- even the most helpful comments might just be shitposts that can damage your system. Be aware, be smart, don't fork-bomb your computer.

    founded 1 year ago
    MODERATORS