Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Debian committee members vote for systemd as init system

lists.debian.org

Post reply on HN
Print view View original

141–150 of 152 posts

Re: Debian committee members vote for systemd as init system

#141

Post by CameronNemo »

acdha wrote: post #51
druiid wrote: post #20

Earlier quoted context omitted.

Not that I can think of. Upstart is slightly simpler than systemd to build configuration files for, but that's also because it doesn't have any advanced features like memory/processor/IO limits or the like. Additionally it doesn't even properly manage child processes... so you have to use wrappers to get Unicorn management working right in Upstart.

Upstart took years to add support for setuid/setgrp and still doesn't have basic features like a respawn delay which shipped in launchd (or 90s inetd) before upstart was released. There's still no integrated way to reliably kill malfunctioning child processes and the commands will block until success so you're going to need to kill -9 a lot when e.g. adjusting a script for a daemon which forks. I was rooting for upst…

>still doesn't have basic features like a respawn delay

What are you talking about?

http://upstart.ubuntu.com/cookbook/#respawn-limit

Re: Debian committee members vote for systemd as init system

#142

Post by CameronNemo »

SEJeff wrote: post #65
CameronNemo wrote: post #38

Earlier quoted context omitted.

systemd breaks LXC and lmctfy. systemd is not event based (matter of taste, I guess, but I prefer Upstart's model).

What are you talking about? CoreOS uses docker + systemd extensively and docker is just a pretty wrapper ontop of lxc. https://coreos.com/docs/launching-containers/launching/getti...

systemd post 204 requires that it is the only cgroups writer, and tramples over every other writer. Some have said that this is because of a decision by upstream kernel maintainers to allow only one cgroups writer, but this decision has not yet happened. Do you know what version of systemd coreOS uses?

Re: Debian committee members vote for systemd as init system

#143

Post by CameronNemo »

schwarze_pest wrote: post #137
mateuszf wrote: post #86

Earlier quoted context omitted.

Doesn't work on Linux.

Launchd works on Linux (and xBSD) -- in the sense, that it can be ported without much effort. Systemd in contrast only works on Linux because it relies heavily on kernel features like cgroups.

The code is shitty and there is no sysvinit script compatibility.

Re: Debian committee members vote for systemd as init system

#144

Post by oblio »

kashchei wrote: post #106
oblio wrote: post #90

Earlier quoted context omitted.

I find hard to read such comments and think that they are valuable contributions anymore. First of all, Pulseaudio was not the biggest success, true, but can't someone learn from their mistakes? Both are also living, moving software products that continue to improve, as you said, "development marred with huge number of bugs that ruined audio on Linux until recently" - key words: "until recently". Secondly, about the…

Also: just saying that something is a myth does not make it any less true. The whole point is that systemd (and Pulseaudio) is anti-Unix because its author does not understand Unix design, how would his opinion be of any value in this matter?

I find his arguments quite compelling and honestly, at this stage saying "the author does not understand Unix" just sounds silly.

Judging by his work and his writings, Lennart probably sleeps with a copy of "The Unix Programming Environment" or other such classic under his pillow. He probably knows Unix 10x better than you or me (feel free to point me to your resume/bio if my assumption is wrong :) ).

Just say that you don't agree with his design.

That's fine and it's acceptable. It also turns this debate into something kind of like Linux versus Minix. Working code (his) wins for now ;)

Re: Debian committee members vote for systemd as init system

#145

Post by _ak »

Gibheer wrote: post #87
_ak wrote: post #79

Earlier quoted context omitted.

IIRC, when a presentation a few years ago at Chaos Communication Congress revealed systemd security issues, Lennart Poettering argued that these issues aren't a problem because they're resolved on Solaris and will be as soon as Linux gets some additional security mechanism. That sounded to me like systemd would also (theoretically) support Solaris.

Solaris had an init system like systemd for some years, called SMF. It was first released in 2005, the same year Apple released launchd. It features service dependencies, log collection, fault detection and much more. One of the biggest differences is probably the usage of config files. SMF uses XML files to describe the service and its variables and a program called svcprop to edit variables and create new instances…

I was aware of that, and it wasn't my point. I was talking about the supposed portability of systemd. The question remains, is systemd really Linux-only, or portable to some degree?

Re: Debian committee members vote for systemd as init system

#146

Post by gingerlime »

CameronNemo wrote: post #139
gingerlime wrote: post #91

Earlier quoted context omitted.

> Because Upstart does not use cgroups, it can not kill all of a services children (just that service), and so zombie services might be problematic. from my (very limited) experience with upstart, even the upstart scripts themselves can get into a unrecoverable zombie state[1], where the only workaround is to do one of the following 1) reboot ; 2) run some crazy-ass script[2] that forks processes until the right pid…

You should use init-checkconf before enabling the scripts.

Thanks for the tip. An init system that gets itself into such a fragile position is a signal that something isn't quite right (not to mention there was not even a response to this bug report, which isn't a great sign either)

Re: Debian committee members vote for systemd as init system

#147

Post by acdha »

CameronNemo wrote: post #141
acdha wrote: post #51

Earlier quoted context omitted.

Upstart took years to add support for setuid/setgrp and still doesn't have basic features like a respawn delay which shipped in launchd (or 90s inetd) before upstart was released. There's still no integrated way to reliably kill malfunctioning child processes and the commands will block until success so you're going to need to kill -9 a lot when e.g. adjusting a script for a daemon which forks. I was rooting for upst…

>still doesn't have basic features like a respawn delay What are you talking about? http://upstart.ubuntu.com/cookbook/#respawn-limit

That's unusafe in production: unless you have a very short-duration problem it'll retry a few times and then pretend you wanted the process stopped. Something like a down database or NFS server will still require you to restart everything in a cluster outside of upstart.

They should have copied prior art from launchd or some inetd implementations where the delay has a back off mechanism with some configurable min/max limits.

Re: Debian committee members vote for systemd as init system

#148

Post by druiid »

acdha wrote: post #147
CameronNemo wrote: post #141

Earlier quoted context omitted.

>still doesn't have basic features like a respawn delay What are you talking about? http://upstart.ubuntu.com/cookbook/#respawn-limit

That's unusafe in production: unless you have a very short-duration problem it'll retry a few times and then pretend you wanted the process stopped. Something like a down database or NFS server will still require you to restart everything in a cluster outside of upstart. They should have copied prior art from launchd or some inetd implementations where the delay has a back off mechanism with some configurable min/max…

Agreed. The inability to specify a restart delay is just silly. It makes that functionality only useful for OOM type issues where the main process dies unexpectedly. Network transition type problems and you're going to have-a-bad-time.

Re: Debian committee members vote for systemd as init system

#149

Post by acdha »

druiid wrote: post #148
acdha wrote: post #147

Earlier quoted context omitted.

That's unusafe in production: unless you have a very short-duration problem it'll retry a few times and then pretend you wanted the process stopped. Something like a down database or NFS server will still require you to restart everything in a cluster outside of upstart. They should have copied prior art from launchd or some inetd implementations where the delay has a back off mechanism with some configurable min/max…

Agreed. The inability to specify a restart delay is just silly. It makes that functionality only useful for OOM type issues where the main process dies unexpectedly. Network transition type problems and you're going to have-a-bad-time.

Yeah – things like that or needing a number of major releases before getting reliable console support, setuid/gid, restart not implying start, etc. left me wondering if any actual sysadmins were involved in the development. Most of these would have been on my group's list of basic 1.0 requirements…

Re: Debian committee members vote for systemd as init system

#150

Post by teddyh »

jordigh wrote: post #8

For a fun retelling of the events (I think this only works on Firefox): http://aceattorney.sparklin.org/jeu.php?id_proces=57684

That thing is unbelievably more awesome than I would otherwise have assumed.

Who made this (and part 2)? How can I find out if any more parts are made?

Post reply on HN