[HN Gopher] Systemd through the eyes of a musl distribution main...
___________________________________________________________________
Systemd through the eyes of a musl distribution maintainer
Author : awilfox
Score : 141 points
Date : 2024-01-06 07:02 UTC (15 hours ago)
(HTM) web link (catfox.life)
(TXT) w3m dump (catfox.life)
| dijit wrote:
| Before this topic boils down to: SystemD gave me cancer/SystemD
| cured my aids as it always seems to. Please permit me get my
| opinion across (as it is more nuanced) before I continue.
|
| I sincerely believe that systemd solved a problem that nobody was
| willing to solve, and it has every right to solve those problems
| any way it wants (when you ask for help you don't get to choose
| how you are helped after all) - my concerns boil down to the fact
| that the adoption it has seen has lead indirectly (or, directly)
| into a monoculture; and a monoculture that almost certainly will
| stifle innovation since a replacement will need to be bug-for-bug
| compatible. Prior init's were actually quite easy to replace and
| alternatives were often used, but these days most software
| assumes systemd and this situation gets worse every year.
|
| That said; and with the knowledge that while I am afraid of
| systemd as monoculture (and a relatively opaque one); this line
| "systemd, as a service manager, is not actually a bad piece of
| software by itself. The fact it can act as both a service manager
| and an inetd(8) replacement is really cool."
|
| Is something I vehemently disagree with.
|
| For starters, (x)inetd is an anti-pattern, everything I
| understand about systems development indicates we should be
| seperating concerns as much as possible, having one super-server
| that launches everything under one daemon is directly opposed to
| this.
|
| "But", I hear you thinking already: "systemd runs services as
| independent users, it solves that!", and I would agree with you,
| except now pid 0 is listening to the network instead.. That
| doesn't strike me as much better.
|
| If there's a bug/backdoor in your binary distributed version of
| systemd then you are SOL and your whole system is owned as root,
| but at least a bug in your application might not expose your
| entire inetd user. :\
|
| It's also a common issue that inetd's architecture can lend
| itself to getting DoS'd harder than other more-standard daemons,
| except now it's your pid 0 being DoS'd; not sure how you recover
| from that honestly.
|
| EDIT: if you are going to downvote, please provide reasons. Sick
| of this holy war, lets just end it reasonably please.
| awilfox wrote:
| The monoculture problem is one that I really tried to cover in
| the article, indeed.
|
| While I do agree that a "super server" listening to the network
| could be a new (or old, with (x)inetd) concern, a well-written
| and well-designed pid1 doing this isn't much more risky than
| having the services manage themselves. The listener
| could/should be just as unprivileged as the target daemon,
| nominally using the same uid/groups and root directory as the
| target as well. And indeed, systemd's .socket files support the
| same environment control variables (User=, Group=,
| SupplementaryGroups=, RootDirectory=, WorkingDirectory=, et al)
| that services do.
|
| So that boils down to "are people writing socket activation
| units correctly", which is probably "no", but could be "yes".
| znpy wrote:
| > The monoculture problem is one that I really tried to cover
| in the article, indeed.
|
| The issue is that the previous "multi-culture" really sucked
| real bad. It was a shit show, really.
|
| systemd is rising the bar by A LOT in terms of systems
| management, and most alternatives are simply not keeping up.
|
| But can you really blame it on systemd making a stellar job
| on its own?
|
| If anything, we could blame it on the "alternative projects"
| doing a fairly poor job and delivering very little.
|
| edit: systemd is so good that FreeBSD people have already
| started pondering if they should build something similar for
| themselves: https://www.youtube.com/watch?v=o_AIw9bGogo
| dijit wrote:
| Fuuuuuck I hate that talk by Benno.
|
| Mostly it strawmans the opposition, says its because they
| dont like change primarily.
|
| Then he indicates that macos's launchd is an improvement,
| despite it being one of the most painful parts of advanced
| macos administration.
|
| Its a talk that comes up often in these threads but it
| completely betrays the idea of having a fruitful dialog
| about the pros and cons of this design and the situations
| where it can be beneficial.
| acdha wrote:
| > Then he indicates that macos's launchd is an
| improvement, despite it being one of the most painful
| parts of advanced macos administration.
|
| This seems like a rather hot take. Most of the Mac admins
| I knew when I worked in the field were quite happy to
| have a single standard way to solve that class of
| problems.
| sevagh wrote:
| >"systemd runs services as independent users, it solves that!"
|
| It's in a terrible way, too. Not sure it improved but I recall
| somebody once, at a company I worked at, trying to introduce
| per-unix-user systemd services (e.g. `graphite` user for
| running Graphite), and there were some atrocious steps required
| like `loginctl --enable-linger` and God knows what.
|
| We moved to running everything systemd as root, it's easier
| (and you can specify which unixuser the actual systemd unit
| runs at, which is "close enough").
| Nullabillity wrote:
| Loginctl/per-user systemds are for managing interactive
| sessions. System services with User= is exactly the way you'd
| go for isolating background daemons.
| ptx wrote:
| What if you want to let a non-root user manage the systemd
| unit for a particular service? Is there a better way than
| per-user systemd instances?
| chuckadams wrote:
| chgrp, setfacl, sudo.conf ... lots of choices.
| acdha wrote:
| Check example 3.4 here for a polkit policy allowing an
| arbitrary user to restart a single unit:
|
| https://wiki.archlinux.org/title/Polkit
| twic wrote:
| Does this let them modify the unit file, create units,
| create timers, etc?
|
| User systemd allows that kind of complete self-service,
| and so lets you do application deployment and management
| without touching the root account, which is rather nice.
| ptx wrote:
| Why is inetd an anti-pattern? Isn't separating all the work of
| opening ports and launching daemons into a separate component
| (so that it's not mixed into every other component) exactly
| what separation of concerns is all about?
| pi-e-sigma wrote:
| Inetd approach is just fine. Don't listen to to the
| worshippers of systemd complexity. It's like listening again
| the guys who insisted that JEE is the future and you are
| stupid because you prefer simple solutions to simple
| problems.
| Karellen wrote:
| > my concerns boil down to the fact that the adoption it has
| seen has lead indirectly (or, directly) into a monoculture;
|
| Were there multiple implementations of sysv-init being used by
| different distros on Linux before systemd came along?
| dijit wrote:
| yes, at least 5.
|
| sysvinit, s6, openrc, runit and Solaris SMF
| Karellen wrote:
| Were they alternate implementations of sysv-init? Or did
| they do their own thing, and also happen to run sysv-init
| scripts for back-compat? Because systemd also runs sysv-
| init scripts for back-compat.
|
| Edit: Also, were any distros actually shipping those as
| supported init systems? I was under the impression that
| most of them were still in the "experimental" stage and not
| viable replacements (yet).
| liveoneggs wrote:
| OpenRC and Solaris SMF definitely did their own thing.
| SystemV-init and the "run levels" concept was flawed from
| the very start when it replaced the previous BSD-style
| "single user" vs "multi user" boot up.
|
| Linux only adopted SystemV style init because it was the
| norm in Solaris at the time. It is not a linux-ism.
|
| As this article notes - systemd is actually _fine_ as an
| init system and hardly anyone denies it. It 's all of the
| other stuff (journald, resolved, timers, etc) + tight
| coupling + environmental assumptions that is the problem.
| awilfox wrote:
| I'm unaware of any Linux distribution using SMF. If there
| was, I would have been running it. I didn't really like
| pfexec (it felt bolted on and not quite there yet), and I
| really really hated ZFS (and still do), but SMF made
| Solaris administration a joy.
|
| I don't think any distribution was using runit before
| systemd, but it was available in Gentoo as a sysvinit
| replacement and ISTR it was used in the Rails community
| for supervising Unicorn.
| rst wrote:
| "Nobody was willing to solve" is a bit of a stretch when
| upstart got shipped at pretty much the same time. (Sponsored by
| the commercial home of a particular Linux distribution -- but
| so was systemd.)
| acdha wrote:
| I used Upstart a lot but it did less and had various unfixed
| bugs whose failure mode was becoming unmanageable. I give
| Ubuntu credit for starting it but was reminded of jwz's CADT
| rant periodically until we upgraded to a release which used
| systemd instead.
| Nullabillity wrote:
| > Prior init's were actually quite easy to replace and
| alternatives were often used, but these days most software
| assumes systemd and this situation gets worse every year.
|
| Not really. Sysvinit scripts are... scripts full of
| sysvinitisms (double forking and PID files, anyone?). Idiomatic
| systemd daemons are, comparatively speaking, very
| straightforward. Of course, there are a lot of nice-to-have
| features, but to get a running system, you should largely be
| able to get away with parsing Wants=, After=, and ExecStart=.
| einpoklum wrote:
| > Not really. Sysvinit scripts are... scripts full of
| sysvinitisms (double forking and PID files, anyone?).
|
| ... well, a bunch of scripts are something that's relatively
| easy to replace. It's not as though other system components
| have reliance of these scripts and their sysvinit'isms baked
| in.
|
| From what I've heard (though not verified) - non-systemd
| distributions seem to manage to work with upstart, or openrc,
| instead of sysvinit, without much hassle.
| dijit wrote:
| Previous inits were glorified loop { fork() } programs.
|
| There were many scripts, many implementations, but
| interestingly most were compatible with each other.
|
| The largest issue inits had was that the flexibility they
| provided gave distro maintainers a lot of choice in how
| those scripts should operate to be consistent with the rest
| of the system.
|
| Things like log locations.
|
| The issue to be solved is: how to determine parallelism in
| boot, how to supervise a process with minimum complexity,
| and how do we do structured logging.
|
| Interestingly: SMF solved all of these a decade before.
| einpoklum wrote:
| > Previous inits were glorified loop { fork() } programs.
|
| Maybe (I'm not an expert on old init systems), but
| current inits aren't that.
|
| > The issue to be solved is: how to determine parallelism
| in boot
|
| I think you're replying to another comment of mine. At
| any rate, there were and are alternative solutions rising
| to meet this challenge - which involve nothing like the
| behemoth which is systemd. Examples: OpenRC, runit, GNU
| Shepherd (sort of).
|
| https://en.wikipedia.org/wiki/OpenRC
| einpoklum wrote:
| > I sincerely believe that systemd solved a problem that nobody
| was willing to solve
|
| What problem was there which nobody was willing to solve?
|
| Also, "solving" a problem by creating a mechanism that in
| itself highly problematic in other ways does not necessarily
| count as a solution; it is a shifting-around of problems.
|
| -----
|
| The systemd "holy war", such as it is (mostly complaints on
| forums and in blog posts and in personal chats; don't remember
| any violence in this war) - is due to four reasons:
|
| * The significant problems which systemd introduces.
|
| * The way systemd has been developed and managed as project
| (including some grievances with individuals).
|
| * The fact that distributions have not only adopted systemd,
| but made it effectively impossible to opt out of.
|
| * Faults with the process in which systemd was adopted as a
| required default by all of the main distributions - bypassing
| wide opposition without addressing its criticism. So, the
| adoption of systemd exposed technical-governance/power-dynamics
| problems in the Linux distro world, with systemd serving as the
| symbol for those.
| tuna74 wrote:
| "* The fact that distributions have not only adopted systemd,
| but made it effectively impossible to opt out of."
|
| The job of a distro is to decide what to ship and integrate
| that in the best way possible. Would a distro let you choose
| between glibc and musl for example? If you want either, use a
| distro that chooses that.
| awilfox wrote:
| This has more to do with systemd trying to be a "system
| layer" project for Linux, and influential projects
| (initially Gnome, then KDE, and now a lot of other things)
| going along with it.
|
| Honestly, I see no reason a distribution couldn't support
| multiple service managers. Indeed, Gentoo officially
| support OpenRC and systemd and do just fine. However, you
| need to have the resources to do it _and_ the desire. I
| think there are multiple distributions with one or the
| other, but Gentoo is likely the only with both.
| einpoklum wrote:
| > However, you need to have the resources to do it and
| the desire.
|
| If resources were lacking to offer both regular and
| systemd-based init and service management, than a systemd
| offering should have been deferred until such time when
| resources become available, or different projects did
| some work of their own to reduce the amount of necessary
| resources. Offering multiple other init/service
| management options apparently doesn't require many
| resources.
|
| (Of course, they could have saved a lot of resources by
| dropping GNOME until the GNOME people started being civil
| and not hard-depend on systemd... but I realize that's a
| bit of a controversial suggestion :-P )
| throwaway7356 wrote:
| > systemd offering should have been deferred until such
| time when resources become available
|
| Why would you delay adoption of a technical superior
| solution if there is no interested/lack of resources in
| continuing maintenance of the inferior solution?
|
| Distributions did not stop adopting Python 3 and invested
| in continuing Python 2 either.
| einpoklum wrote:
| > Why would you delay adoption of a technical superior
| solution if there is no interested/lack of resources in
| continuing maintenance of the inferior solution?
|
| But a technically superior solution was not on the table
| to become the default, the suggestion was to use systemd
| and effectively prevent the use of anything else
| (including potentially technically superior solutions).
| awilfox wrote:
| I like the off-by-one there, and choose to interpret it as
| intentional.
|
| The fourth item is what I find to be the most interesting. I
| really hadn't thought about it that way before. I remember
| the discussion in Fedora mailing lists around systemd and
| iirc the criticisms were mostly actually answered and
| handled. But in Debian it really wasn't and it fractured the
| community a lot.
|
| It is perhaps the case that the "anti-systemd" crowd wouldn't
| be "anti-systemd" if they felt like they had been heard.
| Perhaps that's the bigger lesson we should all be learning:
| to listen closely and respond respectfully.
| einpoklum wrote:
| > I like the off-by-one there, and choose to interpret it
| as intentional.
|
| Amongst our weaponry are such elements as... I'll come in
| again.
|
| https://www.goodreads.com/quotes/1495-nobody-expects-the-
| spa...
|
| > It is perhaps the case that the "anti-systemd" crowd
| wouldn't be "anti-systemd" if they felt like they had been
| heard.
|
| I would say it is the other way around. systemd would not
| have been adopted as the default init system, had the anti-
| systemd crowed not been ignored.
|
| But that's not even the main point. The grievance is not
| about how some individuals did not "hear". It is about the
| _possibility_ of such a decision being taken with that
| level of technical-community resistance; i.e. the
| expectation is that decent process would not depend only on
| the benevolence of those in charge. That's why it's a
| structural rather than a personal failure IMNSHO.
|
| And again, there's the conflation, or bundling, of the
| multiple decisions:
|
| 1. Offer systemd in the distribution
|
| 2. Make systemd the default option for the distribution
|
| 3. Necessitate installation & use of systemd with the
| distribution
|
| I am specifically pretty certain that Devuan would never
| have been forked if systemd were merely a configurable
| installation option in Debian.
| throwaway7356 wrote:
| > I am specifically pretty certain that Devuan would
| never have been forked if systemd were merely a
| configurable installation option in Debian.
|
| You can't stop 5 or so random people on the internet from
| starting the 100th irrelevant Debian-based derivative.
| teddyh wrote:
| > _now pid 0 is listening to the network_
|
| Pid 1, surely.
| acdha wrote:
| > For starters, (x)inetd is an anti-pattern, everything I
| understand about systems development indicates we should be
| seperating concerns as much as possible, having one super-
| server that launches everything under one daemon is directly
| opposed to this.
|
| It means that this server had to be carefully secured but the
| benefit is that you have exactly one bit of heavily-audited
| code listening to the network, logging activity & problems,
| starting processes, changing users / dropping privileges,
| setting up namespaces, etc. I've seen a lot of code get various
| combinations of those wrong so I think that's a far more
| nuanced problem than in your portrayal.
|
| Those are all things people should know how to do but I've seen
| Java or PHP running as root in production because someone
| couldn't figure out how to drop privileges needed only at
| startup enough times to appreciate the benefits from systemd
| making it so much easier to do things right.
| INTPenis wrote:
| Nice article, after years of emotional flaming finally something
| fair and balanced about systemd.
|
| The point about there existing no competition and no respect for
| glibc alternatives is very valid and to that I can only say; if
| you build it, they will come.
|
| Systemd had the advantage of Red Hat backing so they got a great
| headstart. But in general people will use whatever works. So roll
| your sleeves up and get cracking.
| nerdponx wrote:
| I always appreciated this presentation for being a reasonable
| and balanced take, if you're interested in other examples:
| https://youtu.be/o_AIw9bGogo
| plagiarist wrote:
| If someone built the vision in this article I would use it. I
| love declarative config.
|
| The article is such a good take it makes me want to try out the
| author's Adelie project.
| throwawaaarrgh wrote:
| People will use what works. But there is a limit. If you have
| two things, one of which does everything under the sun, and the
| other only does _mostly_ everything, people tend to choose the
| first. The more people do this, the more "weight" the first
| carries. Until one day, it makes no sense at all to use
| anything _but_ the first. Even if it causes you tons of
| headaches. The more different the two are, the less and less
| likely that you could or would ever switch. It 's too big not
| to use. And so, building an alternative becomes a fool's
| errand. Nobody would use it, because there's just too many
| reasons why they shouldn't or can't.
|
| (In case you don't believe me: it is now impossible to run a
| desktop without a half dozen Systemd shims, because the entire
| ecosystem is now hard coded to use Systemd. I know because my
| desktop is Alpine Linux, a musl distro)
| traverseda wrote:
| No kde?
| awilfox wrote:
| KDE really, really needs logind - it can't really use
| ConsoleKit any more. Same with SDDM, though I think the CK2
| backend is still writhing in agony somewhere in its
| codebase.
|
| And KDE's touchpad integration relies on libinput, which
| relies on udevd. I think libinput _might_ work with mdev if
| you really try hard enough?
|
| I am not aware of KDE having dependencies on any other bits
| of systemd, at least Plasma 5 LTS doesn't.
| addicted wrote:
| Red Hat backing SystemD was hardly an advantage beyond the fact
| that it had financial muscle.
|
| So for example, Red Hat backing meant that Canonical would have
| to be pulled in kicking and screaming to use SystemD and Ubuntu
| is one of, if not the most influential distro in the Linux
| world.
|
| Ubuntu created and used upstart until it basically lost out to
| SystemD and had to move over.
| dmwilcox wrote:
| What I heard and I'm not sure how much truth is in it -- but
| it's fun gossip so enjoy -- is that upstart needed some work
| done, and Poettering went off for 6 months and came back with
| a replacement (instead of a fixed upstart). If anyone knows
| the full/real story of systemd origin I'd be curious
| stryan wrote:
| RHEL6 did use upstart, but when RH tried to submit
| patches/work with upstream like they do with most projects
| they ran into issues with Canonical's CLA and other
| submission policies. So when Poettering came back with
| systemd they went "what the hell" and switched to that.
| pengaru wrote:
| jrb explained the origin story to me once in passing at a
| gnome meetup in SF irl ages ago. But the only part I recall
| is it involved Lennart and Kay collaborating on a new init
| system on their own... without rh even initiating the
| project. I got the impression that this was a sort of rogue
| effort from these guys.
|
| Folks direct a lot of systemd hate at Lennart, but just
| take a look at the journald header[0]: uint8_t
| signature[8]; /* "LPKSHHRH" */
|
| == Lennart Poettering, Kay Siver, Harald Hoyer, Red Hat
|
| I don't know the details but I heard at some point Kay and
| Lennart had a falling out within the project. By the time I
| got involved in journald development @ CoreOS, neither Kay
| nor Harald were visibly participating anymore... It was
| kind of annoying, as it left just Lennart to review any
| journald PRs, who was obviously busy, but eventually got
| around to it. I think it's worth noting that despite being
| the person who receives all the systemd hate, Lennart
| didn't promptly abandon maintenance of the project after
| getting installed everywhere.
|
| [0] https://github.com/systemd/systemd/blob/v255/src/libsys
| temd/...
| ofrzeta wrote:
| I've found systemd-nspawn to be a great alternative to the olde
| chroot method for fixing systems in a rescue shell. systemd-
| nspawn -D /mnt mounts the system like chroot but the real value
| comes with systemd-nspawn -b -D /mnt/ that actually boots the
| system in a container.
| q2dg wrote:
| I use systemd-nspawn as a built-in alternative to LXC/LXD.
| awilfox wrote:
| Thanks! I hadn't considered that use case.
| habitue wrote:
| Maybe a good way to get competition is to give someone a possibly
| dubious (but fun!) goal of writing a systemd compatible
| alternative in rust.
|
| Reimplementing such a massive piece of infrastructure is pretty
| daunting. I don't think many people who are not being paid to
| would embark on it and then keep up the momentum to actually
| cover all those edge cases and maintain a community around it.
|
| Rewriting things in rust seems to be pretty motivating though, so
| maybe it could be a force for good here
| nerdponx wrote:
| If you're just looking for init and service management, the S6
| system (and its wrapper 66suite) are pretty good. It's the only
| alternative that seems to match Systemd for feeling like a
| modern tool in my opinion, rather than a relic of the old days.
| generalizations wrote:
| Been watching that for a couple years now. At one point there
| were plans to integrate with alpine Linux, but it wasn't
| ready yet. Has there been progress towards that?
| awilfox wrote:
| Yes, there is some progress it seems:
| https://skarnet.com/projects/service-manager.html
| throwaway7356 wrote:
| Don't want s6 as it brings with it a binary configuration
| database (Windows registry). systemd at least has text files
| for config.
| egberts1 wrote:
| My sole resistance to s6, binary config AND default-all
| privilege for spawned daemon.
|
| Better to stick with INI v1.4 format.
|
| https://cloanto.com/specs/ini/#escapesequences
| milliams wrote:
| There's a willingness from the systemd devs to start
| incorporating Rust into it, possibly quite soon:
| https://github.com/systemd/systemd/pull/19598
| habitue wrote:
| From 2021?
| notamy wrote:
| The original PR is from 2021, but there's been activity on
| it that's less than a month old indicating that it's still
| wanted, especially as the kernel starts to integrate Rust.
| sevagh wrote:
| Systemd is Godsent for people who have to administer diverse
| Linux boxes.
|
| I can see how people who want to run their own tight ship on
| their machine would balk at it. I also sort of hate the systemd-
| resolv and the fact that it instantly rendered worthless 99% of
| online guides of how to unfuck your local DNS resolution.
| forinti wrote:
| I had no opinion on systemd until I found out I could configure
| the mount points in fstab to magically mount themselves
| whenever they were needed.
|
| I have a lot of network shares and some of them caused real
| trouble when they failed for whatever reason.
|
| Now I really appreciate it.
| pi-e-sigma wrote:
| Various automount tools have been available since the 90s.
| mariusor wrote:
| Indeed, why use Dropbox, when FTP existed for decades?
| pi-e-sigma wrote:
| Except these automount tools provided exactly the same
| functionality that is currently provided by systemd. And
| did it better
| bravetraveler wrote:
| I contest _' better'_. What's the difference? It's
| mounted... no?
|
| Allowing _' systemd'_ to be aware of mounts lets you
| create dependencies between your mounts and services.
|
| For example: _' Requires=mnt-myfs.mount' (and 'After')_.
|
| Use _' PartOf'_ if you want the service to get restarted
| during an unmount/re-mount.
|
| This integration is mint! Anything _not_ systemd _[when
| it 's already managing your services]_ trying to
| orchestrate is, by nature, second-rate
|
| One may note the removal of the fstab generator. It's
| overblown. Any distribution including systemd vendors it.
| pi-e-sigma wrote:
| You obviously haven't used any of them and I have a
| feeling that in fact you haven't used anything but
| systemd because your remarks about systemd ability to
| create dependencies between mounts and services as
| something amazing is just hilarious.
| bravetraveler wrote:
| Sigh.
|
| I was hoping to be a bit more productive. I haven't used
| them, obviously, I asked - _' what's the difference'_.
|
| _They haven 't even been named._ Is this a troll?
|
| You obviously miss my point. In this hypothetical I'm
| picturing a systemd system with services and mounts.
|
| The recommendation appeared to be... have another service
| _[or something]_ try to provide something that _'
| systemd'_, which is already present, can handle
| completely fine.
|
| So, I repeat, what's the difference? What am I missing?
| What's better than having the thing managing your
| services also manage your mounts?
|
| Between the lines I'm saying this isn't fancy work. I
| want these mounted and useful relationships and that's
| it. They serve a purpose; I need a compelling reason to
| replace init.
| doublerabbit wrote:
| > Systemd is Godsent for people who have to administer diverse
| Linux boxes.
|
| I disagree whole hearty. With 15 years of system
| administratorship, me and systemd don't get on.
|
| Services timing out on start-up/shutdown, "waiting x/y -- x/y
| retries and hijacking resolv.conf are my common two.
| acdha wrote:
| > Services timing out on start-up, "waiting x/y -- x/y
| retries
|
| What would you prefer happen instead? Having seen plenty of
| downtime caused by not having retries or hanging indefinitely
| weren't exactly improvements in my experience.
| doublerabbit wrote:
| Leave the service dead, or just kill -9 the process.
|
| "service didn't start, oh well"
|
| "service didn't stop, force killing it"
|
| Is just fine.
|
| It's my responsibility to ensure the service is operating
| correctly, not all-for-one systemd. Redhat bloatware
| dictating how Linux should be.
|
| I am aware that I can change the timeout of retries, but
| that's documentation overhead.
| acdha wrote:
| > Is just fine.
|
| It's prolonged downtime, that's what it is, and it may
| make the system unusable. I saw that several times during
| the transition period where a network outage or data
| center shutdown meant that some important daemons failed
| on startup (one of them had the concept of retrying a
| connection error, but not a DNS resolution failure) and
| the admins of the SysV boxes had to manually restart
| everything while the Upstart & systemd boxes recovered
| almost immediately. One fun case had the developer almost
| getting this right: they had implemented retries but
| without a time delay or back off so their init script
| maxed out its retry count in a second of "host not found"
| errors and then exited permanently.
|
| When you leave things like retries, logging, or dropping
| permissions up to each daemon you end up with a
| hodgepodge of incomplete implementations and things like
| error handling are where corners tend to get cut the most
| since the situations are infrequent and often hard to
| simulate.
| toast0 wrote:
| > It's prolonged downtime, that's what it is, and it may
| make the system unusable
|
| IMHO, that's how I feel about systemd --- if a startup
| task is stalled, the system is non-interactive, unless
| something has changed since I last experienced this
| issue.
|
| If some other operator access has started, you can use
| that, but the console is useless.
| t43562 wrote:
| I'm enjoying artix linux with dinit. I tried a couple of other
| alternatives - s6 and openrc - although I wouldn't say I was that
| fair on openrc.
|
| dinit may lack many things - I don't know - I haven't had any
| reason to be unhappy with it and it seems to work in a fairly
| understandable way. I defined a new service (for minidlnad) and
| that appears to be straightforward.
| Philpax wrote:
| This is quite a balanced take on the matter. Appreciated!
| kemotep wrote:
| > I prefer my init scripts to handcrafted by local artisans. Each
| time the computer boots up is an objet d'art.
|
| In all seriousness this is a wonderful article. Has the author/op
| seen this talk[0] by a FreeBSD developer on systemd?
|
| What I like about the talk is asking about what is going to
| happen when we need to move on to newer ways of doing things that
| will have advantages and disadvantages over the old way. We can
| see a similar story with X11 and Wayland. Systemd does do some
| things better than the old way but does have flaws.
|
| [0]:https://youtu.be/o_AIw9bGogo
| macNchz wrote:
| I was a big skeptic earlier on, but I have come to appreciate
| systemd in recent years. That said, the section on resolved is a
| big one-it has been one of the only things that consistently
| causes me annoyance over the three years since I started
| primarily using Linux on the desktop.
|
| After one particularly deep rabbit hole where I never actually
| solved a problem where local network mDNS lookups always took
| exactly 6 seconds, I wound up disabling it entirely in favor of
| unbound, which works great but revealed that a handful of other
| things seem to expect resolved to be present and won't work
| properly without it.
| nijave wrote:
| More structured metadata in journald is nice and I don't have any
| qualms with binary logging formats, but the author does have a
| point on log shipping. Additionally, reading journal files has
| always seemed painfully slow to me (30 seconds of 100% CPU usage)
|
| I'm not overly found of timer units, either. They seem feature
| rich but much more complicated to setup than a single line in a
| crontab.
|
| On the other hand, real dependency management between daemons,
| mounts, and sockets is a huge win.
|
| I can't quite remember the right terminology but afaik systemd-
| resolvd supports routing different domains to different DNS
| servers on different network interfaces which can be auto
| configured via DHCP. The practical implication being, you can
| connect to a split tunnel VPN and domains accessed over the VPN
| get routed to the VPN DNS server.
| akritid wrote:
| It's called split DNS. Can be implemented using dnsmasq
| nijave wrote:
| It can be implemented with dnsmasq but dnsmasq doesn't
| integrate with DHCP (edit, client) out of the box and
| requires a restart to apply configuration updates which
| invalidates query cache.
|
| Edit-
|
| I think split dns more commonly refers to serving different
| internal/private and external/public zones.
|
| In this case, the DNS servers may return the same results but
| if I'm connecting to a VPN running some distance away, I
| don't want to route all DNS requests to that server--only the
| ones for domains on that network. The Domains directive
| allows configuring this https://man.archlinux.org/man/systemd
| .network.5#%5BNETWORK%5...
|
| You can add a dhclient hook to reconfigure dnsmasq with
| `server=` directives to achieve the same thing, but, as
| mentioned, that still requires restarting the dnsmasq daemon.
| That usually manifests as: the VPN connection times out, the
| hook runs, dnsmasq is restarted, but a random web page or
| request will fail while the daemon is restarting. Sure, you
| could do SO_REUSEADDR or something to prevent the disruption,
| but, once again, this all just works out of the box with
| systemd-*
| denton-scratch wrote:
| > dnsmasq doesn't integrate with DHCP
|
| DNSMasq is a combined DNS and DHCP server! Of course it's
| integrated!
| nijave wrote:
| I'm talking about a local caching resolver, not a server
| running somewhere else on the network. dnsmasq doesn't
| ship with a DHCP client
| denton-scratch wrote:
| I don't get your point. DNSMasq doesn't ship with a
| client, because it's a server. It's a cacheing resolver
| and a DHCP server that is usually run locally. I don't
| know of any system that doesn't come with its own built-
| in (or standard) DHCP client.
|
| Can you clarify your objection to DNSMasq?
| cbzbc wrote:
| His objection is that it doesn't replace the use case
| that resolvd is supposed to solve. Which is to provide a
| local service that can redirect DNS queries dynamically
| as local interfaces go up and down, which is where the
| integration with a DHCP client comes in.
| egberts1 wrote:
| Dnsmasq and resolvd is a beast to tame in homelab, and
| split network.
| wharvle wrote:
| > I'm not overly found of timer units, either. They seem
| feature rich but much more complicated to setup than a single
| line in a crontab.
|
| I've twice tried to use them. Closest I got to having one work
| was that it reported it ran, and didn't error, but it did not
| run. Extremely simple cases that were basically copy-paste an
| example and barely modify it, too.
|
| Oh well, add a line in cron and forget about it.
| chasil wrote:
| I use much functionality in systemd that was not present in SysV
| init, and I really appreciate it. It has never crashed any OS
| that I have run.
|
| However, there are a few aspects of it that are inconvenient.
|
| Automount units use an unintuitive naming scheme, and you are not
| free to name them as you wish (as you might for a socket unit).
| If you are mounting an NFS volume immediately below the root
| directory, you don't see the problem, but if the mount is several
| directories deep and/or uses ASCII symbols (non-alphanumeric), it
| is not pretty.
|
| Socket units require two files per port. When I am moving complex
| inetd.conf setups to Linux, it's far easier to implement them
| with busybox inetd than convert dozens/hundreds of services to
| unit files, despite the increased functionality. Somebody has
| probably written some scripting to do this.
|
| I am not aware of any include directive for my own directories,
| so I don't have to place everything in /etc/systemd/system. There
| probably is a way to do this, and I am betraying my ignorance.
|
| And my, things can get messy in a hurry in /etc/systemd/system.
|
| I don't know how to configure users to be able to maintain their
| own (personal) units.
|
| And lastly, it's so seductive that I have no idea how to do many
| things in other operating systems that I easily do in Linux. I
| wish this itself was not a walled garden (but I'm not leaving).
| assbuttbuttass wrote:
| > I don't know how to configure users to be able to maintain
| their own (personal) units.
|
| This is something I use all the time! Just put unit files in
| ~/.config/systemd/user and use systemctl --user to start/enable
| them
|
| https://wiki.archlinux.org/title/systemd/User
| isignal wrote:
| Just a note that this requires the admin to enable linger if
| the units need to be started before the user logs in and run
| after they logout.
| jiripospisil wrote:
| > I am not aware of any include directive for my own
| directories, so I don't have to place everything in
| /etc/systemd/system. There probably is a way to do this, and I
| am betraying my ignorance.
|
| Systemd by default looks at a bunch of directories depending on
| the context.
|
| $ systemd-analyze unit-paths (or --user / --global)
|
| https://www.freedesktop.org/software/systemd/man/latest/syst...
| greyw wrote:
| Reading the section about resolved reminds me of musl having a
| "broken" stub resolver implementation for years (whenever the dns
| payload was larger than 512 bytes). "Broken" because the TCP
| fallback was supposedly intentionally not added for complexity
| reasons.
|
| DNS and all the additions seem to be really not easy to handle.
| acdha wrote:
| Yes - that lower level networking stuff is just a minefield of
| edge cases which most people never need but are really annoying
| if you're unlucky enough to hit them, and Linux has always had
| this problem where if something works for Windows the people
| who run those broken networks and many users will say it's a
| Linux problem. A lot of the systemd decisions are probably
| explained by someone getting a ticket saying their Red Hat
| laptop takes much longer than Mac to get on the corporate
| network or was unable to deal with the captive portal on some
| hotel Wi-Fi, and they realized fixing it was going to require
| work across 5 different code bases.
| 20after4 wrote:
| I think this is the most likely explanation for why systemd
| includes everything but the kitchen sink. For consistency,
| and ease of maintenance, having it all under one umbrella is
| certainly a benefit (for the developers of systemd.)
|
| Also, NIH is a hell of a drug.
| remram wrote:
| I think the problem of systemd is that it is complex. It is fine
| when it works correctly, but when you eventually have to dig into
| any sort of problem, it is hell.
|
| For example, all of my boxes spew many logs per minute about
| "Failed to set up mount unit". This is apparently a bug with the
| generated name of some internal unit related to mountpoints (too
| long). This one is not as bad as others, because it does have a
| bug reported for it, but is still something I'll have to deal
| with until I upgrade the distro on all the servers. Many similar
| bugs I can't track down at all.
|
| Systemd makes a lot of things easy, but not simple, and that is a
| big problem in practice.
| twic wrote:
| This is it. For example, systemd (a) allows you to run services
| as a normal user, not as root, (b) treats child processes of a
| service process as part of that service, and (c) collects logs
| from services. Except if you try to do all three, that just
| doesn't work, because they've half-arsed the log collection
| process:
|
| https://serverfault.com/a/1143851/92104
|
| There's no reason for this not to work! Taking a very
| straightforward and traditional approach to running processes
| (as in my demo code in that question), you don't have this
| problem. But rather than that, they did something clever which
| doesn't work properly.
| thwarted wrote:
| I can't make heads or tails of either of those answers, and
| they seem to contradict each other. The output capturing is
| all to the same file descriptors, this is the way resources
| are inherited on fork (and there's no redirection here). That
| it works with unbuffer is weird because the subshell and
| subprocess both end up flushing their output when they exit,
| so there should be no need to flush before exiting.
|
| If the first answer is correct, then the unbuffer works
| because the process introspection as the source of the output
| is unified to be the unbuffer process. But why bother
| introspecting the exact process that originated a write to
| the output? Did we have a problem with file descriptors being
| highjacked? And even if we did, _losing_ the output (or not
| associating it with the parent process) is worse.
| ivolimmen wrote:
| I like the honesty of the article. I never got the grunge others
| have against it. I am a software engineer and work in office
| automation (a.k.a. the boring stuff). On Linux I am a poweruser.
| If Ubuntu used initd I use it. They switched to systemd so I use
| that. I liked it. Making an application start on reboot was easy
| to do. And easier than with the rc files 20 years back.
| jiripospisil wrote:
| I generally embrace systemd and have been pretty happy with it
| but there's one component which simply doesn't work correctly and
| that's systemd-resolved in combination with DNSSEC. I eventually
| had to replace it with Knot Resolver which works flawlessly on
| the same machine / network.
|
| https://github.com/systemd/systemd/issues/9867
|
| https://www.knot-resolver.cz/
| traverseda wrote:
| I originally wrote this comment for reddit, but I feel like
| hackernews might appreciate it. If you think it's too long or
| detracting from the article or something feel free to downvote, I
| won't be offended.
|
| Here are some of my criticisms, although I do still use systemd
| daily on my personal devices and servers.
|
| * Bad security
|
| Systemd is architected in a way that has a lot of code running as
| root, it's also written in a language that isn't memory safe.
| This means it has a large attack surface (a lot of code you need
| to make sure is bug free to be secure) and it's harder to make
| sure your code doesn't have really severe security related bugs
| (The [NSA recommends](https://www.nsa.gov/Press-Room/Press-
| Releases-Statements/Pre...) using memory safe languages for
| critical stuff like this).
|
| There are certainly other critical projects (like this linux
| kernel) that are similarly important and written in memory unsafe
| languages, but systemd has had some [pretty critical
| vulnerabilities](https://cve.mitre.org/cgi-
| bin/cvekey.cgi?keyword=systemd) discovered that do not inspire
| confidence in their ability to use these kinds of dangerous
| languages safely, and they don't have nearly the same budget as
| the linux kernel for detecting and preventing these kinds of
| issues.
|
| This is less of a problem if you're a large enterprise customer
| running up to date SELinux, but it should still have been
| possible to write systemd in a way that limited the pid1 attack
| surface while retaining all current functionality.
|
| * Journalctl is a pain for desktop users and smaller teams
|
| Journalctl is how systemd manages logs. By default it saves logs
| in a binary format with additional metadata. This makes it easier
| for large teams to ingest the logs into a centralized log-
| collection daemon, like the ones offered by redhat for enterprise
| deployments, but it breaks a lot of workflows that older
| sysadmins probably used. Things like just rsync-ing a bunch of
| logs to one place, or using tools like grep and find to inspect
| logs. Systemd does of course provide replacements for those
| tools, instead of using grep you can use journalctl to search
| through your logs, but you could use grep to search through any
| text file. Config files, source code, or logs. Now I need to
| memorize all the flags for one more tool, and change a bunch of
| stuff about how I collect logs.
|
| This also presents a challenge for people doing embedded work, as
| you can't just grab the SD card out of a system can look at it's
| logs. You need a working journalctl CLI on your host machine.
| They've add in a --directory flag, but in the past this was much
| harder, requiring you to actually chroot into the embedded system
| (that may be broken in strange ways) in order to read logs.
|
| Journalctl has advantages, but they're mostly enjoyed by large
| enterprises.
|
| Yes I know it's actually systemd-journal or just "journal" or
| whatever they call it. Journalctl is the command most users will
| be familiar with though.
|
| * Poor [Locality of behavior](https://htmx.org/essays/locality-
| of-behaviour/) makes it harder to reason about
|
| When you're trying to understand how a system works it's nice to
| be able to see everything in one places. There are like 9
| different places a systemd unit file can live, you can apply an
| over-ride to a unit file, unit files can depend on other files
| like socket files.
|
| This is good for large teams as it makes it easier for specific
| groups in a company to claim ownership over parts of the system,
| but it means as a desktop user or sysadmin working with a small
| business you've added a lot of complexity. You can't just type
| `ls /etc/init.d` to get a rough overview of what services exist,
| you need to memorize more systemd-specific commands. If you want
| to edit a service you can't just edit a service, you need to
| create an over-ride using another systemd specific command, make
| sure you have the EDITOR environment variable set up, and then
| open the original service in another editor so you can compare
| the two.
|
| It creates some more work and complexity and encourages you to
| use a bunch of systemd-specific tools (and presumably get red-hat
| certified training).
|
| * People use systemd stuff before it's ready
|
| I'm not sure this is something I can blame systemd or redhat for,
| but the official stance of redhat is that systemd-resolved is not
| ready for production, and yet it's used all over the place. That
| can give people a poor impression of systemd after the 9th time
| they try to do something even slightly different with their
| networking setups and systemd-resolvd breaks, not to mention the
| numerous security issues in systemd-resolvd.
|
| * Unix philosophy
|
| A lot of people say that either unix philosophy doesn't matter,
| or that systemd does embrace unix philosophy. That stuff about
| logging and systemd-specific tools I mentioned above? That's what
| people actually mean when they talk about unix philosophy, they
| mean being able to grep through their logs and rsync logs to a
| remote server. They mean using standard text files and not
| needing to have a special command that wraps your text editor to
| "properly" edit a unit file.
|
| * Doesn't run in a chroot
|
| As someone who splits my time between embedded linux and server
| linux this is just a personal pet peeve of mine. It makes it very
| hard to debug embedded systems that use systemd if you're not
| using systemd on your workstation. It does feel like I'm being
| forced to use systemd sometimes, and while I've largely gotten
| over it I'm still a bit bitter. It's also made some small
| personal projects, like getting a full linux distro running on a
| KoBo e-reader, much much more difficult than they had to be.
|
| It's a mess under docker, and why I need to use alternative OCI-
| runtimes like nestybox to do a bunch of testing for embedded
| systems. Thankfully I wasn't an early adopter to docker and
| didn't have those problems until there were already mature
| solutions. But there's really no reason why it should _have_ to
| run as pid1, other than them wanting you to use docker-
| alternatives that are deeply integrated with systemd, like their
| podman tool or systemd-nspawn. This was just such a blatant
| attempt to abuse their near-monopoly position that it bears some
| extra whining.
|
| * OpenRc does everything systemd does, but better
|
| Unfortunately other red-hat influenced projects like Gnome won't
| support or test on non-systemd init systems, let alone providing
| default services files for them, meaning that any distro that
| wants to be compatible with gnome will need to do a bunch of
| extra work to write and test service files. For one project
| that's potentially reasonable, and certainly there are distros
| that do that extra work, but for projects like Arch who have the
| explicit goal of sticking as close to upstream sources as
| possible it makes it more or less impossible.
|
| Systemd survives not because it's a good solution to the problem,
| but because it has a large corporate backer, is widely deployed,
| and is a safe thing to code against. There's a very old IT
| saying, "No one ever got fired for buying IBM". If you pick a
| safe industry-standard options no one can blame you if it goes
| wrong, even if it's the technologically inferior option.
|
| As much as I'm a systemd-hater I still do use it on my personal
| devices and servers, because it's by far the path of least
| resistance.
|
| I hope we see a similar situation like with pulseaudio and
| pipewire, where the pulseaudio rewrite was much much nicer than
| the original. I don't think that's going to happen until systemd
| slows down though, right now if you tried to re-implement systemd
| I suspect you'd get the rug pulled out from under you as they
| changed standards and behaviors (I've seriously thought about
| doing it myself, at least for relatively simple unit files). I'd
| still prefer to be using OpenRc, as I don't know how a rewrite
| would deal with the locality-of-behavior issues, but systemd has
| been getting better and more reliable over time.
| chuckadams wrote:
| > You can't just type `ls /etc/init.d` to get a rough overview
| of what services exist
|
| You never really got that on svinit systems either, since there
| was still inetd, and cron had at least three different places
| you had to look as well. With systemd, you have systemctl list-
| units and you're looking at everything -- to say nothing of
| being able to filter by status. rc files make you implement
| service control yourself from scratch every time (save for a
| small set of primitive utility functions), and every one is a
| snowflake.
| Denvercoder9 wrote:
| _> Journalctl has advantages, but they 're mostly enjoyed by
| large enterprises._
|
| I don't agree with this. As a single administrator, being able
| to do `journalctl -u <service>` and get all output from a unit
| (and its subprocesses), including anything that it erroneously
| send to stdout or stderr instead of its logfile, is a godsend.
| Back in the SysV days I had to manually step through
| initscripts to figure out what's wrong when a daemon
| immediately exited without logging anything.
| traverseda wrote:
| Sure, but couldn't you get the same advantages is systemd
| logged to a text file instead of a custom binary format? The
| advantages is that it's handling stdout, stderr, log
| creation, log rotation, etc.
|
| I'm not comparing it to sysvinit here, I'm comparing it to
| any other modern init system.
| realusername wrote:
| My biggest issue with that binary log format is that they are
| just reinventing a DB without being aware of it. And as they
| discovered, building a DB from scratch is hard, there's
| corrupted logs even in my own personal machine now.
| gavinhoward wrote:
| I think the author is right on just about everything.
|
| But the author is especially right on the need for competition.
| So I am working on it.
|
| I am building a build system, and I am making it usable as a
| library. When I have made it so, I will implement an near drop-in
| [1] replacement for systemd.
|
| You'll be able to use systemd unit files, and there will be an
| option to have binaries with the same name (off by default to not
| interfere, though) so that users don't have to learn new stuff
| right away.
|
| [1]: I am not going to implement journald for example; logs will
| be text, even if they are structured internally.
|
| Besides, implementing things to be perfectly compatible would
| only _strengthen_ the monoculture, not weaken it. The plan is to
| be compatible on the things that matter for distro integration,
| so that distros can ship both with little work, but have other
| things different, so that users can choose what works best for
| them between the two.
| traverseda wrote:
| Have you considered integrating this with OpenRC?
| gavinhoward wrote:
| I am not sure what you mean.
| twic wrote:
| In a similar vein, but already existing, nosh lets you use
| systemd unit files and commands via a shim layer:
|
| https://jdebp.uk/Softwares/nosh/
| throwaway7356 wrote:
| Does anyone use it? It there a distribution (BSD or Linux)
| using nosh?
| vetinari wrote:
| > I think the author is right on just about everything.
|
| The author is very wrong on the systemd-resolved bit.
|
| Not understanding the ability to have per-interface specific
| zones is ok; it is a thing for desktops with multiple
| interfaces that come and go (like VPNs, for example). There is
| no other resolver on Linux capable of doing it and integrating
| with NetworkManager. You can kinda-sorta make dnsmasq do it,
| but with some limitations.
|
| But the crown is taken by the "mDNS is better taken care of by
| a dedicated package like Avahi." Uh, oh. It is like saying,
| that you don't need Chrome, it's duties are better taken care
| by nginx. Similarly, you can use Avahi for _advertising_ mDNS
| services, but not for _resolving_. Which, as an user, you
| probably are interested in.
| awilfox wrote:
| You do realise avahi-client is a standalone CLI resolver, and
| Avahi is what both Gnome (gvfs) and KDE (kio) use to find
| mDNS clients on the network?
|
| There's also nss-mdns at https://github.com/avahi/nss-mdns
| but it is mostly unmaintained.
| smitty1e wrote:
| The Famous Article (TFA) is an exemplar of dispassionate
| substantive, liberal criticism.
|
| The shortcomings of systemd seem likely the overall shortcomings
| of open source: none of the $PROJECT maintainers experience
| $PAIN_POINT, so it is simply not a priority for $PROJECT.
|
| Somehow this seems a variation on the tragedy of the commons =>
| https://en.m.wikipedia.org/wiki/Tragedy_of_the_commons
|
| Without some capitalist skin in the game, the $PAIN_POINTS become
| difficult to prioritize.
| WesolyKubeczek wrote:
| I would in fact love a portable user-level process manager that
| can speak systemd unit files and is portable.
|
| Something like supervisord, but you use systemd unit files, and
| it tries to do as much as it can within limitations (process
| tracking sure can be wonky, no dbus everywhere, no cgroups
| everywhere, no absolute freedom in resource limitations if you're
| not PID 1).
| peter_d_sherman wrote:
| Most people (including most Unix greybeards!) _really don 't
| understand Unix's 'init'_ (AKA "the init daemon", "the init
| process", etc., etc.) -- much less any of its massively-
| increasing-in-LOC (and complexity!) successor programs...
|
| So we need to start with 'init'.
|
| 'init' -- even in its absolute first, simplest incarnation -- is
| _still too complex_ to understand correctly!
|
| You see, we need to shift perspectives!
|
| We need to shift perspectives from a longtime System
| Administrator -- to that of a new barebone OS programmer.
|
| What is 'init'?
|
| Is 'init' a program that handles runlevels, starts and stops
| services, that mounts filesystems, that processes messages, that
| captures dead processes, that waits for hardware to become
| available, that logs and maintains informational/database/etc
| files, that starts audio, that starts X11, that stars the GUI,
| that acts as a proxy for sockets, or does anything else with the
| system?
|
| No!
|
| From the point of view of a new barebone OS programmer (as Dennis
| Richie and Ken Thompson were when they invented Unix and invented
| 'init') -- 'init' is _NONE_ of these things!
|
| 'init' is only _THE FIRST PROGRAM, THE FIRST COMPUTER CODE THAT
| RUNS IN USER SPACE_.
|
| And that's it!
|
| _That is all that 'init' ever is, or ever was!_
|
| (User space, to recap, is the unprotected AKA "unprivileged" AKA
| "non-supervisor" memory running unprotected (AKA "user-land")
| code: https://en.wikipedia.org/wiki/User_space_and_kernel_space)
|
| 'init' (and every single 'init' successor program, i.e., OpenRC,
| systemd, etc.) -- are the _first program_ , the first set of
| computer code _OUTSIDE OF KERNEL CODE_ (which has been running
| and is currently still running) to be run by the system.
|
| Now, _what should that first program do?_
|
| See, that's the _magic question_ -- which gives rise to all that
| is to follow!
|
| In theory you could have an OS where the 'init' program, or its
| equivalent -- did absolutely nothing! But that wouldn't be very
| productive!
|
| If the 'init' program isn't itself a shell program (i.e., sh,
| bash, etc.) -- then (because there's no GUI at this point) the
| computer will not be able to accept typed command-line commands
| -- which is the _first thing_ that you want a new OS to do!
|
| So now our 'init' expands in scope (and lines of code)!
|
| Our 'init' could be hardcoded to launch 'sh' or 'bash' (or
| whatever shell program exists) -- but what if the user wants to
| change that?
|
| OK, so now we need our first configuration file. Where to put
| that exactly?
|
| Oh, it's on a filesystem that hasn't been mounted yet?
|
| Well, maybe init should mount that filesystem!
|
| Point is, _there 's a set of problems_ (and sub-problems!) --
| which give rise to increasing and increasing init's functionality
| over time!
|
| init, as the first user-space program for an OS to run, on
| whatever OS it is ran on, in whatever form it is in -- _could
| simply be written to run and 'outsource' all of its functionality
| to other programs_...
|
| But init (as it evolved into its very large LOC complex
| descendants) -- became a "dumping ground" -- for functionality
| that was inconvenient to go in other places and/or to be
| outsourced to other programs.
|
| See, _all_ of the code in all userland Linux utilities -- could
| in theory be grafted together into one big super program in
| userspace.
|
| It would have the same functionality as all of the individual
| Unix/Linux command-line programs put together (and maybe that
| would be desirable to some people). But from a Software
| Engineering "separation of concerns" AKA dependency reduction AKA
| modularity AKA "do one thing and do it right" AKA loose-coupling
| perspective -- doing that might not be so desirable!
|
| And yet, with the complexity brought about by 'init' descendants
| -- it seems like we're going down that exact route!
|
| Which leads us full circle (because history always repeats
| itself!) -- back to the reason _why_ Unix was created -- because
| of the complexity and problems brought about by the complexity of
| its predecessor, Multics!
|
| https://en.wikipedia.org/wiki/Multics
|
| Point is -- 'init' in whatever form it takes -- _is by no means
| obligated to do anything_ -- although if it is to do nothing,
| then it should at least launch one other program which will do
| something! If that 's the case, then why not put that under user
| control? But wait, if we're doing that, why not make it launch
| multiple other programs! OK, now we need a file to tell init
| where that should be! But what if the filesystem for that file is
| not mounted?
|
| Anyway, you see how the "rabbit hole" of problems (and increasing
| LOC complexity) forms!
|
| Related: https://www.joelonsoftware.com/2002/11/11/the-law-of-
| leaky-a...
| throwaway7356 wrote:
| > That is all that 'init' ever is, or ever was!
|
| Except it is not. The "init" process seen by users as PID 1 on
| the usual Linux distributions is far from the first program
| started by the kernel. There are usually hundreds of processes
| started before that PID 1 process gets started.
| bitwize wrote:
| What Lennart found is that pid 1 is the only process in the
| whole userland that can ensure a process is terminated without
| risk of race conditions. Hence, all the process management
| stuff HAS to be in pid 1 in order to provide consistency
| guarantees. Hence, systemd.
___________________________________________________________________
(page generated 2024-01-06 23:02 UTC)