
Uselessd: A Stripped Down Version of Systemd - ahomescu1
http://uselessd.darknedgy.net/
======
wpietri
Does anybody understand what audience systemd was meant to address, and what
problems it solves for those people?

I'm a recovering sysadmin, so these days I only maintain a few personal boxes.
Perhaps because of that, I'm having a hard time appreciating systemd. Having
reluctantly dealt for the last couple of years with upstart, redoing init
creates an awful lot of work and confusion, and I personally haven't
experienced much benefit.

Perhaps systemd is better, but everything I've heard about it makes me fear
the second-system effect [1] is in full force.

[1] [http://www.catb.org/jargon/html/S/second-system-
effect.html](http://www.catb.org/jargon/html/S/second-system-effect.html)

~~~
atombender
Upstart is much better than SysV initscripts, but introduces some other
problems. Systemd has a better design.

The main problem with SysV is that every script needs to do everything: It is,
after all, just a hook for the OS to call on startup (as well as a useful, but
not necessarily mandatory, way for users to interact with the service).

So every script needs startup config (Debian: /etc/default), PID file
management (start-stop-daemon), daemonizing (ditto), startup log management
(ie., tracking what happens until the program can start logging on its own),
limits (ulimit is per session, so every script has to do this to avoid
inheriting root's limits).

Plus, you don't get: Dependency management; automatic respawning on failure;
CPU and memory resource alotment; ability to list and inspect declared
services vs. everything else that's running; handling of orphaned forked child
children; etc.

Systemd has been accused of being monolithic, but it seems highly modular to
me, and more so than Upstart.

~~~
uselessdguy
Actually, you do get (limited) dependency management through insserv, which
was standardized by LSB and its set of initscript headers. Most dpkg and RPM-
based distros used them.

Automatic respawning is a job for a process supervisor, not a process manager
or initd. It's a separate duty altogether. So is resource limiting, which is
probably better serviced through separate tools that wrap around syscalls.

~~~
lobster_johnson
I disagree about respawning, but it probably comes from a difference in
opinion about what the scope of a "process manager or initd" should be.

To me, starting a service expresses the intent: This service should be
running. What the underlying process is is of no concern; a service is an
abstraction of an OS process, not the process itself. The service's "target
state" drives what to do with the process. I want to the service to be
running, irrespective of what the underlying process is, which means that a
process dying just implies it must be started again.

This functionality belongs in the init system first because it's closest to
the source, secondly because it's such a common requirement that it belongs
there. Sure, one can argue the technical design; respawning can be a separate
subsystem forked from the init, for example. But it should be an integral
_feature_ of the init system, not something I have to get from a third party.
To paraphrase Jobs, it's a feature, not a product.

This conflation of "target state" and "actual state" is something that so many
apps get wrong. For example, consider an FTP client or an IM client: If I
connect to a remote server and the connection fails, the app should not
require me to manually connect again. I, as a user, has expressed the intent
that I wanted to _be connected_. That's my target state. Whether that state is
_reachable_ is the concern of the underlying connection manager. The
underlying connection is just an implementation detail. Imagine if the lights
and all your electrical appliances didn't automatically come back on after the
power went out.

In other words, high-level abstractions should always attempt to be seamless.

~~~
uselessdguy
Most people don't make a distinction, but I feel that is important to note
these.

Strictly speaking, init(8)'s sole responsibility is to reap children, set the
session and process group IDs, and optionally exec the actual process manager.
In practice, this is bare bones, but strictly that's all that's required.

A process manager then usually provides an abstraction around processes
(usually PIDs) called a "service", implementing a minimum of
start/stop/restart/status. Status is most primitively done using a PID file.
Other extensions like conditional restart can be added.

A process supervisor then ensures that processes are automatically restarted,
that inotify(7) triggers are added, that system load is monitored, applying
resource limits, emailing an admin upon state change, etc.

Such a trichotomy is rarely expressed, but a hypothetical example that would
likely work would be sinit + svc + perp.

Autorestart should be expressly enabled by the sysadmin's choice and disabled
by default, due to the possibility of buggy daemons improperly backing up
their state, as well as edge cases that may be present in the admin's
particular environment.

~~~
vidarh
The problem for me with such a strict view is the special status of pid 1. You
can not have a reliable process manager without either putting it in pid 1, or
having restart logic in pid 1, since a process manager outside of pid 1 can be
killed without taking down the system, and thus can die unnoticed unless the
init includes restart logic.

You also have a second problem: How do you log failures reliably? Your process
manager can not do that, or be responsible for spawning something to do that
if it itself is pid 1 - it could be brutally murdered the instant it spawns
the next process, or at any random time, unable to pass on any temporarily
collected data while waiting on a suitable place to store said data.

There's a lot of thinking behind the systemd architecture that actually make
substantial advances over what we used to have, and that solves issues that
are not at all addressed by most other init systems. Your suggested sinit +
svc + perp for example would suffer from both the dead process manager problem
and the log problem. They are real - I've run into that more than once.

While I'm not in love with, or convinced by, how much stuff they've added to
it, also keep in mind that systemd is not just a pid 1 replacement. The
systemd project includes multiple components, only the core of which runs as
pid 1.

Maybe it'd be nice and useful to see that decomposed with clear API's
connecting them, but for now they're developed and shipped together, and I
understand why they don't particularly want to have to deal with that, but
seeing systemd-the-project as just an init replacement is not really the case
(though pid 1 in a systemd install still contains more than you suggests it
should).

~~~
uselessdguy
You can trap virtually all signals beyond SIGKILL.

Keep in mind I'm not advocating a strict separation, it does make sense to
intertwine to an extent for practical purposes. I'm mostly trying to say that
they're separate stages, and should not be completely equated for each other,
lest some undesirable design properties emerge.

------
uselessdguy
Figured I'd make a throwaway to answer questions.

I'm the person who goes by The Initfinder General. Feel free to ask and be
elucidated about uselessd and my general outlook on systemd/the state of
Linux/Unix, if you so wish.

EDIT: Proof it's me:
[https://forums.darknedgy.net/viewtopic.php?pid=78186#p78186](https://forums.darknedgy.net/viewtopic.php?pid=78186#p78186)

~~~
bkirwi
Was glad to see this; thanks! Systemd has made my Arch system overall much
easier to administer, but the monolithism makes me nervous. It'll be
interesting to see how things look once they've been broken up a bit.

I'm curious: are you trying to rescue a kernel of value from the systemd
project where it improves on existing systems, or is this mostly a proof that
it didn't need to be built so monolithically in the first place?

~~~
uselessdguy
It's a little bit of both, coupled with the fact that I simply wanted a
challenge, being a bored sap and all. This is probably the first remotely
noteworthy thing I've done.

The end goal is to drive systemd into a direction that focuses succinctly on
process management, having a portable base that can be transposed to other
operating systems. Still quite some way to go, but hopefully it'll be done
some day. But yeah, supplying systemd's core features for people who would
like to have a conservatively developed and focused service manager that won't
suddenly swallow the windowing system one day, is a key goal. Captures the
gist of it.

Eventually I might transfer control to someone else and focus on my own
interests. The eudev project lead has expressed some interest in us.

~~~
ycombine33212
When the original programmers felt their program was mostly done and stepped
away, others came in, a new breed, and diverted the trajectory of the
projects.

Well engineered software projects eventually are completed. And then people
shouting that anything not actively "maintained" is "depreciated" come in and
attempt and succede in using software for political gain or control.

Most of the "Debian Developers" are not the same sort of people that started
debian. They are often not programmers.

We who actually write software are looked down by them. The people who use
software are looked down upon by them. They are now a middle man, using their
position for control, rather than for helping. Like a bad government.

The Debian social contract even says the distro is for the sake of the users.

------
spb
This is the kind of thing I want to see when people criticize systemd: an
example of what they'd do differently (other than just "there's nothing wrong
with having a million lines of copypasted bash in init.d, I'll stick to
unsupervised several-minute boot times tyvm"). Bravo.

------
Nursie
Sounds good.

Because systemd always sounded like it solved some init problems but then
sprawled over so many other systems that it seems invasive and monolithic.

KISS.

~~~
erikb
Having one name to run tens of binaries under doesn't mean monolithic? Or is
GNU monolithic? or "*nix"?

~~~
ycombine33212
Yo bro, a bunch of subroutines put together to form a program aint monolithic
bro, you can use them seperate bro. They just happen to be used together bro!

~~~
erikb
My computer uses Linux kernel, init, Gnome3 and Gnome terminal together.
What's your point, bro?

------
jdeisenberg
I must be especially dense today, but when I follow the link, I see only the
title "usysd", links for Edit, Recent Changes, Preferences, and Discussion,
but no other content. What am I doing wrong?

~~~
uselessdguy
Sorry about that.

We've been under attack since shortly after we got covered on Phoronix.
Started off with IRC bot spam, but looks like they got the wiki, as well.
We're working on undoing it. Good thing ikiwiki is versioned.

It's a shame that software forks can summon such derision, but it looks like
init systems are serious business. Oh well.

The same person is also spamming the #systemd channel on freenode. Pathetic
display altogether.

EDIT: We're back.

In the meantime, our BitBucket repo:
[https://bitbucket.org/bcsd/uselessd](https://bitbucket.org/bcsd/uselessd)

~~~
jdeisenberg
Thanks. I realize startup systems are a controversial, but they hardly warrant
this. My only interest in them is "which one is best to teach students in a
beginning Linux admin course"?

~~~
techdragon
Old first so when you teach the new, they understand what has been abstracted
away.

------
qwerta
And that's how its done!

Provide alternatives. Do not complain that hairball of bash script works (if
nobody modifies it).

------
InfiniteRand
I find the systemd debate vaguely interesting but not especially relevant to
me, however I must applaud the effort of these guys. They were dissatisfied
with ongoing trends and decided to work on an alternative. Kudos, good sirs,
kudos.

------
namecast
Legendary. I'd love to see this installable as a .deb / apt repo / ansible and
puppet modules one day. Let's make fixing this mess as easy as possible for
the masses.

------
ycombine33212
EXXXCCCUUUSSEEE ME.

Your opinion is __DEPRECIATED __

You need to be banned from the mailing lists, you 're using TRIGGERING WORDS.

Harraser.

------
dang
Url changed from [1], which points to this. It was on HN yesterday [2], but
didn't quite exceed the "significant attention" threshold for dupes [3].

1\.
[http://www.phoronix.com/scan.php?page=news_item&px=MTc5MzA](http://www.phoronix.com/scan.php?page=news_item&px=MTc5MzA)

2\.
[https://news.ycombinator.com/item?id=8344059](https://news.ycombinator.com/item?id=8344059)

3\.
[https://news.ycombinator.com/newsfaq.html](https://news.ycombinator.com/newsfaq.html)

------
ycombine33212
Coup. The tech committee is made up of current or former redhat and canonical
employees. This is a social problem and needs a social solution. They took our
distribution from us. They came from the same place as the various womens
groups who invaded a few years ago and kicked out male programmers who opposed
them.

------
exabrial
> Is uselessd actually an elaborate false flag operation by Red Hat to
> discredit their opponents and install a New World Order?

> ...Fuck.

I loled

