Slashdot Mirror
Debate Over Systemd Exposes the Two Factions Tugging At Modern-day Linux
walterbyrd (182728) sends this article about systemd from Paul Venezia, who writes:
In discussions around the Web in the past few months, I've seen an overwhelming level of support of systemd from Linux users who run Linux on their laptops and maybe a VPS or home server. I've also seen a large backlash against systemd from Linux system administrators who are responsible for dozens, hundreds, or thousands of Linux servers, physical and virtual. ... The release of RHEL 7 has brought the reality of systemd to a significant number of admins whose mantra is stability over all else and who perhaps had not waded into the choppier waters of Fedora or Debian unstable to work with systemd before it arrived in RHEL.
I know quite a few of us in hacker culture who hate the fact tha systemd does not feel UNIXy at all. It breaks practically every principle of the UNIX philosophy. Reminds me of working with windows, and that is never fun.
IMO, administrators' backlash against systemd is just plain wrong. It enables some seriously cool administrative features, a lot of which are very much utilized by CoreOS to make setting up and managing a cluster of servers a breeze. Is creating unit files really so difficult? The syntax is not exactly complex. As for stability... I have never, not once, had a systemd related crash or anything of the sort. Some distros do particularly suck at packaging systemd, however (I'm looking at you, Gentoo). Give it a try, preferably on something like Arch. If you still have complaints... well, stick to slackware, I guess?
I've seen an overwhelming level of support of systemd from Linux users who run Linux on their laptops and maybe a VPS or home server
I haven't seen an overwhelming support anywhere. Most people who run Linux on their laptops say, "meh, as long as it boots."
This article is a LOT better than the previous one by the same author. He makes his point clearly, that he doesn't like SystemD, as a sysadmin he doesn't want binary log files etc; but if someone else feels like they need systemD, maybe there should be a fork to make place for those people. It's a fairly kind, open attitude. Maybe we should have more of that around here.
"First they came for the slanderers and i said nothing."
Who controls the system, the system administrator or software developers?
How many packages come with init scripts that actually work?
How many packages have dependencies that aren't documented?
How many packages work only on a narrow subset of environments that are tested by the developers?
The answer, of course, is "all of them."
Today, the competent administrator can control startup, dependencies, etc on a granular basis. With systemd, that control has gone - somewhere else.
Who gets called when stuff fucks up because some bozo fucked up their package's systemd configuration? It won't be the package developer, that's for sure.
I Agree to a point. I believe you are talking more about the "Doing one thing well" kind of aspect like most of our tools give us. But there is also the fact that we have enjoyed the benefit of choice. (Choice of shell, choice of desktop environment or window manager, etc). Should there be a choice at install time whether your system is sysdemd or sysvinit or makefile or whatever I think it would be a good thing (maintainability be damned though). Me personally I will stick with my sysvinit style startup. Has /. done a poll about this yet?
I use LMDE on three laptops. I don't support systemd. Ignoring the technical arguments, it's been forced down people throats and that alone should be enough for people to step back and halt it's adoption.
That aside, will people please stop this constant masturbation about startup times? There are way, way, way more important things to deal with than edging out a few more seconds. Systemd provides me with no perceivable gains. I don't sit down, press the power button, then stare at the screen until I can log-in, then wait again for the desktop to load. I press the power button, plug-in the laptop, take out my mouse, manager whatever papers I'm going to use, etc... and then log-in. When I had a desktop, I almost never rebooted it. Startup times matters even less on desktops.
However, systemd does provide me perceivable losses. Time spent arguing over systemd could have been spent making everything else better. Systemd removes options, that while I'm not doing anything with at the moment, I like the ability to choose in the future. There are way too many instances of previously good companies/projects suddenly fucking over it's users (of which systemd is becoming an example of in and of itself). I prefer not being locked into something. Systemd didn't present itself as an option, it demanded that it be a requirement.
Personally, I find it crazy that Microsoft and other large software companies are doing more to support scripting while somehow the linux community is being dragged into less and less scripting. (article mentions desktop users don't want to know how to script anything). We need more scripting not less. I'd love to be able to pull out the couple commands I use that are buried in menus and place them as buttons on the menu bar. I don't want an AI to do it for me, I want to take my common commands and make them easier to navigate to and execute or completely automate them.
wow talk about not knowing whats going on, from day one there's been multiple factions doing their own thing on every little single nitpicky detail, which is why linux is both good, and a fucking nightmare to deal with
keep squabbling
The division is not between administrators and users but between luddites and users. Luddite administrators generally spent years learning all the arcana of Unix administration and simply can't accept that a large body of this knowledge is now inapplicable. THAT'S the source of "systemd divide".
Oh, and in our company we manage clusters of up to 30000 machines for our customers. And we simply _love_ systemd because it makes so much easier to make reliable clusters.
Administrators dislike constraint based systems.
This should surprise no one. One of the problems with a constraint based system is that you don't control the precise ordering of things.
This doesn't bother the Debian folks, because their build system is a constraint based system. If they have a package to install which has dependencies, they don't control the actual build order of the dependencies, or of their dependencies, and so on. Turtles all the way down. You do an apt-get install foo, and it's going to try to build subcomponents when they become available to try to build. And if they fail to build, they don't care: they "try again later", in case something that happens later satisfies the dependency that wasn't satisfied the first time around.
This is very disturbing to system administrators, who like things to be both orderly and predictable. All dependencies should be mapped out, known, and explicit. If something gets tried now, and fails, the correct response isn't "We'll try again later!", it's "Stop! Someone fix this fucking thing, it's obviously broken".
The build system is not deterministic; if there are two components, and one has a subdependency on some X of "at least version N", and another has a subdependency on X of "at least version N+2", then depending on the vagaries of network overhead, it's possible that half your code gets built with version N and the other half gets built with N+2, and things break. Things breaking is in fact far more acceptable to a system administrator than "things act weird", and "things act weird" is at least deterministic for a given build instance, and far, far, more preferable than "things sometimes work and sometimes don't".
So system administrators dislike Debian for large system installations. And they dislike systemd for starting things up and shutting things down.
A desktop system is far, far more forgiving: "It's not working; I'll just reboot!". As long as things "mostly work", then things are great! "Look! It's as good as Windows!".
Note that launchd in Mac OS X has many of the same problems as systemd; it's also a constraint based system. It's somewhat worse, in that it insists on controlling file descriptors and sockets and Mach ports for the things it starts - which means you have to rewrite a lot of at least the startup code in most Open Source software to tolerate being run by something that opens the files and sockets that it expects to do itself. But that's just a lot of make-work, and people who are paid to do work are paid because it's not something they'd be willing to do voluntarily, for free, and that's what they're exchanging for the money they are getting in exchange for putting up with that part of the job.
Unlike the people making things work with launchd, though, the people expected to make things work with systemd aren't being paid. And so systemd represents make-work and change for chage's sake, which doesn't sit well with volunteers.
--
So yeah, a lot of people find systemd annoying. Kirk McKusick once accused "vnode" as being "the structure that's taken over the kernel"; in Linux, systemd is fast becoming "the program that's taken over user space".
How this will all play out, I don't know, but don't expect it to be resolved any time soon, given the dichotomy between the philosophies of the stakeholders involved.
Systemd articles have become the new Slashdot clickbait. It seems every freakin' day there's another "discussion" about that unholy abortion.
I do not fail; I succeed at finding out what does not work.
It's not just the init, it's also the applications that are being infected with Lennart-ware, e.g. gnumeric. It's a great spreadsheet, but recently it's been picking up various egregious hard-coded dependancies that simply don't make sense. This occurs mostly via GTK, which seems to pull in a significant chunk of GNOME.
I run a minimalist Gentoo desktop, and I notice when additional dependancies are dragged in. The past year or 2 has seen goffice, ghostscript, harfbuzz, dbus, and various other crap become hard-coded dependancies for gnumeric. It was not necessary a couple of years ago. If I had several million dollars, I'd hire a bunch of progragrammers to port gnumeric from being dependant on GTK to being dependant on FLTK (Fast Light ToolKit) http://www.fltk.org/ Some of the money would go to ongoing maintenance.
Another few million dollars, and I'd like to hire a team to hack and slash away at Firefox. I was around when "Phoenix" was forked as a lightweight alternative to the Mozilla web-browser. I savoured that promise. That promise has been dashed into the ground, with a Firefox that's bigger, heavier, and slower than the original Mozilla ever was. Time for a new fork.
I want GNU-Linu-x, not GNOME-Lenna-x
I'm not repeating myself
I'm an X window user; I'm an ex-Windows user
...is Unix. When choice is taken away you are left with Windows.
Time is what keeps everything from happening all at once.
Whether one dislikes systemd or not isn't necessarily because of what it does or doesn't do. The issue for many people (myself included) is simply that it's a monolith that keeps trying to grow larger in an "open" world that was meant to stand for a certain amount of platform agnosticism and component independence.
I realise that systemd can make life easier for some more novice users but to be true to the spirit of the open source community I would expect it to be optional where it can be so. When it starts to intrude into critical areas and make itself mandatory in some releases, that bothers me. It makes me think that the whole business is a sneaky attempt to subvert the Linux kernel and eventually take control of Linux as a whole.
Maybe. Currently we have every app maintaining its own configuration file(s) in miscellaneous directories under the user's home directory in non-standard format and each application implementing its own configuration parser.
Your comment, along with all of the others, proves to be that nobody that dislikes systemd has actually used it.
Required service dependencies are *absolutely* trivial, unidirectional or bidirectional.
This whole comment section is hurting my head. So so so much misunderstanding and untruth.
On the contrary; I've fixed a number of the dependency orderings in ChromeOS using systemd. Like I said, it's fine if you are OK with rebooting, and as you said, it's possible to express the dependencies correctly. I don't think we are contradicting one another.
It's also possible to explicitly specify correct build order dependencies in the Debian build system, so that it can avoid retries. My issue is that it's also possible to express the dependencies as loose constraints, and things can still be made to work (rebooting in case the mouse didn't start up correctly in ChromeOS was one of the things I fixed; 95% of the time, it started fine, but the first reboot after an upgrade, before the boot cache files had been built, it didn't, due to timing). The Debian build system does it by retrying.
The problem is that people depend on this behaviour to get them out of jams, rather than drilling down and fixing the missing underlying dependency specification, *because the system _mostly_ works without them needing to do so*. And *that's* the problem. If it just freaking *broke* outright, like a reasonable system, you'd know (A) what to fix and (B) that you didn't have any more hidden timing related crap lurking in the shadows, which wouldn't show up in in house testing, but might show up as a heisenbug at some customer site. That's just not acceptable.
Systemd has it's downsides. The real downside is that you have so much complex code running as root. most other complaints can be dealt with.
Binary logfiles: You're not supposed to keep important log files on the local machine. Send them to your central logging facility where they are stored in a database. If the machine is still running, you can use the appropriate tools to look at the binary log files for debug. All your logging, stats and alerting should be centralized anyway.
Doesn't feel unixy: Get with the times. It's scriptable and tweakable more than ever. Just get used to the way it works.
Solution looking for a problem: Just not true, see the benefits.
Systemd is one of the options to solve some problems that have been pestering unix for a long time.
Dependency in services: Systemd can restart all dependencies on a service in the right sequence if you have to meddle with one part of a stack
long startup times: Systemd has the possibility to start up things in parallel. No long waits for earlier systems that your service doesn't depend on. Mostly useful for mobile users, but HA systems benefit too due to shorter maintenance downtime
Location/circumstances specific profiles: Depending on where you are and what kind of facilities you have available, your system can "adapt" by changing power profiles, network connectivity, firewalling and whatnot. Primary benefits are for mobile users, but servers changing load depending on things like overheating, having to run on UPS power and such are also quite useful.
Systemd isn't the only project that wants to work this way. Upstart is another one that at least wants to deal with the startup concurrency and dependency problems of classical init. Sun (Oracle) Solaris SMF is also a good example of this line of thinking.
While you can have doubts about the amount of complex code and forks to 3rd party code done by systemd while running as root, I don't think it's useful to complain that someone moved your cheese and took away the init scripts you used to use in the old days. Once you figure out how to work with the new tools, you'll find it's way more tweakable and controllable than classical init. If in the end you choose for init or a different alternative, that's up to you, but at least investigate and educate yourself, before you start complaining with arguments that just aren't true.
I was promised a flying car. Where is my flying car?
One of nodes in your 500-node cluster is hanging because SysV scripts shat down its pants yet again because of a subtle race condition. Reproducing it locally yields nothing. Logging in SysV is nonexistent so debugging the issue is non-trivial. All while your cluster is frozen waiting for that critical DB node to start.
Now enter systemd. The traditional race conditions are solved right away. No more PID races, clean dependencies on mount points. In case of a service failure, its stdout/stderr are readily available. Boot graph with all the dependencies clearly shown is waiting for you to check it. The system status (including service watchdog timers) is easily streamed into an external monitoring system..
Yeah, sure SysV scripts are better.
from your post you sound like the sort of admin that doesn't test new systems to destruction before deployment so then i'd also be worried about you wanting to update working machines
"The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
" simply that it's a monolith " - that again is a reworked dictionary definition to suit an argument. systemd is not a monolith
"The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
SysV is not better. But BSD init is not worse.
Yet another clueless anti-systemd rant by Paul Venezia, yawn.
So now he goes on an ad hominen and labels systemd proponents as clueless noobs, while serious admins hate it. Right. I, for one, in one of my duties as a professional system admin manage hundreds of Linux machines, can't wait until we finally get rid of that SysV init crap in favor of systemd (I won't rehash all the advantages systemd brings here). Due to EL7 switching, we'll eventually get there, thanks Redhat!
1. systemd was FORCED down my throat by just issuing a "pacman -Syu". it took me THREE fucking days getting my desktop back to normal after sifting through a barely comprehensible arch wiki page. systemd had long since been adopted by other distros and i was amazed how BROKEN it still is.
2. systemd FORCED me to sit down and learn a new set of tools for NO reason. my system worked just fine before systemd. i've since migrated to openrc (thx gentoo devs and apg + artoo from the arch community for making it possible (relatively easy to adopt) on my system.
3. systemd VIOLATES EVERYTHING K.I.S.S. it tries to be much too clever and it makes me feel dumb
4. systemd GRABS everything. not just init. try to install gnome without systemd... no way you can do that without a major hassle.
5. systemd -FORCES me to jump through hoops and rely on the good will of some very nice folks to provide me with a viable alternative. i have to rely on experimental and often buggy packages to get back to before where i had NO PROBLEM with init.
i hate SYSTEMD and this pottering can go to hell for what i care. thx for a whole lot of lost time. if it where just nothing and didn't force me to waste all this time i wouldn't even have cared... but this means WAR!
fuck you pottering. fuck you arch linux guys for violating your core principles and fuck all those ZEALOTS not giving me a choice in the matter and think they know what's best for me. this is the worst time being a gnu/linux advocate in like EVER.
on a positive note: thank you windows 7 for staying predictably stupid and giving me a working system while my linux init was broken for three days.
If you are full-time sysadmin having setup the perfect shop with sysvinit, you'll probably not see that many benefits. However, lots and lots of people don't have access to a resource like you. When systemd is properly integrated, these people will get a much better experience out of the box, e.g. daemon supervision, watchdog integration or better on-demand startup of services (for really cheap VPS stuff).
If you know your stuff, you'll have configured this by hand long ago - but most people don't know their stuff. systemd allows distributions a better default experience.
This is Slashdot. It is a violation of website rules to read any linked article.
And as usual, the embedded developers are barely at the table. Though I guess, to be fair, in this case at least, it is easier for us to bypass the debate and control what is on our systems... but after GPLv3 this invisibility has been a bit of a sore point.
Dude I call bullshit on you. You're talking about theoretical problems that no one ever really runs into ever. There are 2^15 PIDs available. You're not going to iterate over all of them and actually run into a PID race in an init script. That is not a thing. It's just something you might learn in an OS class or something because, well, it /COULD/ be a thing in that theoretically there is a race there, so it's good for learning about races (I guess...). But it's not a race you're ever going to run into in a million years unless you have a fork bomb in your startup scripts. And if you have a fork bomb in your startup scripts, you have bigger problems. And if your entire cluster is freezing because of that one node, maybe you should work on that single point of failure since computers _DO_ have hardware failures occasionally and you _ARE_ likely to get bitten by having a single point of failure like that.
But not because of sysvinit. Stop making shit up.
And you have a slightly lower UID than I do. Which means you should have grown out of your "disparage people who have more experience than I do because I'm so cool" adolescent phase by now. Stop talking about people who "can't see past their bash manual". That's not a thing, either. Having experience is a good thing. Unless you changed careers, you should have enough of it by now to see that. Look in the mirror and think about why your personal growth might maybe be going a little slower than it should.
Oh, SystemD? Well, I think those programmers should probably have spent their time solving real problems, and I'm suspicious of it, because it seems like it's reinventing the wheel, because of its questionable design decisions thus far (such as binary log files), and because Poettering's other brainchildren like PulseAudio are best avoided. But, given that there seem to be enough people who dislike it to support at least one mainstream distribution, I'm pretty sure I won't be stuck with it, so, if someone else likes it, good for them.
vi ~/.emacs # I'm probably going to Hell for this.
Let's start by saying that the death threats against Lennart Poettering are ridiculous and should not be tolerated.
That being said, the design of systemd confuses me. It seems ripe for all manner of stability and security problems. As I understand it, it bundles a large number of services into a single process, which takes place of the init daemon. That's guaranteed to cause all kinds of system crashes.
What I don't get is why it isn't split up into multiple processes. All the same functionality could be provided by having a simple core init daemon that loads a set (perhaps a small set) of child processes. It wouldn't take longer to load. The services and behavior would be identical. But it would be a lot more stable, because a child process could be restarted if it crashes, keeping init to a bare minimum.
What's even more surprising is that someone with some sense hasn't done exactly that: Make a wrapper for the systemd build that patches a few things and just compiles it differently, into a slightly larger number of binaries. This way, we can benefit from the unification of services, while maintaining stability, and Poettering would have to be intentionally self-destructive to try to keep breaking that wrapper every release.
I would rather run a server OS on my desktops than a desktop OS on my servers. That's why I use Linux as my main OS instead of Windows or OS-X. And I'll keep doing so, though I may, sadly, have to leave Debian after more than a decade.
Stop-Prism.org: Opt Out of Surveillance
*NIX "admins" (users with a better password, nothing more) fear systemd: Why? It makes doing what they do with arcane by hand configuration a snap for even midrange users. This takes away their 'magic power' (lol, not) and they fear for their jobs because of that simple fact.
Every article I read about Systemd somewhere mentions dependencies. I don't get it. My computer has handled those ever since openrc came out. For example, it knows not to start network server daemons such as ssh, httpd, etc... before the network. If you turn the network off it will automatically stop all those daemons first. Turn the network back on and they come back right after. That's about as complex as dependencies get on my system, everything else can and does start in parallel. If I did install some new magic daemon that depended on 5 others before it could run though the facilities are there in openrc for me to set that up.
So... what is so special about Systemd?
Currently we have every app maintaining its own configuration file(s) in miscellaneous directories under the user's home directory in non-standard format and each application implementing its own configuration parser.
That's a feature. Typical operating systems around when Unix were developed had structured files understood by the operating system. We can still have that sort of thing, through libraries, and indeed some applications make use of them. But not forcing it on applications leaves them free to implement their own backstores.
Many applications don't need to make use of a complicated configuration file format, and there are other real-world reasons not to conform to a system standard, such as cross-platform applications. Sometimes it's just not worth it to make all the changes to make your app a good citizen. And that's why all modern operating systems have the concept of unstructured files.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
It is, and this ridiculous claim that it's not so because it's not a singular binary is as telling as it is tedious.
Worse yet, it's a monolith that's ousted EMACS as the poster child for feeping creaturism.
Would you rather they use a massive hairball of interdependence that the developers themselves state are required even if you try and claim they are not?
When you cant win, ad hominem.
I think I missed the poll. Can someone support the statement with a poll/survey data?
My experience is the opposite.
There is enough of a divide over systemd to make it an option or a fork will result.
If debian does not allow turning systemd off, I think the following will happen:
- debian fork created, allow turning systemd off.
- majority of debian users adopt fork.
- majority of systemd people use Ubuntu or fedora.
- systemd-off becomes option in Debian
- systemd-off becomes option in Ubuntu and Fedora
Startup time matters? Hmm. Let's see.
15:11 up 39 days, 13:13, 5 users, load averages: 1.09 1.11 1.41
well that's my laptop, can't remember what I was doing 39 days ago or why I'd care how long it takes to boot, I could go make tea, or read a book, or whatever. Really not at all important.
Servers? Well, they may spend anywhere from ~2-5 minutes doodling around in the BIOS, so shaving a few seconds or whatever from the system boot time means they take about ~2-5 minutes still doodling around in the BIOS. If you've done servers right, there will be redundancy, so who cares how long server A takes to reboot when servers X, P, Q, M, and R are chirping merrily away. Sorry, but I'm just not seeing the need for speed.
valen% uptime
3:22PM up 168 days, 14:53, 47 users, load averages: 0.58, 0.36, 0.34
Oh no! My slow OpenBSD server will reboot slowly when I upgrade to 5.6. Oh, the humanity!
Processes need to be restarted when libraries and sundry components underneath them are patched.
When you patch openssl, you need to restart Apache, otherwise the running httpd will be using the old, unpatched libcrypto.
When you patch glibc, any processes that you do not restart will not bring the glibc patch into the memory of a running process, and will continue to express any vulnerability that you patched.
Ksplice seems like a really nifty thing, but as patches pile on, more and more of the running userland is out of date. Going for a long uptime means less trust over running processes.
This makes no sense to me.
Seems to me that re-boot time = startup time + shutdown time.
But, as I understand it, systemd advocates make a huge fuss about faster startup (which I have not noticed btw), yet the same systemd advocates claim claim that shutdown time is not important.
WTF?
- Hide everything in a binary blob
- Embrace monoculture
- Do not play well with others - especially UNIX
- There can only be one and so you must win at any cost
- Replace accepted standards with *your* standard
- Embrace, extend and extinguish because the people responsible for it have a culture which wants that
- Adopt Borg philosophy: resistance is futile, we have already won, why are you arguing?
- Be intensely hubristic: systemd is the best, therefore systemd is superior to all other systems, therefore systemd should to the jobs that other systems do.
Not since the day you stopping changing for better and looking for better things. You cling on the past, you don't have any better visions for things to come or any idea for future.
Your UNIX philosophy doesn't have ACL or system policies for fine-grained security control, or DRI to allow real gaming and accelerated video playback and capture, or the component-based design which all modern desktop systems base on, or even the capability to support PnP and USB devices and instant changing of multi-monitor setup in X.
Your UNIX philosophy sucks yet you cannot see it, because you still hide in the basement doing creepy network stuff in front of 3 CRTs with the original xterm.
Please go f*** yourself and die to save Linux.
I personally ran into tons of problems with SysV scripts. They are not theoretical. One of them forced me to go into our data center at night to power-cycle a machine: http://anonscm.debian.org/cgit... (can you find it?)
And yes, I really do hate the old "let's just hack a bash script approach" or "'sleep 10' solves this race" kinds of admins. And mostly because I have to make their shit run on large-scale clusters that experience all kinds of weird failure modes.
"Elegant"? I don't think this word means what you think it means. Look inside DHCP source - it's crap. And it's not like DHCP is some kind of an uber-complicated protocol, a simple implementation of it takes about a day to write.
The one I see is if you try to stop and start it simultaneously (or, "within a racy amount of time"), there could be a race with the PID file. Theoretically I guess you should have a consistent state if you start and stop the daemon simultaneously (either it should end up stopped or started), but it seems like it would be bad practice to attempt to do something like that. Slackware's rc.bind script has this comment, which is hilarious:
# Start BIND. As many times as you like. ;-)
# Seriously, don't run "rc.bind start" if BIND is already
# running or you'll get more than one copy running.
Sound logic. I learned not to blindly run "rc.whatever start" long ago.
You want people to test code on weird clusters that apparently are tightly integrated somehow and not using a standard batch submission mechanism. I used to want people to test code on Linux/SPARC. Neither of us is going to get what we want, because expecting other people to test such marginal use cases is expecting other people to do our work for us.
And why would you have to manually power cycle a machine because named didn't start? And why would you have to fix a failure on a single node of a huge cluster overnight? If that was the nameserver for all the machines, well, you should have had at least two nameservers. It's not like they take much CPU. Single points of failure are bad.
vi ~/.emacs # I'm probably going to Hell for this.
The one I see is if you try to stop and start it simultaneously (or, "within a racy amount of time"), there could be a race with the PID file.
There's an infinite loop near line 92 if for some reason BIND becomes unresponsive to signals. That actually happened to me, so that's why I can pinpoint it. And to add insult to injury, this loop happens during service shutdown and can leave the machine inaccessible remotely.
Now let's check the systemd's version of this file: http://pkgs.fedoraproject.org/... Please tell me which one is better.
You want people to test code on weird clusters
Not really. I simply want people to stop assuming that race conditions are rare and write reliable software.
Because they don't bother to shut down. They just power it off, or unplug it.
Well, the problem in your example wasn't a race condition. It's that they never did kill -9.
The comparison with the SystemD version of the file is invalid because the complexity has just been shifted elsewhere. In the init version, the complexity is in the script. In the SystemD version, it's in a monolithic binary running as PID 1. Which is better is not clear just from looking at the files.
However, and I've said this before -- even if Debian's init scripts suck, that just proves /Debian's/ init scripts suck. Slackware's init scripts are much, much cleaner than Debian's or Red Hat's.
You might want to look into some sort of "(sleep 600; reboot -f ) &" inside of your shutdown script if you're going to be working with machines you can't easily get to to power cycle. That would potentially solve all sorts of obscure corner cases in shutdown. You'd have to put that in after it did its final "I KILL YOU ALL MWA HA HA" signaling to shut down the user processes so the sleeping shell doesn't just die with the rest of userspace. Still, might want to look into it.
vi ~/.emacs # I'm probably going to Hell for this.
The answer backs my original point, while they may be a backport to Debian 7 it's not actually live in a production release of Debian. So tell me, do you also claim that Redhat has everything in the latest Fedora release? That is the equivalent, and it's extremely dishonest.
-The wise argue that there are few absolutes, the fool argues that there are no probabilities.
I thought ChromeOS used Upstart, not systemd. When did this change?
Never start vast projects with half-vast ideas.
The comparison with the SystemD version of the file is invalid because the complexity has just been shifted elsewhere. In the init version, the complexity is in the script. In the SystemD version, it's in a monolithic binary running as PID 1.
Yes, it's written ONCE, thoroughly audited and tested on variety of systems.
Which is better is not clear just from looking at the files.
Look at http://anonscm.debian.org/cgit... - can you spot a fatal flaw in this file?
I don't like the part that overwrites resolv.conf to use 127.0.0.1 as the nameserver if it thinks the network is down, but I'm not going to play shell script bug hunt with you. SystemD also has bugs. Almost all software has bugs. The software on Apollo 11 had bugs. And Debian's init scripts are, indeed, messy and imo overkill and inferior to the rc.d method used by Slackware and the BSDs.
I'll just leave you with this: https://plus.google.com/112984...
Yes, yes, "it's just an interface to journald!" So it's more like syslogd embedding a web server and QR encoder than init itself. Much better.
vi ~/.emacs # I'm probably going to Hell for this.
I don't like the part that overwrites resolv.conf to use 127.0.0.1 as the nameserver if it thinks the network is down
So turn it off. Duh.
Yes, yes, "it's just an interface to journald!" So it's more like syslogd embedding a web server and QR encoder than init itself. Much better.
Incorrect. That web server lives in a separate gateway daemon, that is started as a regular service (and it's totally optional). It has NOTHING to do with PID1.
Sorry still don't care. The argument against systemd is being perpetrated by a small number of folks who have an axe to grind. They operate anonymously to hide how few and irrelevant they are.
s/made up story/metaphor/g
We really bring it on ourselves by trying to be subtle online.
Unity? Screw that: XFCE. Slashdot Beta? Screw that: SoylentNews. Australis? Screw that: Pale Moon. UX developers DIAF
I thought ChromeOS used Upstart, not systemd. When did this change?/q
Never released; it turned out to be a bad idea.