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

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

[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

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

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

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

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.

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

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.

[Ericg]

Yep!

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