Systemd 213 Adds A Time Sync Daemon

[liam]

how do you protect from the OOM killer ?
did they fix systemd terminating processes with kill at shutdown ?
hardware watchdog to supervise itself from hanging ?

audit is the tool to audit, an init is to init
a quantum leap indeed, by a Planck length that is

OOMScoreAdjust=Sets the adjustment level for the Out-Of-Memory killer for executed processes. Takes an integer between -1000 (to disable OOM killing for this process) and 1000 (to make killing of this process under memory pressure very likely). See proc.txt for details.

I think this should address your concern about how it terminates processes at shut down. It's a configurable policy (cgroup, process, mixed, none). If processes are left during shutdown than haven't responded to the policy you can configure http://www.freedesktop.org/software/...temd.kill.html to either sigkill them or not, but it defaults to sigkill.

Starting with version 183 systemd provides full support for hardware watchdogs (as exposed in /dev/watchdog to userspace), as well as supervisor (software) watchdog support for invidual system services. The basic idea is the following: if enabled, systemd will regularly ping the watchdog hardware. If systemd or the kernel hang this ping will not happen anymore and the hardware will automatically reset the system. This way systemd and the kernel are protected from boundless hangs -- by the hardware. To make the chain complete, systemd then exposes a software watchdog interface for individual services so that they can also be restarted (or some other action taken) if they begin to hang. This software watchdog logic can be configured individually for each service in the ping frequency and the action to take. Putting both parts together (i.e. hardware watchdogs supervising systemd and the kernel, as well as systemd supervising all other services) we have a reliable way to watchdog every single component of the system.

http://0pointer.de/blog/projects/watchdog.html

Also, you're going to continue to see problems with systemd if you expect it to be just an init. It just isn't

[gens]

...

oom works on arbitrary point system
still it won't kill a root process if there is a user one that takes up ram

first try sigterm, so the process can idk try exit clean
just sigkill-ing everything right away is just plain wrong
i wonder the reasoning

watchdog...
"This is required to increase reliability and make sure that regardless what happens the best is attempted to get the system working again."
i stopped reading after that gem

audit is still a better system and it's scriptable

systemd is an OS...
so is linux, and i can't find great many things wrong with linux (none that won't be solved with wayland plus a couple minor ones, that is)

[TheBlackCat]

That wasn't an attempt at trolling. It was a sarcastic joke from a UNIX user. Sorry you didn't find it funny. I was satiring the humour of yet another block to add to the monolith, it doesn't matter if it uses separate binaries, I'm still no longer a GNU/Linux user.

We understand that is what you did. What you don't understand is that is trolling.

[TheBlackCat]

Also, you're going to continue to see problems with systemd if you expect it to be just an init. It just isn't

That has been explained to gens hundreds of times, at least a dozen by my personally.

[interested]

oom works on arbitrary point system
still it won't kill a root process if there is a user one that takes up ram

first try sigterm, so the process can idk try exit clean
just sigkill-ing everything right away is just plain wrong
i wonder the reasoning

Your rather brief and almost fragmentary stream-of-consciousness writing style, makes it very hard for other people to understand what exactly it is that you mean.
Are you against how the Kernel OOMkiller works? or do you dislike the fact that thanks to systemd, end-users can now easily take advantage of such kernel features?

Sure, many people doesn't need OOMkiller protection on their services, but for those who do, it is a fantastic feature that is easy to use thanks to systemd.

This feature is just one tiny features out of the many systemd has. But it illustrate a crucial point about systemd, namely that systemd is a plumbing system that makes it possible for distro maintainers and end-users alike to use advanced kernel features. For a long time the problem was that the Linux Kernel got new features, but user-land was very slow in adapting such features. There simply lacked some concerted effort to make things work, which is the reason behind the yearly "Linux Plumbers Conference", and ultimately the reason for why and how systemd is designed.

watchdog...
"This is required to increase reliability and make sure that regardless what happens the best is attempted to get the system working again."
i stopped reading after that gem

Again, it is impossible for other people to understand why you stopped reading; was it too tiring?, too many long words? Are you against the principle of watchdogs on systems?

Really, watchdogs have been a stable of HA computing and the embedded market for years, since they solve an otherwise rather hard problem, namely to supervise the supervisor system and the OS. Even "bug free" systems may hang because of some random bit flip etc. Hardware watchdogs can make recovery fast and cheap, since no there is no need to get a human to power-cycle the hardware. AFAIK, even most desktop motherboards have hardware watchdogs these days.

audit is still a better system and it's scriptable

I have a really hard time understanding why you drag "Audit" into this. Audit seems to be a CAPP audit framework; it doesn't supervise anything, it doesn't prevent anything, it just monitors for changes and report them. Systemd actually supervises all processes instead of merely monitoring them, and can control the limits and behaviour of such processes too, such as preventing them from forking, cap their resource use, starting them or terminating them if needed etc.

There is a tiny overlap between "Audit" and systemd, in that, thanks to systemd developers, "Audit" actually works on OS containers too (of course, only on systemd systems).

As for you implying that systemd isn't scriptable, that is just wrong. It just happens to separate configurations in easily parsable text files, from executable code. But the normal GNU tools like grep, tee, sed, ed, bash, works with systemd, in fact, systemd often makes it easier to use such tools.

[misc]

On one of my hosts my process supervisor is this file in /etc/cron.d/ :

* * * * * root pgrep foo > /dev/null || service foo start

If this triggers, I even get a report (cron already emails stdout to root@localhost, then forwarded to a proper mailbox) with a notification dialog on my workstation (since my email client does that already). Absolutely nothing new was needed for this - no replacement pid1 or new initscripts, no replacement for cron, no replacement logging/notification mechanism in lieu of syslog and/or a properly-configured MTA on the host.

It would have been better if it was not so easy to fool by renaming one of my process ( by changing argv[0], a trick that work on linux and most *BSD ) to make sure your scriptlet doesn't work, but I guess that your point is that since this duct tape is sufficient for your world, it should be adopted everywhere ?
For people wanting actual rate limitation, proper process detection and something that do scale ( cause 1 fork per minute is nice for your server, maybe not so good when you start to have 1000 or more container, and likely not fine on a battery powered system ), I guess they need to use something else.

[liam]

oom works on arbitrary point system
still it won't kill a root process if there is a user one that takes up ram

first try sigterm, so the process can idk try exit clean
just sigkill-ing everything right away is just plain wrong
i wonder the reasoning

watchdog...
"This is required to increase reliability and make sure that regardless what happens the best is attempted to get the system working again."
i stopped reading after that gem

audit is still a better system and it's scriptable

systemd is an OS...
so is linux, and i can't find great many things wrong with linux (none that won't be solved with wayland plus a couple minor ones, that is)

I'm having a hard time parsing some of this, but I'll try to address those points which I THINK I understand, however, in general, references to particular issues would be helpful.

still it won't kill a root process if there is a user one that takes up ram

I'm not quite sure what this means. Did you read the above? OOMkiller can be disabled for specific processes, so the above is entirely possible. I admit, I may be misreading your question.

first try sigterm, so the process can idk try exit clean
just sigkill-ing everything right away is just plain wrong
i wonder the reasoning

Again, did you read the links? "Processes will first be terminated via SIGTERM (unless the signal to send is changed via KillSignal=)"

[stevenc]

I guess that your point is that since this duct tape is sufficient for your world, it should be adopted everywhere

That's right. I was suggesting that everyone, everywhere has to use my cron one-liner... or they will become *irrelevant*. Seriously, did you really think that was my point?

No, my point was that: if I merely wanted process supervision, it can be done extremely simply with the existing, familiar, commonplace components of GNU/Linux or BSD. The exact method can be based on individual circumstances or expertise.

I also tried to illustrate that systemd seeks to replace much that is familiar, and give us something complex that requires learning anew. Therefore I expect it to have many bugs and/or be more difficult to understand during times when it doesn't work as expected I consider these to be 'costs' of migrating to systemd, and I think it's too much to sacrifice.

[F.Ultra]

Chrony is lighter than ntpd despite offering some additional features.

Chrony is smaller than NTPD since NPTD supports tons of different hardware clocks needed to build and maintain a stratum 1 server. Runtime wise they should both use so little resources to not be noticeable.

[misc]

That's right. I was suggesting that everyone, everywhere has to use my cron one-liner... or they will become *irrelevant*. Seriously, did you really think that was my point?

No, my point was that: if I merely wanted process supervision, it can be done extremely simply with the existing, familiar, commonplace components of GNU/Linux or BSD. The exact method can be based on individual circumstances or expertise.

I also tried to illustrate that systemd seeks to replace much that is familiar, and give us something complex that requires learning anew. Therefore I expect it to have many bugs and/or be more difficult to understand during times when it doesn't work as expected I consider these to be 'costs' of migrating to systemd, and I think it's too much to sacrifice.

My point is that you simple way is buggy. It doesn't handle stuff like rate limitation ( hello flood of mail if you cannot start the system at 2AM ) , it can be fooled by a unprivileged user, it doesn't scale. So yeah, that's simple to make crappy code. And so you just show that if we depend on the individual expertise, then we end with a potential share of crappy systems. Now, for sure, if you jusge the quality of others people code based on the number of code in your one liner, that's likely bad. But not everybody do have a ratio of 1 bug per line.