Systemd 213 Adds A Time Sync Daemon

[interested]

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 think the notion, that a modern OS shouldn't have inbuilt process supervision, but instead relying on its end users to program such a solution, is undefendable.

The OS should provide the framework and programs, just like systemd does, so that Linux Security Modules (LSM) and other kernel features can be used. The end-users should tweak declarative text config files, not be forced to program just to get a bare minimum functionality. Relying on declarative text config files like systemd does, also makes it much easier to machine parse the config files, which is necessary these days with automatic mass deployment of servers.

The non-systemd distros doesn't seem to have any standard process supervision system, in fact, most of them doesn't have anything at all in that regard. The solutions that exist, are really quite limited and doesn't increase security by hardening the process. What you learn in one distro, can't be used on another.

All systemd Linux distros now have automatic process and service supervision, that can utilise powerful kernel features that dramatically increases security and stability. The supervision chain is total, including the supervising process itself, and is configured with declarative text files, that are easy for both humans and machines to parse and edit. Once learned, the knowledge can be extended to all systemd distros.

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.

Learning new stuff all the time just goes with the territory of computing. The main driving force behind the changes are that the problem domain keeps shifting, often increasing in both scope and complexity. The 1980-90 way of running a server is dying. These days it is all about virtualisation, OS containers, Big Data, Cloud Computing, mass deployment, extreme resource utilisation, massive scaling, and doing all this in a secure and easy manner. Any OS that can't compete in these domains will become irrelevant in a short time.

So while sysvinit (though always a hack) would work in well enough on a single server, running on metal, dishing out a few simple services like http, or ftp, while idling most of the time, it simply doesn't work well for modern computing problems.

There you have it; if you want work in IT, you just have to learn something new all the time, because they way we use computers change. People not making a living in IT can "stop the world" if they want to by using old software: WordPerfect 5.1 for DOS is still an excellent word processor and may fit the work flow of somebody perfectly well in this day and age. But it is not a general solution for the majority of end-users.

Like it or not, if you want to make a living using Linux, you just have to learn to use systemd. Systemd covers a lot of ground, so there is much to be learned. However, the documentation is there, and once you get the principle behind each systemd component it isn't hard to get to know.

[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.

[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.

[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.

[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=)"

[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.

[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.

[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.

[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.

[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)