pid1: add SurviveFinalKillSignal= to skip units on final sigterm/sigkill spree

[bluca]

Add a new boolean for units, SurviveFinalKillSignal=yes/no. Units that
set it will not have their process receive the final sigterm/sigkill in
the shutdown phase.

[yuwata]

superficial comments only.

[keszybz]

Hmm, so we'd be supposed to put services in a special slice. But slices are a mechanism for resource management, generally unrelated to how services behave during shutdown or other state transitions. I liked the previous approach with a setting that can be attached to any unit much more.

[bluca]

Hmm, so we'd be supposed to put services in a special slice. But slices are a mechanism for resource management, generally unrelated to how services behave during shutdown or other state transitions. I liked the previous approach with a setting that can be attached to any unit much more.

Well, ish - there's init.scope, and the forthcoming init-workers.scope, that also have semantic meaning outside of resource management. Also, there's the whole delegation mechanism, that is also not about resource management, but process management. The caveat for this feature is that I think managing processes by cgroup is the way to go, and the key thing we need to do for this is killing a subset of live processes on soft-reboot. I think it fits very well with the hierarchical cgroup model, and having to reimplement that manually (going unit by unit to check a boolean) would be much worse.

Then there's the issue that @poettering did not like the boolean, so I'm trying to get two birds with one stone here.

[keszybz]

IMO that's a false similarity. Yes, we have a init.scope, but that's because the init process and its helpers form a unit which shares resources, so it makes sense to create a slice/scope for them. The fact that units should survive a reboot does not mean that they should share resources in any way.

[bluca]

Hence sorry, but these implicit deps might make sense in isolated usecases, but I doubt they are good defaults, nor are they desirable at all.

Yeah. Stuff that survives a reboot would generally be special, and would need to coordinate closely with other early-boot and late-shutdown services, so some careful crafting of ordering dependencies will be necessary anyway.

Do you have any such real-world examples? I have a dozen of them or so, and only one fits that description, but it's a one-shot remain-after-exit that configures hardware on early boot, so that also doesn't fit quite well. Everything else is a normal service from any other point of view.

After re-reading the discussion, I'm swayed by Lennart's arguments.

Please rework this, so that the knob just controls the xattr.

+1 to this. This would be a generally useful thing, and I think we all agree on having this.

We do not. I am very strongly against half-arsing this. It is very important to me and my use cases to have a first-class, well-defined, intelligible, supported and consistent interface for this.

This is not any different from many of the other well-defined, high level interfaces we have. For example, pretty much everything that deals with images, directories or mounts could be removed, and is doable with the single MountImage and BindPath settings. Everything else is redundant - RootImage, RootEphemeral, ExtensionImages, PrivateTmp, TemporaryFileSystem etc.
Same for the exec directories, everything is redundant - StateDirectory, RuntimeDirectory, etc.
Same for most of the input/output redirection, both old and new - OpenFiles, etc.
Heck, if you take this all the way through, I'm pretty sure 2/3 of all unit settings are redundant, as an inline script in ExecStartPre could very well replace most things.

Why do we have all of these redundant then? Because often it's not enough to enable some very low level functionality, but we want to offer a first class interface, that comes with a promise that whatever else we change, it will keep working as advertised, and models some common and specific behaviour that we want to encode and expose. For me, this is one of those cases.