On 7/21/2017 2:25 PM, Stefan Bruens wrote:
On Freitag, 21. Juli 2017 19:26:02 CEST Brian K. White wrote:
On 7/21/2017 12:08 PM, Richard Brown wrote:
[...]
Donating time and effort is no service and no virtue unless it's actually a good thing.
That's true, but for any sane person with a little bit of comprehension, Richards post actually is "a good thing".
On the other hand, mindlessly trolling and ignoring technical reasoning never is - that's your contribution so far.
Thanks for wasting everyones time,
And I say, that's just namecalling. How does one modify the behavior of a unit file at emergency-console time? I don't mean merely edit the unit file, I mean make it do something that systemd doesn't allow for. I can do that with an init script, because the init binary itself, which I can't see into or modify at run-time, does very little, exactly for that reason. How does one read the binary dadabase journal with only sh to work with? I can do that with the text syslog. At one time I had a nice efficient small init script that managed lxc containers. It included options to stop, start, and query status of any individual container, and for all containers as a virtual "service". At server shut-down time, the script received a shutdown command like any other init script, but unlike normal init scripts, there was no daemon to kill. Instead, it used a few lxc commands to examine the state of all configured containers, and shut down any that were running, and only when all were gracefully shutdown, the main script exited with the proper exit value to tell "rc" the overall status (worked, didn't work, etc). Systemd makes no allowance for the necessary arbitrary "status" operation for that to work. Systemd operates in a fundamentally different way, being triggered by events and states of things, such that the very idea of "In order to determine the status of service foo, run these commands to arrive at an answer at the time the question is asked." is simply incompatible with the way systemd works. It *needs* something that it can monitor itself directly, and only react to changes in the state of that thing, be that a process or a file or a socket. The only way to regain the functionality I already had, would have been to actually write a stupid special monitor daemon that could serve as the thing for systemd to monitor, since there really is no actual thing to monitor. No single file or process or socket, not even for a given container let alone the whole meta-service. It would have been a 100% superfluous extra process to code, run 24/7, serving NO actual necessary purpose to the containers, just providing a stupid pacifier for systemd to suck on. There was a whole discussion about "ExecStatus" in unit files just for cases like this. My particular example involving lxc containers is not the only such. By now, systemd has it's own special built-in support for cgroup-based containers, and possibly, it might even provide reasonably sane equivalents to the operations I had in my own script (like setting up virtual consoles in screen sessions for each container, nice simple commands to check the status of all containers or an individual one etc, all right from a 5 or 6k shell script that didn't even run except just for the split second when it's actually used once at boot and once at shutdown.) but even if it now has built-in special support for containers and totally obsoletes my init script, even to my own full satisfaction, that still does absolutely nothing for any other similar virtual "service" that just doesn't happen to be cgroup-based container management. The systemd developers simply declared that no such need is valid. Problem solved! It's simply a lie to say I don't have a valid argument based of technical grounds. Rather it is the other way around, no one is bothering to respond to the technical argument. I say, it's because it's a real problem that they don't have an answer to. Well yes, exactly. That's the problem. -- bkw -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org