121–130 of 193 posts
Doesn't work here on Ubuntu 16.04 xenial
while true; do NOTIFY_SOCKET=/run/systemd/notify systemd-notify ""; done
So while this is a bug, the author is overreacting just to make systemd look bad.
Earlier quoted context omitted.
> "Systemd is winning because they showed up and basically nobody else did" I can't see how you would qualify this statement, which is utterly false. Specifically, systemd adoption was the result of political pressure by LP (the author), who works at Red Hat. There are plenty of other choices out there. The idea that systemd won because of some kind of meritocracy is wrong. It was mostly political with some technical…
systemd is by far the best linux init system. The options are sysvinit, OpenRC, Upstart, and systemd. Of those, the only reasonable choice is systemd. Upstart was almost good, but its really frustrating to use. OpenRC is decent, but confusing. systemd solved problems, not only that it solved them well. The scope creep of systemd is something that is a bit alarming, however even with the creep it's doing a good job. T…
Before, I could simply do "sudo service xxx start". Now, with systemctl, everything is much more cumbersome. Just run "systemctl list-units". Ho boy, you get a huge list of... things. Not just what used to be called services or daemons, but units belonging to mount points, /dev entries, and who knows what.
Granted, it is probably easier to create service scripts for developers than with init.rc or upstart (although I never had a problem the few times I had to muck with them). But as a simple consumer, I do not feel systemd solves any problem I had. It just made things some things that worked fine before slightly more confusing, and there are some regressions every now and then while other programs are getting ported to systemd.
I've been thinking for a bit that it's reasonably easy to write a PID 1 that reaps children and sends siginfo_t structs over a pipe to PID 2, which can be an init system as monolithic as you want. Of course, it would also be simple for the kernel to allow PID 1 to die/crash, and just restart it instead of panicking. I don't know why the kernel continues to treat PID 1 so specially—if the ewontfix.com PID 1 is suffici…
> I don't know why the kernel continues to treat PID 1 so specially By design all processes inherit from PID 1 (directly or indirectly), so you always have an unbroken tree from every process back to PID 1. PID1 aka init is supposed to do bookkeeping (e.g. zombie processing), and if PID1 crashes the bookkeeping records are lost. Because of this, it is better to fail hard, instead of allowing for corrupted process tre…
By "Breaking this" you mean "fixing the fact that pid 1 can't crash and restart"?
> Because of this, it is better to fail hard
It can't be fixed because it would "break compatibility" where that "compatibility" is that the machine should panic?
You're not really making a good case for why this can't be changed.
Why not
* pid 1 exits
* kernel re-executes init as a new pid 1
* userspace continues on as if nothing happened.Earlier quoted context omitted.
launchd was for OSX.
Oh, whoops. Wasn't there another Linux init system around the same time?
Earlier quoted context omitted.
> However, linux is missing basic functionality other os's offer, and systemd is showing up and trying to fill in those blanks. I'm curious what functionality other OSes had that Linux did not before systemd came along. It seems to me that it has been subsuming functions of other systems on Linux that were already present, as opposed to offering anything new. Socket activation? inetd/xinetd. Timed start of programs?…
> I'm curious what functionality other OSes had that Linux did not before systemd came along. Uniform daemon/service handling. Just look at the scripts in /etc/init.d (or wherever they are located in your particular SysV init setup). It's a total mess. The rest of what systemd offers I can't comment on because I'm not familiar with it. But it is clear to me that systemd's declarative .service files are a billion time…
However, imho, shell scripts are great for that kind of work. Services come in all sort of shapes, some are proper daemons (fork, cd /, close([stdin, stdout, stderr]) and the rest), some are a little worse to say the least. And more often than not, the later is your super business critical important app built in house by incompetent developers.
The point being that services comes in all forms and shapes, and having a scripting language for integrating them and, if needed, compensating for crappy software is extremely useful.
Another aspect is that programs contain bugs, and the more complex a program is, the more bugs it contains. Keeping PID 1 as simple as possible should be a goal, nobody needs an http server inside its init system (or a dhcp client, or a dns resolver or...).
For some years now, the Gentoo Project has OpenRC/runscript (specialized shell for init scripts). It works really really well and it's quite simple to write an init script in it. It's a bit sad that it wasn't more considered in other distributions.
Earlier quoted context omitted.
Ah, yes: When is a bug not a bug? According to the systemd developers, it's when we don't encounter it on our personal machines.
... And also when they can pass the buck to kernel developers, even when it's not a kernel bug.
Earlier quoted context omitted.
I think Systemd is winning because it works (in the overwhelming majority of cases), and no one cares about init systems except the vocal minority.
Can we please just have one OS we use in data centers and servers whose features and development is guided by professionals, not rubes? I'm so sick of people telling me I'm not the target user or some variant thereof. Linux is not OSX or Windows, and not swayed by arguments of the form "most people don't are about that". I do. They should. And the fact that they don't shouldn't result in crappy operating systems.
For every person whinging online about systemd, there are hundreds of people using it every day in their laptops and servers without giving it a second thought.
Earlier quoted context omitted.
There are exactly two compelling (for me) arguments against systemd, and one that seems to result from it's current focus: * Binary log files (WHYYYYY; OTOH you could argue that the only proper place to do logging is to a remote database.) * Monolithic nature - everything gets shoved in to the daemon, making it harder and more unusual to do things without it. * Servers - systemd seems to be focused on a desktop lifec…
Yes, these are also reasons I dislike systemd. Also, one of the original selling points of systemd was "It will reduce boot times significantly!" ... And then it ends up that systemd is actually slower to boot than any of the other ones out there.
It was not.
http://0pointer.de/blog/projects/the-biggest-myths.html
Myth: systemd is about speed.