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

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.

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