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:Incorporate other stuff

[thinkingrodent]

I think I'll just add a web browser.

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

[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

[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

[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

[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:Portability with non-commercialised *nixes

[thinkingrodent]

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

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.

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.

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

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...

[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.

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]

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 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: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.

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.

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.