Ask Slashdot: Feature Requests For Epoch Init System 1.3.0?

New submitter Ben Dibell writes: My name is Subsentient. I maintain the Epoch Init System, a single-threaded init system for Linux designed to be easy to configure and customize, as well as staying out of your way.
Epoch uses a numeric priority system to determine the boot order of objects, supports a wide range of customizability, and doesn't require much anything except libc and /bin/sh (though /bin/sh can be omitted, not recommended). Epoch also features advanced service status reporting features and has service supervision.

I'm just here to ask the Slashdot community what they'd like to see in the next release, 1.3.0 "Fluoxetine", before I wrap it up.

There are generally 2 things I can't consider:
* Parallel service startup, because that can be done manually, and implementing it would make Epoch too complex IMHO.
* Switching away from the numeric priority system to "true" dependencies. I implemented the priority system because I liked the freedom it gives the end user.

Despite these omissions, your feedback matters to me. I want to make something everyone will want to use.

-Subsentient

Comments

systemd compatibility

[Anonymous Coward]

You need to support the standard service file format to be relevant.

Re:systemd compatibility

[ZG-Rules]

I actually wish I had mod points right now...

Re:systemd compatibility

[Anonymous Coward]

And if you don't ignore nonzero exit statuses or stderr, then you will have a competitive advantage over systemd. Poettering just doesn't understand why those concepts are important to UNIX users. He's just a kid so he just doesn't get it.

Re: systemd compatibility

[buchanmilne]

Don't use Type=simple (the default) in a service unit if you don't want the 'simple process intended for use with inetd-style systems' behaviour. See the relevant man page (I think systemd.service) for other options that would be more appropriate for your use case (but I am not sure there is one for "anti-systemd FUD").

Re:systemd compatibility

[drolli]

No, i think it should have an interpreter translating the Systemd file formats to XML. The first thing started should be a Java web service which accepts these XML files, compiles them to JavaScript and send them to the build-in browser.....

Re:systemd compatibility

[davester666]

Maybe he could integrate the code into systemd? Then it would use the standard service file format.

Solaris

[ArchieBunker]

Sounds like the method Solaris used.

Re:Solaris

[Eunuchswear]

Solaris used sysvinit, then moved to SMF (in some sense one of the ancestors of systemd).

Re:Incorporate other stuff

[thinkingrodent]

I think I'll just add a web browser.

Parallel startup...

[andremerzky400]

... shouldn't be too difficult? Well, as long as you stay away from dependencies, and just limit concurrency to services with the same priority... What is it you worry about?

Re:Parallel startup...

[Anonymous Coward]

I second this. Two services with the same priority level could start in parallel. Services with no priority (ex. user installed software) could all start in parallel at the end.

The other thing, more a suggestion than a feature request, is why not try to integrate the good parts of this system into let's say some flavors of BSD and start forgetting about Linux. SystemD has basically been decided, probably for business reasons, and this project might never bring much or any value to the Linux community at this point.

Re:Parallel startup...

[Anonymous Coward]

As soon as you do this you *screw* dependencies. That's a hard-won lession from daemontools, SysV init, and systemd.

Re:Parallel startup...

[Eunuchswear]

Actually the lesson from systemd is that dependencies have been screwed since the beginning and only "work" by accident.

What systemd is doing is forcing people to deal with the whole "when is a service started" problem that everyone has been sweeping under the carpet. The same problem was also visible in parallel sysvinit (Debian) and Upstart, but to a lesser extent.

How fast or slow is it?

[Anonymous Coward]

It's always nice to have alternatives. How fast or slow is it for a typical desktop?

I did find an interesting write up of experimenting with epoch as an init/systemd replacement.

Re:How fast or slow is it?

[thinkingrodent]

For my own system, it boots in around 15 seconds to SliM login manager, which then takes me to XFCE 4.12.

Dependencies

[afgam28]

Why do you think a numeric priority system gives "freedom" to the end user? To me, having to manually mess around with numbers is an annoyance, and it means that the init system is getting in the way.

Having numbers means that some dependency info gets lost. If you have an S10 and S20 script, is there any dependency between them, or were they just arbitrarily numbered? It's impossible to tell unless you go and read through the script and figure out for yourself. This makes it hard to debug when things go wrong. You also just end up with a bunch of scripts that all start with S99 or K99.

The NetBSD init system (which was introduced way back in 2001, and I think ended up being adopted by the other BSDs) has a simple way of solving this. There's a tool called rcorder that parses REQUIRE and PROVIDE lines in each startup script (it's tsort, essentially) and determines the order to run each script. If you wanted to debug something, you could run this yourself and check the output. "Runlevels" were implemented with dummy scripts (i.e. scripts that just had dependency information in them, and didn't perform any actions).

Other than that, it's as simple as the traditional sysvinit, but without meaningless numbers everywhere. You can read more about it here: http://www.mewburn.net/luke/pa...

It's 2015, we should be naming things not numbering them.

Re:Dependencies

[thinkingrodent]

The number system allows for priorities to have the same number, so you can group things in this way. Also, the DefinePriority attribute allows you to name priorities.

Re:Dependencies

[Anonymous Coward]

I would vote this up if I had the gumption to sign up for an account.

rcorder was adopted by FreeBSD, and it's a beautiful thing. A few lines at the top of your script and you know that the dependencies will be managed correctly.

Re:Dependencies

[nuckfuts]

If I was writing a script that depended on some service being started or some other condition before it could start, I would check for that condition within my script. I would not expect some external framework to figure out what my script requires and to coordinate its startup.

Re:Dependencies

[Anonymous Coward]

If you have a text file list of the daemons, each with REQUIRE and PROVIDE, I could write a program that would convert that to startup numbering. Try Epoch. The numeric ordering turns out to be refreshingly simple, and Epoch's daemon specifications are between 1 and 2 orders of magnitude simpler than sysvinit init scripts. If I had ten minutes to put a new init system on a computer, I'd choose Epoch.

Steve Litt

Re:Dependencies

[Anonymous Coward]

Why use a computer at all then if you don't use it to automate tasks?

Re:Dependencies

[belthize]

Thank you. It amazes me that after reams of random posts about all things init-ish here and in other discussions very few people point this out when discussing dependencies.

A proper dependency check for service A within service B's start up can can also be shoe horned straight into something like Nagios for handling A if it goes sideways.

Re:Dependencies

[squiggleslash]

So your service will randomly fail to start, depending upon whether the local system's "init" just happened to start the services yours depends upon before your's?

That... doesn't seem like a good idea to me. While I'd certainly ensure my scripts handle the non-startup of dependencies gracefully, I'd definitely want a sane init system to actually know what to start up, and in what order.

Re:Dependencies

[Anonymous Coward]

Seriously. DRY. Its 2015, every daemon shouldn't have to handle its own dependency management. Do it right once and factor it it out. This is how we end up with mounds of boilerplate copy-pasted around.

Re:Dependencies

[Garridan]

Sounds like you don't know what a topological sort is. Look it up. True, it's designed for a single processor, but the parallel approach is essentially the same: if you have a thread free, take the first thing in the list whose deps are all satisfied. It'll finish faster than a priority system, it's more robust, and much easier to configure.

Re:Dependencies

[fisted]

The NetBSD init system (which was introduced way back in 2001, and I think ended up being adopted by the other BSDs) has a simple way of solving this. There's a tool called rcorder that parses REQUIRE and PROVIDE lines in each startup script (it's tsort, essentially) and determines the order to run each script. If you wanted to debug something, you could run this yourself and check the output.

Came here to say this.

Re:Dependencies

[GigaplexNZ]

So your service will randomly fail to start, depending upon whether the local system's "init" just happened to start the services yours depends upon before your's?

That... doesn't seem like a good idea to me. While I'd certainly ensure my scripts handle the non-startup of dependencies gracefully, I'd definitely want a sane init system to actually know what to start up, and in what order.

Uh, no, the whole point is that the service checks for the dependency, and if it's met, then all good, and if it's not met, it requests the dependency to be started.

Re:Dependencies

[Art3x]

The NetBSD init system (which was introduced way back in 2001, and I think ended up being adopted by the other BSDs) has a simple way of solving this. There's a tool called rcorder that parses REQUIRE and PROVIDE lines in each startup script (it's tsort, essentially) and determines the order to run each script. If you wanted to debug something, you could run this yourself and check the output.

Came here to say this.

Ditto.

SysVInit's numbering always struck me as a little hacky. But it's so simple it works. Plus everybody's used to it. When systemd appeared, I looked into FreeBSD and read about its init system. It's a total face-palm that so many years have gone by without Linux adopting something like BSD's way --- or just taking it. It's an even bigger face-palm that instead Linux adopted systemd.

Re: Dependencies

[buchanmilne]

Some init systems used on linux supported the LSB init script headers which do a similar thing. Some of them also supported parallel start-up (start all services whose dependencies are satisfied).

For example, Mandrake/Mandriva/Mageia used prcsys from around 2004 to 2013 (when Mageia switched to systemd).

But, there are a lot of advantages to systemd and most complaints about it are FUD that have been debunked.

Re:Dependencies

[0100010001010011]

> To me, having to manually mess around with numbers is an annoyance, and it means that the init system is getting in the way.

Just build a script to optimize the boot sequence. I'll leave my laptop or PC to reboot over the weekend as it sorts out dependencies and boot time.

Boot everything sequentially. Measure exactly how much memory/CPU/time each app takes.

Testing that is something computers are good at. Boring and repetitive.

Give it a 'quit' criteria of 'any optimizations less than .5s, you can stop'.

Set up a website to submit results to and you can download the 'boot profile' closest to your use and

Hell let the cloud and VMs autotune it. You could have an EC2 appliance rebooting 24/7 optimizing the boot sequence. [It'd be NP-hard but](https://en.wikipedia.org/wiki/Travelling_salesman_problem) to test to completion but you should be able to get a pretty decent ball park.

Re:Dependencies

[Eunuchswear]

Uh, no, the whole point is that the service checks for the dependency, and if it's met, then all good, and if it's not met, it requests the dependency to be started.

That's insane. Possibly the worst possible way to do an init system I've ever heard of.

Re:Dependencies

[thogard]

The real tick is to manage things in a sane way when the system isn't working properly.

Take the case of a system living in a rack far away. When it boots it needs to 1) bring up part of the network, 2) bring up sshd as soon as possible and 3) bring up user/vm/container disks. Once the disks are verified to be sane enough to continue, it might want to bring up the rest of the networking and it might want to bring up an sshd with a different config. Of course if the disks are screwed up, the best thing might be to bring up part of the system or leave parts of it shutdown even if their normal dependancies are all met. Too bad most systems sit at a console prompt waiting for a human to tell them what to do with the broken disk.

Re:Dependencies

[tlhIngan]

Uh, no, the whole point is that the service checks for the dependency, and if it's met, then all good, and if it's not met, it requests the dependency to be started.

And let's say something horrendous happened that the service fails to start, but takes absolutely forever to do so.

SysVInit, this init, are single thread init systems. They can't block because they'd block the startup. Your dependent service starting the service continues to block startup. And let's say it only takes a second when it succeeds, but 10 minutes when it fails. If it happens before a chance to get to a prompt (e.g., before networking), it could easily take hours for the system to get to a usable state.

A multithreaded startup would let your script attempt to start up (in fact, your script would point out the dependency, while the init system would handle satisfying them), and block on the failing service, while starting up other services so you have an attempt at fixing the problem.

Re: Dependencies

[Anonymous Coward]

Who says networking is a requirement to get to the prompt? (Granted, some configurations will require it). In a simple numeric priority system, your hypothetical hanging failure service will already block getting to a prompt anyway.

Re: Dependencies

[Antique Geekmeister]

Except for the many, many complaints about systemd that are not FUD, such as the overwhelming need by systemd developers to integrate non-init fucntions into the systemd suite such as logging, DHCP, and mounting attached media, the casual reworking of the file-system-hierarchy by ignoring all standards for "/run" and "/media", and insane inconsistencies of "using a symlink for /etc/resolv.conf into the DHCP substructure, except not resetting the symlink if the user puts a flat text file in /etc/resolv.conf and never updating it again"

One of the announced goals of systemd is to "create a stateless Linux", to essentially clear away or prevent any modifications to "/etc" and "/var" and set all local system configuration withing systemd itself. This _breaks_ decades of system configuration work, including every Linux compatible system management tool such as puppit, CFengine, chef, BladeManager, and even installation systems such as Debian'a .dev system, RPM's packaging, and commercial software installation tools. /etc/resolv.conf is merely an example of breaking such tools, but it's a fundamental example of the disdain for non-systemd based system components. It's an example of the chaos being engendered is from such broad goals that have_nothing to do_ with an init system, and that erratically and unpredictably break decades of well-written software that followed the published file system hierarchy standards in favor of underdocumented, non-portable, rapidly evolving and functionally unnecessary switches to a new layout.

Those are only a few of the well documented issues: so overall, there's a lot to like about systemd. But the tendency of its proponents to characterize concerns about it as "FUD" is disingenuous.

Re:Dependencies

[olterman]

Topological sort is one way to do it. Another way is to use out-of-place ordering by starting from the outmost nodes and continue to the roots. Topological sort gives the same end result but worse parallelism.

Re:Dependencies

[jedidiah]

In other words, the absolute worst case of the priority system is the base case of the "more sophisticated" alternatives.

Re:Dependencies

[jedidiah]

This right here would be my big complaint about the "better alternatives" to init. For anything but the most trivial desktop use case, they fuck up the boot sequence. Sometimes it's just glitchy behavior where things get started up out of order but they do start. Other times the box will just get stuck during startup because of some bogus error.

Manual tinkering is far more risky. The better-than-init options make it far to easy to render your system completely unbootable.

Re:Dependencies

[fisted]

So what is a sane init system to do in case of a broken disk? Pretend everything's good and mount its filesystems r/w so that we might get away with starting sshd anyway?
A broken disk is a broken disk. Dropping into a single-user console makes sense because "broken disk" comes in too many machine-indistinguishable flavours for a program to meaningfully take care of and the consequences of "just trying something" could be severe.

If you need this kind of robustness, use a RAID.

Re:Dependencies

[fisted]

You should try and read the link in the comment you replied to

Re: Dependencies

[Anonymous Coward]

Yeap, all the stuff you list us what makes systemd interesting. Without that it would be just another in it system like all the others out there.

Finally somebody comes up with neat new features and with enough momentum to break through the accumulated cruft that clogs up the became enshrined as doctrine.

Re: Dependencies

[Anonymous Coward]

RAID only prevents physical loss of a disk. It doesn't do anything for file system corruption, which is what causes single user fsck requirement.

What might be better is setting things up so you mount you mount your main root disk read only all the time and write to other partitions.

Re: Dependencies

[Anonymous Coward]

Actually it is systemds goal to *enable* stateless systems. You are free to run stateful systems and those are actually expected to be the default configuration for most users.

But there are systems that do profit from being stateless. These include things like medical devices, kiosk PCs, computer poo!s at universities, mobile phones to list just a few use-cases. Enabling those without harming existing use-cases is a pretty good engineering IMHO.

Re: Dependencies

[Bengie]

which is what causes single user fsck requirement.

An FS that needs fsck is broken by design. Use a modern FS. If you need a reliable boot volume, just use ZFS and do a 4 way mirror or something outrageous, two disks on one controller and 2 on another. If that gets corrupted, there is no hope, like a damaged CPU or bad motherboard.

Re:Dependencies

[Garridan]

Sure, better technology exists than topological sort ! Thanks for pointing out a better approach. OP's point, and mine, is that a few minutes of thought can be used to replace a horrible, unmaintainable cludge a graceful, robust approach. In fine Unix tradition, epoch wants to keep ritual animal sacrifice as a neccessary part of system administration. Good for the goat industry, bad for your coldroom floor.

Re:Dependencies

[lars_stefan_axelsson]

There's a tool called rcorder that parses REQUIRE and PROVIDE lines in each startup script

Problem is that UNIX services doesn't actually tell you when they're ready to "provide", the init system is based on the notion of having told something to start, not actually having it available.

So, until you address that any prioritization is going to be a kludge at best. It's no use telling a system that something requires something else, until you can actually guarantee that that something else is actually available.

Fun fact, systemd doesn't address this either. Well, there are some kluges in the form of initd like behaviour, but by and large its still the old "spawn off a process and cross your fingers"-approach to service provisioning and dependency resolution. Only a lot more complicated for not much improvement. "Lots of screaming for little wool, said the woman that sheered the pig..." as the Swedish saying would have it.

P.S. Of course, whether you number or name these things doesn't make one bit of difference. But with numbering at least, you're not fooling yourself into thinking that you're getting something you're not.

Re:Dependencies

[Eunuchswear]

Problem is that UNIX services doesn't actually tell you when they're ready to "provide", the init system is based on the notion of having told something to start, not actually having it available.

[...]

Fun fact, systemd doesn't address this either. Well, there are some kluges in the form of initd like behaviour, but by and large its still the old "spawn off a process and cross your fingers"-approach to service provisioning and dependency resolution. Only a lot more complicated for not much improvement.

sd_notify.

At least the systemd people know there is a problem, sysvinit has been burying their heads in the sand for how many years about this?

(The discussion about this on the Devuan mailing list was funny -- people desperately trying to find some way of avoiding saying good things about systemd).

Re:Dependencies

[lars_stefan_axelsson]

sd_notify.

No, that doesn't really count, as it's outside the scope of the current start-up management. It's not something that could be done with start-up management alone today.

Now of course, if we're allowed to fix the infrastructure, with hindsight there's a lot of things we could/should/would have done differently. But the world being what it is, that's unfortunately often not an option. I mean, Unix isn't that great, we could do a lot better today if we were allowed to start over. But again unfortunately we're not. So sd_notify while being "obvious" also falls far short.

Not that I'm married to SysV startup, it's a bit of a kludge. Likewise I'm not impressed with systemd either, it's arguably worse than the problem it's trying to solve. But again, that's not saying that SysV starup wasn't due for replacement.

Re:Dependencies

[Eunuchswear]

sd_notify.

No, that doesn't really count, as it's outside the scope of the current start-up management. It's not something that could be done with start-up management alone today.

Now of course, if we're allowed to fix the infrastructure, with hindsight there's a lot of things we could/should/would have done differently.

But that's what systemd is about. You can criticise the way they do it, but they are at least trying to fix these problems, rather than denying they exist or throwing up their hands and saying "you can't get there from here".

(By the way, in what way is sd_notify "outside the scope of current start-up management"? systemd is "current start-up management" for lots of us).

Re:Dependencies

[lars_stefan_axelsson]

With current start-up management I meant "as it's defined by history and hence the system we've got to work with". Systemd is, as you say, trying to change that, and hence, have to change everything around it to suit. (And that's not popular, to put it mildly. :-) ) So they're going outside the current scope as what they're trying to achieve can't effectively be addressed within it. If it could be, and they hadn't try to expand the scope, there wouldn't be nearly as much wailing and gnashing of teeth, don't you agree?

Re:Dependencies

[Eunuchswear]

With current start-up management I meant "as it's defined by history and hence the system we've got to work with".

Ah, by "current" you mean "historical". :-)

Luckily for us software isn't carved in stone.

Re:Dependencies

[lars_stefan_axelsson]

Ah, by "current" you mean "historical". :-)

Yes, if you will. History is after all that which happened just before "now"... :-)

Portability with non-commercialised *nixes

[Anonymous Coward]

Make it compatible and portable to Devuan, Slackware, BSD and other non-commercialised *nixes.

Re:Portability with non-commercialised *nixes

[thinkingrodent]

It'll already run on anything with a Linux kernel.

Re:Portability with non-commercialised *nixes

[dweezil-n0xad]

posting to undo a moderation misclick on the above post, sorry

Re:Incorporate other stuff

[JWSmythe]

Make sure it's it's not compatible with any current technology or formats.
Maybe you can write it all in Java. We all love Java running on our servers. Maybe with a non-intuitive touch screen console with no real functionality. You'll make a fortune. :)

Re:Incorporate other stuff

[PPH]

Don't forget an email client

What problem is this solving?

[diamondmagic]

I'm perfectly happy with OpenRC over here (I'm a Gentoo user, mostly). It has parallel startup, a fairly straightforward configuration, it's possible to run multiple instances of a daemon, and it works with Linux and BSD systems.

And most importantly, I can still run my own cron, syslog, and date systems.

How is Epoch different?

What problem is this solving, and how is Epoch uniquely solving those problems?

Re:What problem is this solving?

[thinkingrodent]

Epoch for one, doesn't require another init system like sysv to run on top of. It's also got fantastic service supervision, which OpenRC does not have. And it's easy to set up too.

Re:What problem is this solving?

[Anonymous Coward]

> How is Epoch different?

If it doesn't swallow higher priority syslog messages, stderr, and give a zero (not an error) exit statuses for services that fail to start, then it is simply better than systemd. Correctly doing those things would give it an advantage over systemd. systemd has some very nice features, but hiding syslog messages and stderr makes it very hard, or nearly impossible, to troubleshoot startup problems. Doing those things right would give it a competitive advantage.

Re:What problem is this solving?

[Anonymous Coward]

swallow...stderr

In my opinion, that part of systemd is what proves most that the angry children that make systemd, and ignore bug reports, is the best proof that Poettering just doesn't get it. He does not understand UNIX. stderr output should never be ignored, much less deleted. I'm the author of an analytics daemon that monitors connections to Elasticsearch. I lost a lot of customers, because while my init script outputs clear error messages to stderr, they couldn't tell why my daemon failed to start since systemd doesn't log stderr to the journal. Their journal is great in many ways, and I really like it in general, but it fails because of their policy to not log higher priority syslog messages or stderr. That makes it nearly impossible for my customers to troubleshoot start-up problems. I lost many customers because of systemd.

Re:What problem is this solving?

[geoskd]

He does not understand UNIX. stderr output should never be ignored, much less deleted

Here is a link to a bug report dealing with the stdout / stderr problem. If you read through it, you will find that the systemd folks are very responsive, and fully agree that the bug existed and quickly had a fix.

I'm sorry that you lost customers relating to systemd, but if they switched to systemd, and the only failures they had were your code, then I have to ask why that is. If they had other failures in the conversion, and still insisted that you were the problem (enough to drop you as a service provider), then I would worry that there was some other agenda going on.

If, on the other hand, you were the one who switched to systemd, and managed to have unstable code make it to a client... Thats a whole other ball game.

Re:What problem is this solving?

[Anonymous Coward]

Interesting to see the systemd fanbois mark this as a troll rather than addressing the problems. As Linus correctly pointed out, they ignore bug reports. systemd is a disaster and is hurting Linux. Throwing away stderr, certainly syslog messages, and the exit status are all serious problem. This is just further proof that they are burying their heads in the sand rather than addressing the many issues they have.

Re:What problem is this solving?

[Eunuchswear]

He does not understand UNIX. stderr output should never be ignored, much less deleted

Here is a link to a bug report dealing with the stdout / stderr problem. If you read through it, you will find that the systemd folks are very responsive, and fully agree that the bug existed and quickly had a fix.

Amazing, a bug report that almost matches their paranoid fantasies.

High points:

1. stderr was lost because it was written to the terminal, just like it would have been with sysvinit -- someone had overriden the systemd default of logging to syslog.

2. someone else found another case where errors were being lost due to a misconfiguration of selinux, an all-pervasive system written by the NSA, something the paranoid anti-systemd trolls never seem to worry about, even when they try to claim systemd is a NSA plot.

I'm sorry that you lost customers relating to systemd, but if they switched to systemd, and the only failures they had were your code, then I have to ask why that is. If they had other failures in the conversion, and still insisted that you were the problem (enough to drop you as a service provider), then I would worry that there was some other agenda going on.

If, on the other hand, you were the one who switched to systemd, and managed to have unstable code make it to a client... Thats a whole other ball game.

I very much doubt he has any customers.

Ask elsewhere as well.

[hendrikboom]

I suggest you ask again on soylent news; there's quite an active technical community thers.

Also on the devuan mailing list. They might end up being your users.

-- hendrik

Re:Ask elsewhere as well.

[Anonymous Coward]

I would hardly call Devuan a "failure". They're currently in Alpha, and I'm running it on a system now.

They have an IRC channel where developers are chatting about what needs to be fixed AND THEY'RE DOING IT.

Yeah, it's not moving forward at light speed, but there's a lot of stuff that has to be worked out because systemd has its slimy tendrils in far more than it really should.

Before you write off something like Devuan, you might like to, oh I dunno, do some HOMEWORK first. Check up on the current state of it instead of going on information that is a couple months old.

Re:Ask elsewhere as well.

[Eunuchswear]

I would hardly call Devuan a "failure". They're currently in Alpha, and I'm running it on a system now.

I still don't know what devuan are trying to do. Make a version of Debian Jessie that doesn't use systemd? But Jessie can already be run without systemd. Make a system without libsystemd0? Why?

Re: Ask elsewhere as well.

[Anonymous Coward]

They have a couple of really capable admins over at devuan. I really hope Debian will take a look and pick upnsomentricks from the build sytem the devuan guys (I am not aware of any women being involved, so don't gwt on about gender use:-) have set up.

The development efforts going on there are mostly misguided though. Most of the time they end up trying to reimplement some part of systemd (logind, udev) without bothering to understand what it does or even what the requirements are for that part.

The packaging going on there is actually dangerous. They are blindly removing anything that has "systemd" in its name -- or that somebody decides to be too closely associated with systemd. That haopens with the same deep insights that drive the development effort. In essence they are undoing security relevant code in many places without bothering or even understanding the issues they create by doing that. In many places they did not even bother to reinsert the code that was there before systemd and that limited the scope of the attacks. So they do not only undo the progress made with systemd, they often fall back behind the standards we had before systemd:-(

Re: Ask elsewhere as well.

[Anonymous Coward]

I really hope Debian will take a look and pick upnsomentricks from the build sytem the devuan guys

Like what? I know they do the following:

• Triggering builds from the bug tracker: that's wrong (IMO); builds should be triggered by source uploads arriving in the archive or manually (such as binary-only-rebuilds for library transitions). Anything else makes signing the source package by the uploader impossible. If I already upload something, I don't want to have to do further steps.
• Requiring Git for source packages: I'm all for using Git, but Debian cannot force all developers to use a single VCS, just a Debian doesn't force all people to use the same init system ;)
• Using Jenkins: I know of one derivate distribution that tried that (it's nothing new from Devuan), but AFAIK it didn't scale when trying to build all 20k+ packages; and that was on only two(?) architectures, not Debian's 10+. Also I'm not sure if they check that build-deps are fulfilled before scheduling builds?

Re:Incorporate other stuff

[LesFerg]

And how about a bluetooth interface to a watch app, so I can monitor the services on my wrist... all the trendy gadgets are getting that nowdays

Well...

[Kormoran]

1) Cgroups-based daemon handling. 2) No XML config files, for god's sake! 3) No nested dirs/subdirs in /etc, please... keep config in one single file

Does it ignore nonzero exit statuses, syslog...

[Anonymous Coward]

message, and stderr like systemd? If it doesn't, then it is superior. The systemd guys just don't understand why those things are important.

Re:Does it ignore nonzero exit statuses, syslog...

[Anonymous Coward]

Good point. The systemd guys just don't grok exit statuses or stderr. I've wasted many hours because systemd returns a zero exit status on a failed service start and even more because it swallows stderr. It doesn't save stderr messages to the journal. The journal, while a great idea, is useless because it doesn't log higher priority syslog messages or stderr. I've had several problems, that should have taken just a few minutes to solve, take most of a day because of systemd. For example, with the MongoDB package for Red Hat 7, if it doesn't shutdown gracefully, it leaves behind a /var/lib/mongo/mongod.lock file that keeps MongoDB from restarting. If you attempt to start MongoDB from the command line then you get an obvious error message about the lock file. It takes only a matter of seconds to determine the problem and to fix it. With systemd's policy to ignore exit statuses and stderr, you could be guessing for hours or even days what the problem is. systemd is a disaster made by kids that aren't experienced enough to grok UNIX.

Re:Does it ignore nonzero exit statuses, syslog...

[thinkingrodent]

No it doesn't. If it returns nonzero, that's pretty much going to show as a failure and will be logged as such.

Re:Does it ignore nonzero exit statuses, syslog...

[Anonymous Coward]

systemd guys just don't understand

And, that is the problem. They're too young to have worked on managing a large number of systems, so they just don't get it. stderr should never just be sent to /dev/null like they're doing.

Re:Does it ignore nonzero exit statuses, syslog...

[geoskd]

It doesn't save stderr messages to the journal.

It most certainly does.

There have been several bugs that have cropped up from time to time relating to logging, but they get fixed as soon as they are found. The far more common problem is that by default the logging now goes through journald, and rather than rtfm, people often seem inclined to claim its broken rather than seek out the answers. You can find a good description for how to find the logs here

Re:Does it ignore nonzero exit statuses, syslog...

[Anonymous Coward]

So rather than fix the problems, you attack the reporter? That is the central problem with systemd. stderr is not logged to the journal. I manage several thousand servers, of which about half have been CentOS 7 since last September. I have never personally seen stderr logged to the journal. Every single time I have to troubleshoot a service start-up problem, I have to resort to starting it manually. systemd has some serious design flaws, and the decision to throw away stderr is, in my opinion, the worst one.

Re:Does it ignore nonzero exit statuses, syslog...

[thinkingrodent]

I meant the Epoch Init System. It handles exit codes properly. I am the guy who wrote it.

Re:Does it ignore nonzero exit statuses, syslog...

[geoskd]

Systemd doesn’t throw away stdout or stderr. If you have a case where you believe there is a bug, and those streams are being lost, submit the bug report. You might have found a legitimate bug. You might not. A lot of logging changed with Systemd, and some things are less than obvious. This is nothing intrinsic to Systemd, its just different from what you're used to. Drop any newbie into CentOS, and they would have just as much trouble finding the logs...

*BSD

[tepples]

What holds up a port to the kernel of FreeBSD?

Re:*BSD

[thinkingrodent]

/proc mostly. That's how Epoch does process supervision.

Re:*BSD

[fisted]

It might be the fact that the BSDs already have a mature and sound dependency-based init system.

What does it do with stderr?

[Anonymous Coward]

I manage about two dozen sysadmins with around 80k virtual machines, and swallowing stderr is the biggest problem we now face. systemd doesn't log it or show it on the console. Most daemons give pretty good error messages, but systemd hides that from them. That means rather than taking a few minutes to troubleshoot a problem, they now waste hours because the systemd guys just don't understand stderr. If this init system doesn't hide stderr, then I'm very interested in it.

Re:What does it do with stderr?

[Anonymous Coward]

What distro are you using? 'stderr' for a service by default should go to the same place that 'stdout' goes to. http://www.freedesktop.org/sof...

Re:What does it do with stderr?

[thinkingrodent]

Epoch doesn't touch your stderr. Your apps are free to print to the console. A log of overall service start/failures is in /var/log/system.log

Re:What does it do with stderr?

[Anonymous Coward]

I'm using Red Hat 7, and stderr certainly doesn't end-up in the journal. That makes it very hard to troubleshoot daemon start-up problems. I don't think the systemd guys get how important stderr is. Otherwise, they wouldn't throw it away.

Re:What does it do with stderr?

[Anonymous Coward]

with around 80k virtual machines

And, you're trying to use systemd? You have my sympathy. I'm sure the problems it has with stderr and with exit statuses make your life a living hell. I know it does mine. The three biggest problems we have are with the MongoDB package from 10gen, Tomcat from Red Hat, and ActiveMQ from Puppet Labs. All three of them always exit with a status of 0 (success) even when they fail. Also, they do *not* log the error messages to the systemd journal. "journalctl -u unit_name" doesn't return any clue of why they fail. We have to resort to running them by hand to see the stderr output. It sucks that the systemd guys are so against standard UNIX practices.

Re:What does it do with stderr?

[Anonymous Coward]

by default should go to the same place that 'stdout' goes to

And, that's the bug. We run Fedora, and IIRC we've been using systemd for four years. stderr is most certainly dropped by systemd. It is not saved in the journal. I have been fighting our developers for years over this issue. They output to stderr and refuse to change. My ops guys can't tell why services fail to start since stderr isn't logged in the journal. I know it isn't since "journalctl -r" doesn't show the error output from our services. If stdout is logged, then systemd should also log, rather than ignore, stderr. It isn't output to the console or to the log. As the chief architect, I am constantly put between my developers and my ops guys that argue about this. It has made my life miserable.

Re:What does it do with stderr?

[Eunuchswear]

You are responding to an insane troll. The incredibly tiny seed for their trollish lunacy is that, when configured incorrectly, services started by systemd can write error messages to the kernel instead of the systemd journal.

Re:What does it do with stderr?

[Eunuchswear]

So fix the init script already you twit. Just remove the "2>/dev/null".

What a maroon.

Re:What does it do with stderr?

[Eunuchswear]

Duh, typo, terminal, not kernel.

Re:What does it do with stderr?

[Anonymous Coward]

Have you tried making use of the 'StandardError' directive in affected unit files? By default it should 'inherit' from stdout the distro could have changed it, try setting it explicitly. You may even be able to set it globally, but I've not had this problem in Arch Linux so it must be a RHEL thing.

Re:What does it do with stderr?

[Anonymous Coward]

Wow, you systemd fanbois are all so rude. Why can't you children answer questions without resorting to insults like "twit?" If you spent as much time fixing bugs as you did ranting, you could probably fix all of the problems with systemd.

Re:What does it do with stderr?

[Eunuchswear]

Wow, you systemd fanbois are all so rude.

Aw, diddums.

Various(*) anonymous trolls repeatedly lying is not rude?

(* Actually I suspect there is only one troll, he's getting boringly repetitive).

Suggested improvements

[Anonymous Coward]

1. Increment your version.h
2. Ship it. It's excellent. It's minimal. I love it.

*Hugs*

Re:Suggested improvements

[Anonymous Coward]

hey ben, if you're really autistic enough to post that to yourself, do it when you're blackout drunk so you can think it's from someone else

Moderators on drugs?

[Anonymous Coward]

Why was this marked a troll? These are very serious design flaws with systemd. Of course rather than fixing the problems, Poettering instead has his minions make personal attacks. I think it would take less effort to just fix the problems rather than constantly attacking those that point them out.

Re:Moderators on drugs?

[geoskd]

Poettering instead has his minions make personal attacks

Here is a sample bug report relating to the stderr/stdout problem I see nothing by the way of personal attacks. In fact all I see are genuine interest in a bug, and a quick bug fix being pushed upstream. In fact, the only personal attacks I have seen on anyones part have come from anti-sysetmd people who are clearly not involved in any way in the decision making process, nor the systemd code maintenance process.

Fast graphical startup

[Anonymous Coward]

Fast, graphical startup that give the user all choices and full compatibility with existing software (except for systemd, you can drop that POS like a hot potato and no one will care-- in fact people will thank you and send you beer). And that's it.

Fuck the moderators

[Anonymous Coward]

Rather than addressing the serious issues with systemd, they simply just bury this as a troll. systemd most certainly has trouble with returning a correct exit status. I use Jenkins for continuous deployment, and it uses, like all good UNIX programs should, the exit status. systemd returns zero even when starting a daemon fails. That is a serious bug.

Also, systemd swallows stderr. Most of the start-up problems I deal with run start-up scripts that have useful output to stderr. systemd's policy of not logging that to the console or the journal makes my life much more difficult. For example, if MongoDB doesn't shutdown gracefully, it leaves a file named /var/lib/'mongodb/mongod.lock. MongoDB outputs a clear and unambiguous error message to stderr. systemd hides that message. systemd makes it very hard to determine that is the problem.

Re:Fuck the moderators

[Eunuchswear]

Could you trolls come up with another lie please, this one is boring.

Looks like a systemd fanboi has mod points

[Anonymous Coward]

Why was someone that points out a bug in systemd attacked this way. It's sad to see, as Linus pointed out, people that point out bugs in systemd are attacked. Wouldn't it just take less effort to fix the bugs? I know systemd has made my life a living hell trying to manage a few hundred Red Hat systems.

Coreboot. Get to init ASAP.

[0100010001010011]

Coreboot "is an extended firmware platform that delivers a lightning fast and secure boot experience on modern computers and embedded systems.</marketing>

coreboot (formerly known as LinuxBIOS) is a free software project, aimed at replacing the proprietary BIOS firmware found in most computers with a lightweight system designed to perform only the minimum number of tasks necessary to load and run a modern 32-bit or 64-bit operating system. - https://en.wikipedia.org/wiki/Coreboot

Re:Coreboot. Get to init ASAP.

[evilrip]

That's the first sane post this entire thread ;)

Re:Incorporate other stuff

[Eunuchswear]

Well, you'll be one up on systemd then, it only has a web server.

Re:Dependencies :)

[Anonymous Coward]

That is what systemd does...

it's not portable

[Anonymous Coward]

"The Epoch Init System is a small but powerful init system for Linux 2.6+."

debian will not use it as default.

Multithread/multiprocessor support

[olterman]

Adding this support should be quite easy. Just use similar approach as Puppet or those package dependency systems. Use a DAG (directed acyclic graph). There are ready solutions for manipulating a DAG, including NetworkX. And the DAG specific solution should be quite simple, around 15-20 lines of code (been there, done that). With a DAG you can utilize full CPU potential while still being maintain the correct execution order.

Re:Dependencies :)

[Eunuchswear]

No it is not. It's not the service itself that starts required services, it is systemd that does it.

  GigaplexNZ was suggesting that every service start out by starting all the dependencies it requires.

Re: Incorporate other stuff

[Anonymous Coward]

And a webserver. What good will a web browser be without a webserver. You might have to wait seconds before the network is up.

Re:Incorporate other stuff

[Anonymous Coward]

So you are assimilating lynx then?

Precalculate your dependencies and parallelism.

[shess]

Init systems seem to model themselves on Makefiles, reading everything at startup and detecting dependencies on the fly then deriving ordering and parallelism. This should all be invariant stuff, instead model things on ninja, where you calculate a giant wad of info and mechanically grind through it at startup.

https://martine.github.io/ninj...

no crazy file locations

[Anonymous Coward]

/etc only for the win

dependency injection

[PricekhanLinuxbean]

The real tick is to manage things in a sane way when the system isn't working properly. Take the case of a system living in a rack far away. When it boots it needs to 1) bring up part of the network, 2) bring up sshd as soon as possible and 3) bring up user/vm/container disks. Once the disks are verified to be sane enough to continue, it might want to bring up the rest of the networking and it might want to bring up an sshd with a different config. Of course if the disks are screwed up, the best thing might be to bring up part of the system or leave parts of it shutdown even if their normal dependancies are all met. Too bad most systems sit at a console prompt waiting for a human to tell them what to do with the broken disk. Compare price here is the best websitewww.pricekhan.com