Systemd 230 Released

[starshipeleven]

even though its weekend, looks like it isnt doing much for you.

He is the grinch.

[plonoma]

I would disagree. I would say 90s is WAY to little. Just imagine some porgram doing a sync in the background (ownCloud client) and then you end up with a broken file jsut because it took more than 90s. No, this should be fixed in the programs because different programms have to deal different with this. Lowering the 90s, in my eyes, would only mask the problem and cause problems.

BTW, this seems to be a real problem in the linux space. The notion that you just plaster over issues instead of fixing them is something we should be very careful about as it causes tons of problems in the log run.

This is why it's important for the system to communicate to the user about what programs are not exiting and why.
If a user sees a program is not exiting, then sees it's dropbox is still syncing files.
The user might want to hold on shutdown until dropbox is done.
Thus an option to wait for the program to shut down with timeouts in hours to days to unlimited time should be presented to the user.

[starshipeleven]

This is why it's important for the system to communicate to the user about what programs are not exiting and why.
If a user sees a program is not exiting, then sees it's dropbox is still syncing files.
The user might want to hold on shutdown until dropbox is done.
Thus an option to wait for the program to shut down with timeouts in hours to days to unlimited time should be presented to the user.

Yeah, this also moves the blame from "systemd" to "<whatever crap program that cannot quit cleanly>".

I suspect that this might have to be a desktop-only module, since this requires GUI interactions.

[GraysonPeddie]

Btw, wtf is this phoronix forum bug, when every third button press results in comment field shrink/expand by one line ????

Yeah. Beats me. Vbulletin is as distracting as f***.

[pal666]

The user might want to hold on shutdown until dropbox is done.
Thus an option to wait for the program to shut down with timeouts in hours to days to unlimited time should be presented to the user.

1) there might be no user at computer to answer
2) i know you are imagining windows-like interface, but during late shutdown no gui is running already

[nanonyme]

It is doing its job though. It gives the program a specified time limit to complete it's task. It's known behavior that systemd will do this. If that program continues to be hung after that specified grace period, it takes the gun and shoots that process in the head.

Some applications have a legitimate need to not go down one nanosecond after being told to exit. I would say 90 seconds is a bit too log for my personal tastes, BUT at least it's not &quot;infinity&quot;.

Infinity with user being prompted to force kill when desktop environment is involved sounds sane to me to avoid data loss

[nanonyme]

1) there might be no user at computer to answer
2) i know you are imagining windows-like interface, but during late shutdown no gui is running already

In Windows non-GUI apps that won't shut down in time are just terminated in 30 seconds FWIW

[startas]

To say once again,
1) Systemd job is to shutdown/restart computer, not to wait for some broken/still working app to hack the universe.
2) its USERS JOB to NOT shutdown pc until his launched programs are finished with their tasks.
3) Systemd must not care about user at all, it must signal to all user programs to shutdown, then wait about 5 seconds per program, and then inform user about "gone wild" programs, if he wants to wait or kill.
4) Of course, Linux structure, lets say, is "not ideal" for proper implementation of proper shutdown process.
5) Once again, I cant stress enough how important it is for user to do its job and for system to do its own job, and to mot mix these together.
6) If user wants to shutdown pc after program does some job, then that program must implement its own mechanism to close itself after it finished all tasks and signal system to shutdown or something.

[klapaucius]

Does the Magic SysRq combo work in these cases? It's the quickest way to stop or kill a hanging system, sync the filesystem and shutdown.

[SystemCrasher]

To say once again,
1) Systemd job is to shutdown/restart computer, not to wait for some broken/still working app to hack the universe.

And who are you to universally decide how it should happen right? Most *nix-like systems actually do shutdown this way: sending SIGTERM first, and if it does not suffices and apps are not reacting gracefully, there is SIGKILL apps can't escape or ignore. It isn't anyhow unique to systemd, sysv init did pretty much the very same. Maybe it had shorter timeout between TERM and KILL, but I guess it is configurable.

2) its USERS JOB to NOT shutdown pc until his launched programs are finished with their tasks.

Blatant bullshit and utter misunderstanding on how systems are working. In *nix, when shutdown is requested, shutdown sequence always has been to ask programs to terminate in a "gentle" way with SIGTERM and if they disregard this gentle warning, there is harsh SIGKILL, removing everything unconditionally. In no way systemd has invented it, this sequence has been in use for many years before systemd even appeared. At most it had shorter window between TERM and KILL. Interestingly, Windows also got very similar idea about shutdown sequencing, though it haves different options, including "forced" reboot which would just terminate anything without timeouts. Same could be done in *nix like systems as well.

3) Systemd must not care about user at all, it must signal to all user programs to shutdown, then wait about 5 seconds per program, and then inform user about "gone wild" programs, if he wants to wait or kill.

When system shuts down, it is quite busy and 5 seconds are not going to be enough to save important data and prepare to imminent shutdown in many configuration. Therefore it leads to data loss. I bet unlike you Poettering is smart enough to get idea why it could be BAD thing to do.

And if some program refuses to terminate on "gentle" request, it is actually bug in this program, SIGKILL being an EMERGENCY measure, giving program no any chances to save work or something, so it would eventually lead to data loss, program stands no chances to handle shutdown properly at this point, it going to be aborted immediately, as is.

4) Of course, Linux structure, lets say, is "not ideal" for proper implementation of proper shutdown process.

Neither Linux nor systemd are doing something unique. Systemd's shutdown sequencing is pretty much usual and not anyhow different of other systems. Plus or minus timeout value, lol. Can you imagine that, mister?

5) Once again, I cant stress enough how important it is for user to do its job and for system to do its own job, and to mot mix these together.

Maybe you'll be better with Windows, it would nag you all the time to do all kinds of things yourself. Including waiting for a while and then halting shutdown for obscure reasons. Speaking for myself, once I've told it is shutdown, IT IS FUCKING SHUTDOWN, it have to GTFO and e.g. windows attitude is extremely annoying in this regard. If some app disregards SIGTERM and refuses to quit in a timely manner, it is their stinky programming fault they were smartass enough to intercept SIGTERM but not smartass enough to actually terminate in a timely manner. This is glaring programming bug, and SIGKILL at timeout is a harsh workaround for bugged programs, as simple as that.

6) If user wants to shutdown pc after program does some job, then that program must implement its own mechanism to close itself after it finished all tasks and signal system to shutdown or something.

There is nothing prevents you to launch your job and request system shutdown when it completes. You can use scripts, syscalls, or whatever to do so. Systemd isn't anyhow interfering with it and wouldn't do anything unique compared to other solutions. In principle you can even write your own program to send desired signals on your own the way you want it, though it surely going to be redundant, because virtually any widespread OS in existence already got own mechanisms to do so.

But if you're curious, manual shutdown of *nix-like system is basically like this: send SIGTERM to everyone around. Wait for timeout to let 'em finish their stuff. Wait until either timeout expired or all programs are down, whichever comes first. It it has been timeout, kill the rest with SIGKILL. Sync filesystem and unmount (or remount readonly). Turn off the power or do reboot. That's what Alt-SysRq-R-E-I-S-U-B for, for emergency sequencing of this kind of action using kernel itself, if everything else is down (R switches kbd to "raw" mode so nobody interferes with the rest of sequence). PID=1 should not be terminated though. Killing init usually causes kernel panic. So init itself is virtually best place to do shutdown sequencing, since it sequencing things and so it does not wants to commit suicide anyway.