[*** ] A stop job is running (1m 30s)

Has this ever recovered for you and managed to do a clean shutdown?

Attached: 2880px-Systemd-logo.svg_-2-900x563-1.png (900x563, 14.64K)

Attached: 1660660059314.png (200x193, 29.55K)

Why shouldn't it do a clean shutdown? It just waits that long to SIGKILL the hanging process and proceed normally.

Attached: 1645676812952.jpg (976x1024, 78.82K)

I just hold the power button because it never cleanly exits anyway.

So reducing the default from 1.5min to 10 seconds does no further harm?

Probably not, i don't see why a program would take more than a second to stop.

Attached: 1619466790160.jpg (730x1025, 71.37K)

Why don't they just let you hit Ctrl-C?

OpenRC does not have this problem. It shut downs fast and boots up fast too. Lennart should hang.

Systemd problems. Which I've encountered only on arch and ubuntu, debian stable works perfectly.
Just change the timeout to 5-10 secs.

funny enough, it does if you use things intended to be used with systemd like networkmanager... obnoxious

delete system32

Attached: letsdothis.jpg (500x500, 146.11K)

Why would NetworkManager be intended for use with systemd, considering it predates systemd?

nope it just keeps restarting and usually increments the time countdown each time it fails so it never shuts down. it gets stuck in an infinite loop.

No cause I'm not using pozzed init

I do sysreq E when some stop job hangs (usually User Manager for me) and it works for some reason even though systemd already should've sent a SIGTERM

yes?
it happens everyday to me when shutting down

no that's because 1) I use dinit and 2) I use connman

Yes just give it some time.

I just use the simple fix of not using poottering init.

Well let's say that fstrim is doing is weekly trim, flatpaks are being updated in the background, etc. This would sigkill the process in the middle of these potentially.
It is best to stick with the 90s timeout for this exact reason, and this is what it was meant for. The issue is that processes like Kwin for example cause a hang because for whatever reason the devs are retards. When the shutdown is regularly taking a longtime, you need to diagnose the issue. Chances are it's some issue with the process itself. In this case, make a systemd job that kills the process on shutdown.

>automatically starting long winded processes that can not be gracefully stopped
So modern desktop Linux is essentially Windows at this point?
>oi mate, want to do something with your computer?
>too bad, it's update time

Can't you set specific timeouts for each service unit? (haven't used systemd in a while)

>for whatever reason the devs are retards
so like pottery then

try a distro other than arch

You can in the service file, but chances are you don't want to modify that and the issue is caused by the program itself. Usually the program just needs to be killed on shutdown.
Back in the day it was considered good practice to close all your programs before shutting down kind of for this reason. Luckily most programmers understand that you won't do this, and allow the process to be killed. Essential ones will cause the countdown for SIGKILL. Obviously something that cannot be closed like Kwin that has retard devs who have decided it cannot be gracefully shutdown though will cause a problem where you have to just kill it yourself.