Ask Slashdot: Feature Requests For Epoch Init System 1.3.0? 119
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
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
systemd compatibility (Score:5, Funny)
Re: (Score:1)
Re: systemd compatibility (Score:2)
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: (Score:2)
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: (Score:1)
Maybe he could integrate the code into systemd? Then it would use the standard service file format.
Solaris (Score:2)
Sounds like the method Solaris used.
Re: (Score:1)
Solaris used sysvinit, then moved to SMF (in some sense one of the ancestors of systemd).
Parallel startup... (Score:1)
Re: (Score:2)
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.
Re: (Score:2)
Dependencies (Score:5, Insightful)
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... [mewburn.net]
It's 2015, we should be naming things not numbering them.
Re: (Score:2)
Re: (Score:1)
Re: (Score:3)
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 mig
Re: (Score:3)
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: (Score:2)
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: (Score:2)
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: (Score:1)
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: (Score:1)
Re: (Score:2)
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: (Score:2)
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: (Score:2)
Re: (Score:2)
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: (Score:1)
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: (Score:1)
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: (Score:3)
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, b
Re: (Score:2)
You should try and read the link in the comment you replied to
Re: (Score:2)
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: (Score:2)
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 [freebsd.org]. 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 (Score:3)
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: (Score:3)
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
Re: (Score:2)
> 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'.
S
Re: (Score:2)
In other words, the absolute worst case of the priority system is the base case of the "more sophisticated" alternatives.
Re: (Score:2)
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 o
Re: (Score:1)
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: (Score:2)
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 n
Re: (Score:1)
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: (Score:2)
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
Re: (Score:1)
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: (Score:2)
Ah, by "current" you mean "historical". :-)
Yes, if you will. History is after all that which happened just before "now"... :-)
Re: (Score:2, Informative)
*BSD (Score:2)
What holds up a port to the kernel of FreeBSD?
Re: (Score:1)
Re: (Score:2)
It might be the fact that the BSDs already have a mature and sound dependency-based init system.
Re: (Score:2)
What problem is this solving? (Score:1)
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: (Score:2)
Re: (Score:1, Informative)
> 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: (Score:1)
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 do
Comment removed (Score:4, Interesting)
Re: (Score:2, Insightful)
He does not understand UNIX. stderr output should never be ignored, much less deleted
Here [redhat.com] 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
Moderators on drugs? (Score:1)
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: (Score:3)
Re: (Score:1)
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.
Looks like a systemd fanboi has mod points (Score:1)
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.
Ask elsewhere as well. (Score:3)
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: (Score:1)
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?
Well... (Score:1)
Does it ignore nonzero exit statuses, syslog... (Score:3, Interesting)
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: (Score:1)
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 Mong
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:1)
What does it do with stderr? (Score:2, Interesting)
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: (Score:1)
Re: (Score:2, Interesting)
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
Re: (Score:1)
Re: (Score:1, Interesting)
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: (Score:1)
Duh, typo, terminal, not kernel.
Re: (Score:1)
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 (Score:1)
1. Increment your version.h
2. Ship it. It's excellent. It's minimal. I love it.
*Hugs*
Coreboot. Get to init ASAP. (Score:2)
Coreboot [coreboot.org] "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 [wikipedia.org]
Re: (Score:1)
Multithread/multiprocessor support (Score:1)
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.
Precalculate your dependencies and parallelism. (Score:2)
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... [github.io]
dependency injection (Score:1)
Re: (Score:3, Funny)
Re: (Score:2)
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: (Score:2)
Don't forget an email client [wikipedia.org]
Re: (Score:1)
Well, you'll be one up on systemd then, it only has a web server.
Re: (Score:2)
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