Systemd 213 Adds A Time Sync Daemon

[TeamBlackFox]

systemd is the duct tape between GNU and Linux. Congrats, systemd just got one closer to making the entire userspace consist of a systemd pantheon.

I just realized, its the unholy trinity of computing: the Linux, the GNU and the systemd.

In more serious terms I'm glad to see Linux resembling OS X more and more. Launchd and systemd are like twins, separated at birth.

[Ericg]

Yep!

Incase anyone doesn't read or follow the mailing list... It was an early April fools

[interested]

systemd is the duct tape between GNU and Linux. Congrats, systemd just got one closer to making the entire userspace consist of a systemd pantheon.

I just realized, its the unholy trinity of computing: the Linux, the GNU and the systemd.

In more serious terms I'm glad to see Linux resembling OS X more and more. Launchd and systemd are like twins, separated at birth.

Seriously, if you really hate Linux, GNU and systemd, why on earth are you here in this thread at all? This thread is all about Linux and systemd. It is not that anybody asked about your opinions or even care about them either.

Wouldn't you agree that your stalking of systemd threads is a classic definition of "trolling", the same way as if a an enraged Plan 9 OS user constantly posted in all BSD threads on how much he hated *BSD?

The systemd opponents have lost each an every technical argument against systemd on Linux the last couple of years, mainly because they have been so totally ignorant what systemd is and what it actually does. Instead the system opponents, like you, rely on general hateful, but technically nonsense remarks, in a vain attempt to poison the systemd well. It may give you satisfaction to rant and rave against systemd, but it is exactly why you lose the discussions.

Think about that when BSD starts to develop its own counterpart to systemd: if you keep on the negative campaigning you will lose out on *BSD too. And yes, it is only a matter of time before the first BSD distro will attempt to clone systemd.

[TeamBlackFox]

Think about that when BSD starts to develop its own counterpart to systemd: if you keep on the negative campaigning you will lose out on *BSD too. And yes, it is only a matter of time before the first BSD distro will attempt to clone systemd.

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.

And on that last point, there are no "distros" of BSD. We have variants or forks. None of the 4 major variants want anything to do with systemd, if they want a process supervisor, they have OpenRC which doesn't use PID 1 and doesn't attempt to take over every daemon. Of course some are trying to port launchd to FreeBSD, but that will never be merged mainline. Maybe as a port, but even still, most FreeBSD users I know aren't into OS X.

[interested]

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.

I think your inability realise your own behaviour is part your problem. Again, if you hate Linux, GNU and systemd, why do you post "a sarcastic joke" at the expense of Linux, GNU and systemd, in a thread about systemd if it isn't to troll for responses?

I think to you all need to remember that you are "ambassadors" of your OS choice too. For some reason several BSD-users (and non-Linux users) tend to show up at these systemd threads where they apparently feel compelled by an inner need to spew out a rage rant against systemd, Linux, GNU and the GPL license too.
Not really sportive behaviour, and is bound to reflect badly back on all BSD users.

[stevenc]

if they want a process supervisor, they have OpenRC which doesn't use PID 1 and doesn't attempt to take over every daemon

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.

[interested]

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.

The process supervising in systemd is a quantum leap better and more advanced than that. All processes are supervised automatically and can be configured with ratelimits on restarts, resource allocation (cpu time, memory, IO etc.) thanks to cgroup. It also knows about dependencies between services, so it can intelligently bring up all the needed services in the correct order, if one or more should crash. One could fill pages about the process supervising features that systemd has like OOMkiller protection, actual being able to terminate processes correctly, waking up from hibernate by timer, socket activated processes, using a hardware watchdog to supervise itself thereby making a total chain of system supervising, etc. etc.

But it is not only about having many more features, it is also about scaling. These days a lot of Linux deployment is mass deployed servers: think 10.000 machines each with 100 processes, and we are talking one million processes that needs to be supervised. With all due respect for your solution, that may work very well for your work flow, your solution just won't scale very well. If eg. 10% of the processes are crashing due to a problem, the MTA's would send 10.000 emails per minute to all the System Admins. There are other, more advanced process management solutions around than your simple solution, but they don't come anywhere near the power of systemd either.

[dee.]

I think your inability realise your own behaviour is part your problem. Again, if you hate Linux, GNU and systemd, why do you post "a sarcastic joke" at the expense of Linux, GNU and systemd, in a thread about systemd if it isn't to troll for responses?

I think 90% of BSD users are just hipsters. Think about it:

"I used to use Linux, before it got all popular! Now I use this much more obscure OS that you probably don't know about."

[gens]

The process supervising in systemd is a quantum leap better and more advanced than that. All processes are supervised automatically and can be configured with ratelimits on restarts, resource allocation (cpu time, memory, IO etc.) thanks to cgroup. It also knows about dependencies between services, so it can intelligently bring up all the needed services in the correct order, if one or more should crash. One could fill pages about the process supervising features that systemd has like OOMkiller protection, actual being able to terminate processes correctly, waking up from hibernate by timer, socket activated processes, using a hardware watchdog to supervise itself thereby making a total chain of system supervising, etc. etc.

But it is not only about having many more features, it is also about scaling. These days a lot of Linux deployment is mass deployed servers: think 10.000 machines each with 100 processes, and we are talking one million processes that needs to be supervised. With all due respect for your solution, that may work very well for your work flow, your solution just won't scale very well. If eg. 10% of the processes are crashing due to a problem, the MTA's would send 10.000 emails per minute to all the System Admins. There are other, more advanced process management solutions around than your simple solution, but they don't come anywhere near the power of systemd either.

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

[liam]

All seperate daemons, all separate binaries. Systemd: Umbrella Project, like Apache, not Systemd PID1... Troll argument is troll

I wish this could be a sticky to every article Michael writes about systemd...except for the last part.