[HN Gopher] Systemd 252
___________________________________________________________________
Systemd 252
Author : rascul
Score : 92 points
Date : 2022-11-01 03:34 UTC (19 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| cat_plus_plus wrote:
| Is the project a new site sponsor or something? :-) I get it that
| systemd has some benefits - faster startup, more reliable
| production administration. And at the same time it's not
| everyone's cup of tea - for example, many believe that the
| strength of UNIX is many simple and interchangable commands
| rather than big monolithic code base controlled by a single team.
| Anyway, there have been 251 previous versions of systemd, so it's
| not clear to me why this one is special and deserving of our
| attention after another systemd related story yesterday?
| panick21_ wrote:
| You do understand how Hacker News voting works?
| twic wrote:
| Yes. Clicks on the voting arrows go to the HN backend, which
| routes them to systemd-votecount, which then generates
| article rankings and publishes them over D-Bus, from which
| the backend picks them up and renders them as HTML.
| russfink wrote:
| You, kind person, have won the Internet.
| Denvercoder9 wrote:
| > Anyway, there have been 251 previous versions of systemd
|
| Trivia: when udev (which was at v182) was merged into the
| systemd project, they skipped from v44 to v183 to align the
| version numbers; so there have only been 112 previous versions
| of systemd.
| stopdropnhotpot wrote:
| systemd is fine for single user systems and perhaps verts, but I
| would never deploy it on a server. The deprecation of cgroup v1
| is a welcome change. It's come a long way, but it still has a
| very long way to go.
| panick21_ wrote:
| Facebook runs lots of Systemd but I'm sure on your
| infrastructure you couldn't run it.
| Dah00n wrote:
| Facebook is a Bad Example on stability at scale..
| panick21_ wrote:
| No it isn't. Running a hyper-scale infrastructure is
| incredible fucking hard and doing it at all is amazing.
| stopdropnhotpot wrote:
| I imagine Facebook uses highly monitored virts that are
| spawned and destroyed constantly. I really wouldn't call them
| "servers" more like instances or staging hosts for
| containers. Root exploits aren't so serious in a ethereal
| state..
| panick21_ wrote:
| They use lots of different things for lots of different
| things I would assume.
|
| Also most people today use virtualization.
| otabdeveloper4 wrote:
| xdfgh1112 wrote:
| That isn't so true anymore, given their focus on home
| directory management and killing all user processes on logout
| (desktop-focused and doesn't work well with tmux or ssh)
| otabdeveloper4 wrote:
| > killing all user processes on logout
|
| This is a good default for the server use-case, to prevent
| developers and sysadmins launching stealth long-running
| jobs. (Especially if they steal resources.)
|
| The idea is you'd run batch jobs and services explicitly
| via systemd-run.
| lakomen wrote:
| That is such a bullshit comment, entitled and ignorant, genZ
| type of stupid
| rektide wrote:
| Small detail, but interesting to see varlink capabilities added.
|
| systemd-resolvd gains "monitor" capabilities via the lightweight
| json rpc system varlink.
|
| definitely useful just for monitoring dns broadly, seeing whats
| happening on the system. there's probably some more specific
| creative uses folks could hack together here.
| [deleted]
| t43562 wrote:
| I'm enjoying dinit in artix. I think Artix is not terribly
| mainstream but the dinit part of it seems easy to deal with so
| far. It would be interesting to see it get polished in a
| different distro.
|
| Living without systemd is sometimes a rough choice at the moment
| but I think it can be polished.
| Woodi wrote:
| Welcome to C: ...
| captainmuon wrote:
| About removing support for what they call split-usr and unmerged-
| usr: Why does a init system and daemon manager even need suppport
| for a certain directory layout, shouldn't it be agnostic? Having
| a separate usr-space saved my bacon in the past a couple of
| times.
|
| The thing I dislike most about Systemd is that it leads to
| homogenisation, where to me, running Linux is about choice.
| dsr_ wrote:
| I believe that the end goal of systemd is to end Linux
| distributions as anything other than a flavor.
|
| This will not work completely, but it may work well enough that
| non-systemd linux will be considered an unusual eccentricity.
| marcosdumay wrote:
| Until some eccentricity works well enough that everybody
| adopts it.
|
| Then it's only a matter of barriers and lock-in... And
| systemd imposes a lot of those.
| LeSaucy wrote:
| One could make the argument we are already there.
| VLM wrote:
| Systemd is literally the opposite goal.
|
| Paint everyone into the tiniest least flexible corner, let the
| submarine patents surface, shut it all down, "nobody could have
| ever seen that coming, well, we at least we have a discount for
| Windows Server licenses at this link..."
| HNDV wrote:
| http://www.islinuxaboutchoice.com/
|
| >where to me, running Linux is about choice.
|
| Quote :
|
| "From: Adam Jackson To: Development discussions related to
| Fedora Subject: Linux is not about choice [was Re: Fedora too
| cutting edge?] Date: Wed, 09 Jan 2008 15:58:45 -0500
|
| > Linux is about choice.
|
| If I could only have one thing this year, it would be to
| eliminate that meme from the collective consciousness. It is a
| disease. It strangles the mind and ensures you can never change
| anything ever because someone somewhere has OCD'd their
| environment exactly how they like it and how dare you change it
| on them you're so mean and next time I have friends over for
| Buffy night you're not invited mom he's sitting on my side
| again.
|
| As a consumer, yes, you have lots of choices in which Linux you
| use. This does not mean Linux is in any sense _about_ choice,
| any more than because there are so many kinds of cars you can
| buy that cars are about choice.
|
| The complaints up-thread about juju and pulse are entirely
| valid, but the solution is not to try to deliver two things at
| once. If you try to deliver both at once you have to also
| deliver a way of switching between the two. Now you have three
| moving parts instead of one, which means the failure rate has
| gone up by a factor of _six_ (three parts, and three
| interactions). We have essentially already posited that we have
| insufficient developer effort to have 100%-complete features at
| ship time, so asking them to take on six times the failure rate
| when they're already overburdened is just madness.
| Alternatively, we could say that we're integrating features too
| rapidly, but you do that at the expense of goal 1, to be the
| showcase for the latest and greatest in free software.
|
| Software is hard. The way to fix it is to fix it, not sweep it
| under the rug.
|
| There is a legitimate discussion to be had about where and how
| we draw the line for feature inclusion, about how we increase
| and formalize our testing efforts, and about how we develop and
| deploy spike solutions for corner-case problems like the one
| device class that juju happens to do worse than the old stack.
| But the chain of logic from "Linux is about choice" to "ship
| everything and let the user chose how they want their sound to
| not work" starts with fallacy and ends with disaster.
|
| - ajax "
| captainmuon wrote:
| Hah, I knew somebody was going to post this and almost added
| a disclaimer.
|
| When I say Linux, I'm talking about Linux distributions. Not
| the bare kernel, not embedded Linux.
|
| If I choose to use Linux over macOS or Windows, the #1 reason
| is that it gives me greater choice. On the desktop, to choose
| different desktop environments, to customize it to a greater
| extent than what is possible on other platforms. (That even
| applies to some extent to the server, I can choose from a
| greater selection of alternative services and am more
| flexible than in the Windows Server world, where it is more
| often a IIS, MSSQL, .NET stack.)
|
| If I don't value choice, than frankly there is very little to
| make me choose Linux over whatever is preinstalled on my
| Laptop. I used to have fun tinkering with my Linux
| installation and developing my own tools and workflows etc.,
| but now that I'm older and don't have so much disposable time
| I prefer something that is good enough out of the box. I'm
| sure many people can relate.
|
| If the greater Linux community still embraced "Linux is about
| choice", and I could still run stuff in the "mix and match"
| spirit of ca. 2009, but with a modern kernel and modern apps,
| then I would immediately switch to desktop Linux. But you
| can't choose your window decorations, themes, desktop panels
| independently anymore and get a somewhat matching look and
| feel. It's only Gnome island, KDE/Plasma island, and hacker-
| minimalist island.
| [deleted]
| Macha wrote:
| The kernel initramfs only mounts the root partition - parsing
| fstab and running mount is handled as part of init. This means
| that an init system needs to support split-usr by ensuring it
| can go without the contents of /usr at least long enough to
| bootstrap (which requires special treatment of the mounting
| scripts/units) or else avoid using /usr at all
| rfmoz wrote:
| SystemD fundation basement was a Linux implementation of the
| MacOS LaunchD. It was a step forward over the traditional init
| managers, but in any case disruptible over something new, because
| an equivalent design was running on Apple devices time before.
|
| http://0pointer.de/blog/projects/systemd.html
| fullstop wrote:
| launchd or perhaps, more likely, upstartd.
| rfmoz wrote:
| UpstartD was the good alternative offered by Canonical, but
| Redhat finally won with their SystemD.
| xyzzy_plugh wrote:
| upstart was terrible. I wanted upstart to win, I invested a
| ton of personal and professional energy into making it win,
| and it was all a terrible mistake. The design was simply
| backwards. systemd was right from the start.
| KingOfCoders wrote:
| I love systemd for deploying Golang, especially the security
| features, that systemd can own the TCP port for zero downtime
| deployments of the application and restarts of a fail-fast
| application. It kind of replaced Docker (dockerd) which I've used
| with deploying Scala and TS.
| mnutt wrote:
| It's great, you can have it launch multiple processes on the
| same port using SO_REUSEPORT. Normally it'd be a bit of a pain
| to health check multiple processes running on the same port
| without some other machinery since it is possible to get into a
| state where all but one process is hung. Systemd watchdog will
| provide your service with a socket and expect updates on a
| regular interval or else it will consider your service dead.
| This socket is also very handy for service startup, to have
| your process just notify systemd it is ready rather than having
| to poll to see if your process is listening yet.
| bbarnett wrote:
| _own the TCP port for zero downtime deployments of the_
|
| It's not zero downtime, if the app isn't reaponding. And any
| infra that cares about uptime, has redundant instances.
|
| This feature is, IMO, a feel good feature.
| dinosaurdynasty wrote:
| It's zero downtime in that at no point does the kernel not
| respond to a TCP SYN packet and all those connections
| eventually get seen by the daemon. (Really useful for
| updating local services on Unix sockets.)
|
| It's also much simpler than redundant instances, and
| applications are updated much more commonly than hardware
| failures so it's a cheap way to increase availability in
| practice.
|
| And if your app can restart in a couple seconds... It might
| as well be zero downtime, and if not responding for a second
| is an issue, you have bigger issues.
| bbarnett wrote:
| I believe that if a webpage (for example) doesn't download
| all resources, and be fully responsive in under 100ms,
| there is an issue.
|
| So maybe you think I have issues in general.
| dinosaurdynasty wrote:
| Using a server language with GC will break that.
|
| Using any kind of network that isn't hardwired to the
| server will break that. (Cellular, WiFi, roommate starts
| downloading an update over DSL, etc)
|
| Even just having other services on the server spike in
| usage can break that.
|
| Also I'm talking about "100% of requests finish in
| 100ms", which is damn near impossible, vs "99.9% of
| requests finish in 100ms", which is very doable and
| having a couple seconds a day you don't respond isn't
| going to break that.
| xdfgh1112 wrote:
| Hey, someone rediscovered xinetd
| athrun wrote:
| It's challenging to restart a service without dropping
| connections with xinetd.
|
| Even more so when the process is misbehaving, has children,
| and is not exiting cleanly.
| vegai_ wrote:
| >Hey, someone rediscovered xinetd
|
| With a much better piece of software, exactly.
| blueflow wrote:
| I once won a backdoor contest by installing a systemd socket
| who launched /bin/sh as root. At this point, people don't
| question why systemd is being bound to some random ports.
| biorach wrote:
| were you able to install this without using sudo?
| blueflow wrote:
| In the contest you had root access for a limited amount
| of time, but you can also do it via a user unit.
| Xylakant wrote:
| But then you should only get the users account as shell,
| so while this is a neat trick, being able to gain
| persistent root if you are already root is not that hard.
| blueflow wrote:
| It was part of the contest that your enemy team is not
| able to detect and remove your backdoor. The obscurity of
| systemd sockets was my winning move.
| wmrtynhber wrote:
| systemd doesn't bind to random ports without being told
| to. if the blue team didn't stop and say "why is
| _anything_ listening on port %d ", they're a trash blue
| team.
| xorcist wrote:
| Clearly you have not used systemd and friends much.
|
| It is an ecosystem of daemons that does a lot of things,
| some of which are guaranteed to surprise you. The
| specifics of which will vary between releases.
|
| I could easily see some random systemd utility binding a
| non standard port without anyone taking notice.
| klodolph wrote:
| I remember using xinetd, and while xinetd does do the job...
| sometimes... systemd is much more comprehensive, so you don't
| need to fuss about with different configs for xinetd, cron,
| init.d, etc. This is especially nice since the number of
| config options has skyrocketed, so systemd really simplifies
| administration (in my experience, at least).
| oblio wrote:
| > Hey, someone rediscovered xinetd
|
| 1. http://0pointer.de/blog/projects/systemd.html
|
| Replacing inetd was a systemd design goal.
|
| 2. Snark for someone learning is a bad move.
| xdfgh1112 wrote:
| It was in jest, xinetd is clearly not as powerful as
| systemd and I'm glad to be rid of it.
| KingOfCoders wrote:
| Isn't it astonishing? I've been using Linux pre-Slackware
| with downloading boot.tgz and root.tgz on two floppy drives,
| wrestled with M4 and sendmail, have been writing internet
| applications for 35+ years but never used a Linux daemon to
| manage my applications. You're never too old to learn I
| guess.
| xdfgh1112 wrote:
| I use systemd at work and I have finally learned to love
| it. Still don't like binary logs but the timers, watchdog
| and sandboxing features are wonderful.
| panzi wrote:
| I configurated the systemd services at work to redirect
| the services' output to syslog.
| legulere wrote:
| That's a pretty long list of small changes, but nothing really
| sticks out. I don't really see any ground of discussion about
| this.
| stevefan1999 wrote:
| I just never get why people always flame on systemd. Sure, it's
| kinda bloated in the sense that it is "battery included" just
| like Python, but the intention to have a stable init with great
| system and service management is very good from both a DevOps and
| Sysadmin perspective. It is at least much better than writing
| your adhoc init.d script that may not guarantee to run on other
| Linux distros.
| mindslight wrote:
| I think it just has many details you can end up hating, so a
| person will inevitably run into one or two.
|
| I myself don't have a problem with the monolithic thing that
| replaced sysv init scripts. While the definition of sysv init
| scripts was attractively simple, the resulting implementation
| was not. Wading through many lines of boilerplate shell that's
| mostly accidental complexity is not my idea of a good time.
|
| But I do hate how systemd splays its config and dependency
| graph throughout hundreds of tiny files and symlinks in
| multiple directories (and .ini files at that!), and then
| insists that this is no problem because you can "just" learn
| some bespoke commands to analyze them for you. With my sysadmin
| hat on, I'd much rather have a unit be a single file in a
| single well known directory, that specifies only the service
| properties and no dependency information. And then have the
| dependencies orchestrated by a single logical top-level file
| that pulls those units in and defines what depends on what. In
| general if I'm going to customize a distribution-supplied
| config file, I'd much rather overwrite the distribution file
| and completely own it going forward, rather than having the
| distro file and my file merged with some arbitrary rules.
|
| Having said that, I've moved many of my machines to NixOS where
| systemd is just another thing to be mitigated and nixified. The
| expected on-disk format doesn't matter, because it's all
| generated from a single logical config file and then splayed
| out however systemd wants. The nix config looks a bit verbose
| and wonky, but at least it's contained. But it also feels like
| it would be quite easy to switch out down the line...
| VLM wrote:
| Systemd is a somewhat successful non-unix operating system,
| marketed to people who want a unix-like operating system using
| force. This isn't what anyone wants but you'll go along or
| they'll unleash a hell of sophistry about how this is "really"
| what everyone wants even if its the opposite, made up stories
| about the opponents, or only bad people don't want what we want
| and you don't want to be tagged as one of the bad people so
| you're gonna say you officially love systemd, correct?
|
| It would be like going to the EV car dealership and being told
| the best modern EV they sell is a diesel pickup truck and they
| will unleash sophistry hell on anyone who doesn't go along with
| their meme that the best modern EV is obviously a diesel pickup
| truck but pointing that out in public is doubleplus ungood
| badthink.
|
| Ironically, for a non-unix-like operating system, its not that
| bad and works some of the time, although not as well as a unix-
| like OS would work for someone who's engineering criteria is a
| unix-like OS. Most people would be technically better off with
| a unix-like OS than a systemd based OS, but thats not what the
| corporate marketing department is selling, so we all love
| systemd, uh huh.
| esarbe wrote:
| Rubbish.
|
| Linux+GNU is either a Unix operating system or it is not.
| Having systemd on board changes exactly nothing, since there
| never was a system services interface anyway. Files in a
| directory you say? That's not an interface, it's a recipe for
| failure. Or why do you think that every distribution used to
| ship their own init scripts?
|
| You EV car dealership is awfully flawed, especially with
| Linux+GNU you can even build you own car. So why are you
| complaining? Nobody is forcing you to use a distro with
| systemd. Nobody _can_ force you. You 're not a victim, you're
| privileged.
|
| systemd is for the first time providing Linux+GNU with a sane
| system services management and finally gets it ahead of OSX
| or windows in terms of capability. Instead of unconstrained
| bash scripts (that require ridiculous template magic or fail
| for the first edge case) you need only a ten line service
| description that does things that an init script would not
| been able to deliver. Like the most basic thing ever;
| reliable restart. The amount of hacks that were necessary to
| get an init script to only semi-reliably restart are
| atrocious - and deamontools are just the beginning.
|
| I've come to understand that the dislike of systemd has less
| to do with the technology at hand but more with human nature.
| traverseda wrote:
| > and you don't want to be tagged as one of the bad people so
| you're gonna say you officially love systemd, correct?
|
| That does seem to be like weirdly a thing with redhat
| projects. I once saw someone say that being anti-systemd was
| correlated with supporting trump on hackernews, and of course
| if you don't like gnome you hate accessibility and poor
| people (who apparently don't know how to use less
| hobbled/phone-like user interfaces).
| cptnapalm wrote:
| While systemd does have many good features, it also has failed
| to turn computers off on various systems and distros. I repeat:
| failed to turn computers off. This wouldn't be acceptable in
| beta quality software. But it's systemd and for whatever reason
| gets a free pass on failure to do incredibly basic things.
| twic wrote:
| I think it's because there were other alternatives that solved
| the same important problems, while being much simpler and less
| intrusive.
| lakomen wrote:
| The arrogance of Lennart has something to do with it. The way
| he tends to disregard real bugs as not a bug, since he and his
| production are perfect and always right. Numerous cases of
| that. Then the security aspect of a jack of all trades process
| running as one that controls every other process. Reading logs
| after a panic and rebooting to check them is a pain in the ass
| without journald on the chrooting system, reading and parsing
| logs the same.
|
| There are many reasons to not like systemd and the creator, who
| incidently after leaving the GNU/Linux is now working for the
| same company that sought to destroy it, Microsoft.
|
| The above doesn't represent my personal opinion, it's a
| representation of what reasons people might have.
| rfmoz wrote:
| About the bugs, the Github have 1.8k issues open.
|
| That makes me think, is there a way to know what are the
| projects with more open issues on Github?
| jcranmer wrote:
| Just some large projects whose bug trackers are on github:
|
| * LLVM: 19,219 open issues
|
| * Rust compiler: 8,580 open issues
|
| * Python: 6,693 open issues
|
| The number of open issues isn't a particularly good
| indicator of program quality.
| lotharcable wrote:
| > There are many reasons to not like systemd and the creator,
| who incidently after leaving the GNU/Linux is now working for
| the same company that sought to destroy it, Microsoft.
|
| Yeah, well... Microsoft is probably soon to be one of the
| bigger Linux developers out there. As the profit slowly
| drains out of the desktop their core business model is going
| to be increasingly dependent on open source and Linux.
|
| Just in case anybody reading this is a big fanboy of Linux...
| This is what winning feels like.
| denton-scratch wrote:
| > who incidently after leaving the GNU/Linux is now working
| for the same company that sought to destroy it, Microsoft.
|
| Woah, I missed that news! I don't imagine he'll stop writing
| Linux software though.
| TacticalCoder wrote:
| > There are many reasons to not like systemd and the creator,
| who incidently after leaving the GNU/Linux is now working for
| the same company that sought to destroy it, Microsoft.
|
| I only learned about that a few days ago, here on HN (some
| thread or some old comment).
|
| It is completely insane and gives _lots_ of fuel to the
| systemd haters.
|
| I do run both Debian (systemd) and Devuan (a Debian fork with
| all the systemd stuff removed). I use Devuan on my main
| desktop PC and I've got exactly zero problem.
|
| That's the thing: many "sell" systemd as some mandatory
| machinery but it simply ain't. Ultra-light containers (like
| Alpine-based ones) run fine (and faster) without systemd.
| Desktops do run fine without systemd (I'm running Devuan on
| my workstation and Debian on my laptop: it's basically the
| same experience). For certain types of servers I can
| understand some see benefits in running systemd.
|
| Neither IBM / Red Hat nor Microsoft should be those setting
| the terms of what is or is not an acceptable "PID 1" for
| Linux.
|
| The day Linux becomes "systemd Linux" is the day I'll switch
| to a BSD.
|
| I don't mind that systemd exists as long as people still have
| the choice to run a non-systemd Linux. The kernel should be
| orthogonal to systemd and there should be Linux distros
| packaged without systemd.
|
| And systemd proponents shouldn't go out of their way to try
| to prevent non systemd Linux from existing.
| atonse wrote:
| > It is completely insane and gives lots of fuel to the
| systemd haters.
|
| Sorry, what exactly is the issue with a bunch of Linux
| maintainers working for Microsoft? Is there still some sort
| of collective adjustment issue with Microsoft being a major
| backer of Linux now? If the maintainers themselves (people
| who have dedicated their lives to progressing Linux) are ok
| with it, why does anyone else have an issue?
|
| And what kind of fuel would it add? That systemd has
| corporate backers?
| bbarnett wrote:
| _And what kind of fuel would it add? That systemd has
| corporate backers?_
|
| Systemd was 100% created by redhat, so no, corporate
| backers aren't the problem.
|
| The real problem is that Microsoft has historically tried
| to destroy linux, and beyond that, has a huge history of
| FUD and embrace and extinguish.
|
| Many in the OSS community consider Microsoft to be pure
| evil.
|
| And if their historical behaviour is any indication,
| nothing they do with/for Linux will turn out well, or
| good for the community.
| atonse wrote:
| I totally get it - I've watched it all unfold over the
| last couple of decades.
|
| But everything I see since Nadella has taken over, tells
| me that they aren't just paying lip service, that they
| have just realized nearly a decade ago that it's good
| business to embrace (loaded word) Linux if they have any
| chance for Azure to succeed, and their moves suggest
| that's a core part of their future.
| PoignardAzur wrote:
| > _The real problem is that Microsoft has historically
| tried to destroy linux, and beyond that, has a huge
| history of FUD and embrace and extinguish._
|
| And now they're one of the major backers. All the work is
| being done in the open, so it's not like there's a
| nefarious hidden agenda there (an agenda that would have
| needed to somehow stay dormant for 10+ years).
|
| The idea that working for Microsoft is something dirty
| that should be shunned for open source just doesn't make
| practical sense.
| bbarnett wrote:
| Pulseaudio was developed in the open. So was systemd, and
| many take issue with that.
|
| And embrace and extend can exist in OSS models.
|
| Microsoft _is_ dirty, and it is dirt they cannot wash off
| in a mere few years.
|
| If they behave correctly for 20 years, as long as they
| behaved in a literally evil fashion, then maybe they have
| reformed.
| Maursault wrote:
| > and there should be Linux distros packaged without
| systemd.
|
| systemd should be an _optional_ package on all distros.
| Shoving it down throats is one of the valid major
| criticisms. What should have happened instead is systemd
| was optional on Debian at setup and Debian was forked to
| include it by default. It is simply backwards that Debian
| needed to be forked for purity. Duvuan shouldn 't need to
| exist, but it very much does.
|
| The entire ideology of openness and freedom has been turned
| on its head. Instead of "what is best for everyone is good
| enough for me," has become with entitlement "what is best
| for me is good enough for everyone." Maybe you like the way
| you do things, but would any here really insist on
| _forcing_ everyone else to use your methods and no others?
|
| systemd, among other valid criticisms, is unmistakably
| fascist. For anyone but parent, don't just be thin-skinned
| and downvote my comment because you have allowed yourself
| to be insulted. Be courageous and disagree with me if you
| can. How is systemd _not_ fascist?
| piperswe wrote:
| The primary definition of fascism, according to the
| Merriam Webster dictionary, is this:
|
| > a political philosophy, movement, or regime (such as
| that of the Fascisti) that exalts nation and often race
| above the individual and that stands for a centralized
| autocratic government headed by a dictatorial leader,
| severe economic and social regimentation, and forcible
| suppression of opposition
|
| systemd has nothing to do with nation or race. There are
| much better words than fascism to describe Debian's
| prioritization of systemd.
| Maursault wrote:
| Thank you, and a worthy attempt, but as you have defined
| _Fascism,_ the political movement and a noun and proper
| name, as opposed to the adjective _fascist_ , as in
| advocation of an authoritarian regime and in opposition
| of and intolerant of opposing views, and in modern
| definitions, a synonym of "bullying," your post is
| somewhat of a straw man. Obviously I was not suggesting
| that systemd was literally Nazi software. What I was
| saying is that systemd, as an unnecessarily complex
| machine in itself as it proceeds to annex other parts of
| the system, is autocratic, strongly regimented and
| centralized, suppresses opposition, and subordinates
| individual interests.
| oofnik wrote:
| I would suggest a better word to describe systemd design
| philosophy is _authoritarian_ , if we're going to stick
| with political science terminology.
|
| Human systems tend to flourish when political and
| economic decision-making is relatively distributed
| throughout a given population. I believe this position is
| backed by a reasonable amount of empirical observation.
|
| Machines are (as of this writing) programmed by humans.
| Unlike humans, machines are automated rule-followers.
| This is substantively different from decision-making,
| which is a uniquely human trait involving moral agency,
| free will, etc. (at least as I'm defining it for the
| purposes of my argument). If you try to turn humans into
| automated rule-followers by decree, they tend to become
| miserable. Fortunately, one does not have to take into
| account how machines feel about being absolved of all
| decision-making, making such control systems very
| effective (you don't have to kill / imprison the
| dissenters). But even though the machines might be more
| effectively programmed by a centralized, unified, top-
| down, "authoritarian" control architecture, you still
| need humans to build this controller. And since we know
| software projects end up mirroring the communication
| structure of the humans in charge of building them, it
| follows that authoritarian-minded software engineers
| would be a best fit for building such systems.
|
| The converse is that libertarian-minded software
| engineers tend to recoil in horror when they encounter
| authoritarian software design, no matter how unified,
| elegant, or effective it may be. Such things are a _moral
| transgression_ to the libertarian.
| bbarnett wrote:
| _And systemd proponents shouldn 't go out of their way to
| try to prevent non systemd Linux from existing._
|
| All the changes to gnome, which depended 100% upon systemd
| at the time, were pushed by redhat, gnome contributers.
|
| This one of the biggest reasons given, for getting systemd
| into debian at the time.
|
| When systemd was being pushed origionally, fast boot times,
| predictable names, and a few other things were big reasons.
| Yet debian already had parallel init booting, and already
| had predictable interface names.
|
| Systemd has done almost nothing for debian, and has many
| drawbacks, as you say.
|
| Systemd was a redhat solution, to redhat issues, and redhat
| used its power in the community to force it through.
|
| There were a lot of outright lies, politics, and more at
| implementation time. And you're right, part of it was
| redhat wanting to force systemd, and no other.
| WastingMyTime89 wrote:
| > Numerous cases of that.
|
| Like when? Because I have interacted with projects where
| Lennart is part of the admin team and from where I stand it's
| all in your head.
|
| Both bugs and security are taken seriously.
|
| > The above doesn't represent my personal opinion, it's a
| representation of what reasons people might have.
|
| I admire the courage you display in standing for your
| opinion.
| labawi wrote:
| I don't know about your experiences, but systemd is leaking
| preconceived notions and self-imposed limitations like a
| broken sieve where one is left to sift manually through
| documentation and bug-reports, collecting and evaluating
| rules, exceptions and idiosyncratic notions to determine
| whether systemd will do what one wants.
|
| Latest example: I have a service I want running, so I set
| it to Restart=always. Read the long Restart= documentations
| - seems ok. Does it work?
|
| Failure 1: Well.. you also need appropriate
| RestartSec/StartLimitInterval. Ok, I I set it up. Does it
| work?
|
| Failure 2: Well.. restart doesn't actually apply to failed
| dependencies, so .. don't have dependencies that fail, ok?
| That's not a bug. [1][2]
|
| [1] https://github.com/systemd/systemd/issues/1312 [2] http
| s://unix.stackexchange.com/questions/213185/restarting-s...
| VancouverMan wrote:
| It's quite simple: many people had atrocious experiences with
| systemd.
|
| Systemd ruined Debian for me, for example.
|
| I'd been using Debian testing for years and years, on multiple
| systems. Despite its name, I'd always found Debian testing to
| be more reliable than the stable releases of other major
| distros.
|
| When performing updates and upgrades during those many years of
| using Debian testing, I had only ever experienced trivial
| issues that I could easily resolve, usually just on my own with
| a few minutes of investigation.
|
| Then systemd was forced onto Debian's users.
|
| As soon as it ended up on one of my systems, the problems
| started. That very first update left my computer unable to
| boot. That was the first time in over a decade of using Debian
| that that'd happened. I also remember it taking far too long to
| diagnose and resolve whatever that initial problem was.
|
| Subsequent updates involving systemd just caused me more and
| more problems. They usually weren't minor issues, either.
| They'd significantly impact the usability of my installation.
|
| To make matters worse, I, as a user, didn't see systemd even
| bringing me any benefits.
|
| Eventually, I lost my ability to trust in Debian and its
| reliability, even for Debian stable once systemd eventually
| made it there.
|
| Now I completely avoid Debian and other systemd-using Linux
| distros whenever I can.
| shrubble wrote:
| People who want to use it can use it.
|
| I am thankful for the non-systemd distributions, which are listed
| at https://nosystemd.org ; just scroll down to the list if you
| want to skip the advocacy.
| [deleted]
| ohCh6zos wrote:
| I have absolutely fallen in love with FreeBSD after Debian and
| Arch stopped being what I wanted.
|
| It feels closer to what I wanted than a proper Linux.
| shrubble wrote:
| I have found FreeBSD to be very coherent as a Unix; and the
| documentation is very well written. Jails, once understood,
| seem very good also, even if not perfect.
| Timja wrote:
| I despise systemd.
|
| Having shell scripts that you can read and edit makes so much
| more sense.
|
| Putting a script in a directory to have it run at startup makes
| sense. Systemd's approach of "registering a service" is hell.
|
| Having logs in plain text is beautiful. Having to use special
| software to read logs is hell.
| tenebrisalietum wrote:
| So I think systemd is becoming a tentacle demon upon Linux but
| "registering a service" is not hell.
|
| - You create a new whatever.service text file with some
| data=value pairs and put it in /etc/systemd/system. Doing this
| is at least only 25% as hard as learning bash.
|
| - systemctl daemon-reload
|
| - systemctl start whatever.service
|
| Not hard.
| Octabrain wrote:
| You can still have your wonderful script but in the case of
| systemd, you delegate the execution lifecycle of that script to
| a unit, which, IMHO, is a great abstraction compared to the
| mess of having to deal with the status of the service from the
| script itself. You simply throw the unit file into directory,
| then enable it. Your script does its thing, systemd deals with
| when to run it, in which runlevel etc
|
| About the logs, yes, plain text files, commands and pipes are
| great, but journalctl is really great too. It is powefull and
| includes everything you might need to inspect logs with
| accuracy in the same tool.
|
| Just to clarify: I'm not a fanboy, I'm just pragmatic.
| lakomen wrote:
| > journalctl is really great too
|
| until you're forced to run a rescue system without systemd
| and try to read logs. And don't say that it doesn't happen,
| because that situation is 99%.
| fullstop wrote:
| Surely the answer here is to add tools to the rescue
| system. You could make the same complaint with systems that
| use file systems not yet supported in rescue systems, such
| as zfs, btrfs, etc.
|
| Why would you limit what can be done based on the current
| abilities of a rescue system?
| xarthna wrote:
| I have long been an advocate against systemd for the typical
| reasons (overreaching responsibilities, lock-in, lack of choice,
| software assumption "it will be there", complexity, driven by
| large corporate interests [see lock-in], being modeled after
| launched, etc etc). I feel like the chickens are coming home to
| roost.
|
| That said, if one wants to use it, then use it. However, there
| _are_ alternatives which I would love to see receive more
| adoption. I 've been extremely happy with my Artix [1] system
| running s6 [2] init.
|
| 1. https://artixlinux.org/
|
| 2. https://skarnet.org/software/s6/
| teddyh wrote:
| > * _At shutdown, systemd will now log about processes blocking
| unmounting of file systems._
|
| Nice.
| k_bx wrote:
| I love systemd for everything except its cron replacement,
| somehow it's a real mess. Yet I desperately want something more
| modern to play with journald well. Any advice?
| loudmax wrote:
| Systemd timers are more complicated than cron, but there's a
| reason for the complexity. Once you've put in the extra effort
| to understand the logic, they're really powerful.
|
| If you don't want the complexity, then just run crond.
| esarbe wrote:
| I concur with siblings suggestion of systemd timers. Works like
| a charm. Has jittering and nice tui.
| mariusor wrote:
| I think generally people view timers as a net superior
| alternative to crons: they have better logic for the times,
| they support dependencies, they support randomized delays, etc.
| Why do you think they're a real mess?
| k_bx wrote:
| I guess their UX for a simple cron-like use-case. I remember
| trying to set it up and it wasn't a great experience. Just
| trying to see if others agree or not.
| dinosaurdynasty wrote:
| The arch wiki has really good documentation on them.
|
| And they are so much more debuggable than cron it's insane,
| they are a lot easier for anything non-trivial.
| boncho wrote:
| Systemd is without doubt one of the most important items of
| software on a modern Linux today, except perhaps for the Linux
| kernel itself. It turned the mess of shell scripts and other crap
| into the rock-solid, foundational system services layer we enjoy
| nowadays. If we do ever get the year of the Linux Desktop, we
| will have to thank the authors of systemd for giving us a bedrock
| of delight to build upon.
| europeanguy wrote:
| I'm not a Linux expert, but I thought that systemd was
| generally hated?
| excsn wrote:
| Hehe, I remember some people complaining about it. I never
| could hate SystemD once introduced to it as an infrastructure
| engineer. The difference was night and day in Debian (from
| wheezy to jessie).
|
| Setting common sig handlers, restart on exit, etc. are just
| one-liners with unit files. In the previous one, SysV, it was
| an annoying incantation especially if you were a newbie, like
| me at the time, or product engineer who was dabbling. You
| could easily screw it up. Some non infra engineers cursed the
| SysV files and loved the SystemD unit files.
|
| Now I use dynamic user and the other security features in my
| unit files and wonder how many lines it would have taken to
| do that in SysV, so the complaints are laughable at this
| point.
| traverseda wrote:
| Less hated ad time goes on. I still think it's
| architecturally stupid (look at openrc for something that
| accomplishes similar goals but better), but it's been a while
| since it's broken anything terribly for me, or introduced any
| terrible security vulnerability. It's not great, but it's not
| actively hurting.
| esarbe wrote:
| From my experience this was never much more than a very vocal
| minority.
| otabdeveloper4 wrote:
| Yes, it's so hated that it's impossble to find a Linux system
| that doesn't use it.
| tux3 wrote:
| A couple years ago, absolutely. To decide whether to
| generally hate systemd, and with what intensity, you should
| follow a curve that decreases proportionally with how long
| ago the change was made, and that starts as high as the
| multiplication of how much churn it causes times how old the
| thing it replaced was, all of which is of course multiplied
| again against the buggyness curve
|
| When pipewire replaced pulse, despite pulse being well
| established and a core desktop component, there was very
| little churn and few bugs. People not impacted did not mind
| at all that a major component was changed, or that it did
| many things and bundled three completely different protocols
| into one, arguably not very reminiscent of Unix
| Philosophy(tm)
|
| I would confidently predict that a change as large as
| systemd, to a component as old, and that causes as much churn
| (rewriting, relearning) would follow a roughly similar hate
| curve, only distinguishing itself by whether it was more
| buggy or less buggy than the predecessor.
|
| It's churn people hate, not change. The lesson I learned is
| that you can make large changes to the system, it's only
| hated when it forces humans changes.
| how_gauche wrote:
| Pipewire broke me lots of times during its development and
| rollout, and that's okay, because new software has bugs and
| in some of my other use cases "hey it's a lot better than
| Jack". What I'm not going to do is carry a grudge against
| the maintainer for decades?
|
| I've been using Linux since Slackware installed from a pile
| of floppy disks. I'm extremely happy with systemd (desktop
| and server) and view it as one of the most important UX
| advancements ever made in the Linux sysadmin space. It
| replaced a smorgasbord of broken nonsense with a unified
| and thoughtful system that is objectively superior to what
| it replaced. I suspect a lot of the extreme reaction to
| systemd is not just resistance to change, but based on an
| emotional attachment to the rag-tag heterogeneity it made
| obsolete.
| alxlaz wrote:
| It's worth remembering that much of the churn was caused
| not by having to rewrite configuration, but by the
| multitude of bugs that plagued systemd early on, and the
| way they were treated did not help. systemd upstream was
| extremely difficult to work with and made a lot of people
| reluctant to embrace change, because when something didn't
| work -- which we all understood was natural for software
| developed in the open -- you were pretty much screwed.
| Shell scripts and duct tape were bad but it could take less
| time to fix something than it took to get people "up there"
| to admit that they're really looking at a bug, not a
| feature.
|
| I ran systemd very early on because it gave me some things
| I liked from SMF but I completely understand why so many
| people hated it. It's a (suite of) program(s) with good
| ideas that was hampered by extremely poor maintainership
| and relation with other open source projects.
| HNDV wrote:
| >thought that systemd was generally hated?
|
| If it was generally hated there would be a lot more support
| for the distros that don't have systemd. There isn't. Except
| for alpine, all of them are extremely niche, half of them are
| dead, the other half barely have enough people to stick
| around for a release a year. Even alpine is kinda niche, it's
| mostly used as a way to make lightweight docker containers,
| rather than as a distro that stands on its own, the fact it
| uses musl as its libc means you can't use it on a server that
| has nvidia gpus for machine learning, you can't use it on a
| desktop where you need a browser capable of DRM, you can't
| use it on a personal computer if you ever intend to install a
| video game etc.
|
| I have -yet- to hear anyone in my life actually use something
| like Devuan, the systemd-less fork of Debian, in a production
| environment. Six years after their first release, instead of
| standing on their own as a distribution, they're still deeply
| angry and obsessed with systemd and this is the level of
| professionalism they exhibit on social media :
| https://twitter.com/DevuanOrg/status/1586963662295687169
|
| Of course, one of the twitter comments underneath is "systemd
| macht frei".
|
| One of the things the official devuan account retweets :
| https://twitter.com/jaromil/status/1544618996833583104 "It's
| 2022 and the master of systemd is now working for Micro$oft
| https://phoronix.com/scan.php?page=news_item&px=Lennart-
| Poet... this the last bit @phoronix omits. This is a classic
| cybernetic strategy: to become the master of a feedback loop
| you create and continuously adjust the framework in which
| nodes interact."
|
| I think that says enough about the sort of irrational people
| we're dealing with?
|
| People who hate systemd are very, very vocal, and highly
| unproductive.
| encryptluks2 wrote:
| I think that is an overstatement. I use systemd but there
| is legitimate criticism and even a questionable conflict of
| interest in the creator now working for the competition.
| People working against the best interest of the community
| is a real threat that shouldn't simply be ignored. However,
| so far systemd has worked out alright for me so I can't
| complain too much but the documentation is still lacking in
| certain areas and so doing things that are easy to
| understand with a traditional script based RC can become
| frustrating when you are trying to figure out the systemd-
| way to do things.
| SahAssar wrote:
| > creator now working for the competition
|
| Microsoft hasn't been the competition for while. They
| might not be "part of the team", but they definitely have
| more to win by linux being alive than dead. I'd put them
| more along the lines of IBM or Oracle, huge corps trying
| to somewhat discreetly steer linux in a path that suits
| them.
| [deleted]
| UI_at_80x24 wrote:
| >Except for alpine, all of them are extremely niche, half
| of them are dead, the other half barely have enough people
| to stick around for a release a year.
|
| FreeBSD & OpenBSD would happily disagree.
| cultofmetatron wrote:
| Those aren't linux distros
| tkuraku wrote:
| Seems pretty great to me. Never understood the hate.
| nomel wrote:
| I was sold after a single session of writing a couple of
| dependent services. Logging, retries, cleanup. Everything
| was so ridiculously straightforward, rather than a bunch of
| bash hacks and lock files.
|
| I have trouble believing that people who loath it so much
| have actually sat down to read the documentation.
| zargon wrote:
| > bedrock of delight
|
| It might be sarcasm?
| [deleted]
| fuckstick wrote:
| It's not generally hated. It has a cadre of permacritics that
| are very vocal and often dramatic, and some of them often pop
| up in threads such as this one, that is all. It's especially
| pathological since there are alternatives - if you hate
| Lennart, Redhat or whatever, use something else and move on.
|
| Meanwhile millions are using it to get shit done without much
| drama. It's been years since I filed a bug on systemd, but
| that's what grown ups do when inevitable bugs are
| encountered, not make themselves and everyone miserable
| because they deeply integrated some dubious 1970s Unix
| philosophy into their personality.
| plaguepilled wrote:
| I would say it really depends on the context!
|
| Some reasons systemd is bad:
|
| - Its a "big" for small docker containers (which is part of
| why a lot of people like Alpine Linux).
|
| - It produces binary logs, which might not work with your
| workflow and is a kind of vendor lock-in if you don't script
| a binary-to-text script.
|
| - the binaries are all a lot bigger in terms if SLOC and in
| terms of storage space than the solutions they replace. This
| makes auditing the code more of a chore and is a big argument
| against it in certain security environments.
|
| - (my main gripe) systemd produces vendor lock-in from
| seemingly unrelated apps. A lot of packages which indirectly
| depend on a systemd functionality need to be patched to work
| on OpenRC Gentoo, for example.
|
| Some arguments for systemd:
|
| - systemd abstracts process management. This can be fantastic
| for scripting and security (again, context dependent)
|
| - systemd by default kills services on log out (which is
| great for desktop - but can be an obstacle for servers). This
| is a good default behavior from a security perspective.
|
| - systemd has some parallelization of init, making start up
| more predictable (because something falling over is less
| likely to nuke the whole procedure - again good for desktop)
|
| - systemd provides a lot of tooling to stop you doing things
| the "wrong" way. For example, systemd-analyze-security
| provides configuration tips to harden your system
|
| ==========
|
| In general, I would say that systemd is a very impressive
| tool and helped a lot of distributions standardise how they
| handle boot. I wish it did not impact downstream development
| the way it does though.
| panick21_ wrote:
| You can easily have it not produce binary logs.
|
| Other software depending on Systemd isn't really Systemd
| responsibility. Its not systemd fault that almost nobody
| uses OpenRC.
| denton-scratch wrote:
| > You can easily have it not produce binary logs.
|
| How do you do that? If you want non-binary logs, you can
| have journald tee log records to rsyslog; but the
| canonical log is still the binary log. Have I missed
| something?
| WastingMyTime89 wrote:
| What does canonical log even means here?
|
| Systemd will produce logs in its own structured
| representation and write them straight away as plain text
| in the logger of your choice. For all intent and purpose,
| you now have text logs.
| denton-scratch wrote:
| What I meant by "canonical" is that you can't get rid of
| the binary log; you can pipe it into a database, or a
| textfile, or /dev/null, if you want, but that database or
| textfile is transcoded copy of the binary log.
| ecnahc515 wrote:
| That's not true, you can configure journald to be in-
| memory only in which case there's no binary log, no file.
| If your using systems, you can't really git rid of
| journald, but you can get rid of the binary logs.
| denton-scratch wrote:
| I wasn't aware of that. Can you make the memory usage
| arbitrarily small?
| WastingMyTime89 wrote:
| Every log ever is a transcodification of a system state.
| What difference does it actually make that it is emitted
| into systemd structured format before being put into your
| logger?
|
| Seems like a pointless complain to me. It's arguing for
| the sake of it.
| denton-scratch wrote:
| Oh, I didn't complain. I know better than to come to HN
| and complain about systemd.
| plaguepilled wrote:
| I think its a bit of systemd's issue since it's
| attempting to cover a large range of functionality. The
| way it provides that functionality is important.
|
| Re: the binary logs - true, but the core point that its
| not text by default is still a (small) issue IMO. Not
| ideal default behaviour.
| gupnop wrote:
| There are solid technical reasons for systemd's binary
| logging.
|
| The nice thing about its binary log format is that it's
| organised by fields which are indexed for quicker
| searching and filtering. It's much easier and faster to
| analyse these logs than the traditional text-based ones.
|
| Also, having journald authenticate the process that is
| sending it log entries, and the log sealing capability,
| are two features that can help guard against log
| tampering.
| cesarb wrote:
| For me, the nice things about the systemd journal binary
| log format are:
|
| - It's immediately compressed (without having to wait for
| a log rotation);
|
| - It automatically rotates when a size limit is reached
| (no risk of filling the disk with logs);
|
| - IIRC, it's deduplicated (repeated messages use less
| disk space).
|
| All of these together means logs can be kept for much
| longer by default.
| panick21_ wrote:
| Overall agree. The only problem is if you have file
| corruption it could be a problem to parse. But I usually
| don't change the default.
| denton-scratch wrote:
| Rsyslog can be configured with a database backend, if you
| want to index the log fields.
| UI_at_80x24 wrote:
| Being able to boot a server with a 'live USB image';
| mount root, and inspect the logs to see what happened are
| not possible when you got a binary blob for a log. When
| things have really fucked up, you need the 'ease of
| access that plain-text log files provides.
| fsh wrote:
| If your live USB image is from this decade, it will
| almost certainly come with journald for reading the logs.
| If it doesn't, why choose such a bad live USB image?
| cesarb wrote:
| Just nitpicking, but AFAIK it's not journald which is
| used to read the logs, it's journalctl itself which
| directly reads the binary logs from the filesystem (and
| the normal filesystem ACL permissions are used to allow
| or deny reading the logs).
| awruko wrote:
| > indexed for quicker searching and filtering
|
| I think I am not the only one who is missing negative
| filters - check the log excluding audit messages.
| kaba0 wrote:
| > It produces binary logs, which might not work with your
| workflow and is a kind of vendor lock-in if you don't
| script a binary-to-text script
|
| I never really understood this point -- it's not some
| proprietary format that has to be reverse engineered, you
| quite literally has both encrypt and decrypt source code
| available for every single version it has been released.
| You can also just pipe the binary output through the
| provided "decrypt" tool and then further use the usual unix
| tools if you wish.
|
| But let's add the advantages of this logging: systemd can
| log events from the very start of the boot process, which
| was not possible before.
| ecnahc515 wrote:
| And you don't need journald to read the log files either,
| you can use `journalctl --file /path/to/file.journal` to
| read them directly via `journalctl`.
| WastingMyTime89 wrote:
| It's even more difficult to understand when you consider
| than text files are themselves binary logs and given how
| many encoding they can have they are not even trivial
| ones.
|
| People should just call systemd logs structured rather
| than binary because that's what they are. Sure it means
| you need a shim if you want to view them as plain text
| but it's not like we are talking about some unfathomable
| complexity here.
| ayushnix wrote:
| > But let's add the advantages of this logging: systemd
| can log events from the very start of the boot process,
| which was not possible before.
|
| From what I've seen using Alpine Linux for a few weeks on
| my Raspberry Pi, logs are written to /var/log/messages
| after the init process starts and launches the logging
| service. All logs before the init starts can be retrieved
| using dmesg? I'm not sure about this though, let me know
| if I'm wrong.
|
| One of the things I haven't figured out yet is if
| traditional logging systems can easily do advanced log
| filtering like showing only logs from the current boot
| (like -b in systemd), previous boots (-b -1), and showing
| logs after a specific date and time (--since).
| UI_at_80x24 wrote:
| >One of the things I haven't figured out yet is if
| traditional logging systems can easily do advanced log
| filtering like showing only logs from the current boot
| (like -b in systemd), previous boots (-b -1), and showing
| logs after a specific date and time (--since).
|
| I manage this with clever usage of grep. You are correct
| in that there isn't a single --flag that will only show
| me those specifics.
| ayushnix wrote:
| > I manage this with clever usage of grep. You are
| correct in that there isn't a single --flag that will
| only show me those specifics.
|
| I can grep my way through text logs as well but being
| able to get logs for different purposes using --flags is
| better user experience. I can always resort to to using
| grep, sed, and awk if I want to when using journald but
| the loss of these quality of life features make it hard
| for me to consider using a distro that does not have
| systemd.
| gizzlon wrote:
| - It's also "big" in the sense that it's all-encompassing
| and hard to replace
|
| - It makes alternating between systems harder because so
| much is Linux + Systemd specific.
| yjftsjthsd-h wrote:
| > Its a "big" for small docker containers
|
| Aside size, last I looked it required a lot of hoop-jumping
| to get systemd to run inside docker at all.
| RealStickman_ wrote:
| Iirc using systemd in Podman is much easier.
| klodolph wrote:
| I think the idea of running systemd inside docker (or
| vice versa) is a little redundant to begin with--systemd
| and docker share a number of features.
| yjftsjthsd-h wrote:
| It's unusual, but there are occasionally times when it's
| nice to run multiple processes in one container, and a
| proper service manager would be useful. Usually I see
| supervisord used for that kind of thing in practice.
| erik_seaberg wrote:
| nohup is POSIX, systemd is decidedly not. That makes it
| systemd's responsibility not to break nohup, and more
| generally not to require non-admin users to be aware of it.
| plaguepilled wrote:
| Not sure I fully understand this argument. Can you
| expand? I'm not familiar with nohup and its role.
| erik_seaberg wrote:
| https://pubs.opengroup.org/onlinepubs/9699919799/utilitie
| s/n... blocks SIGHUP and captures output in a file. That
| lets me type nohup ./long_batch_job.sh &
|
| and walk away, knowing that it will keep running after my
| shell exits and the controlling terminal is lost.
|
| systemd broke that at some point, for no obvious reason.
| I think there is some nonstandard route to make systemd
| run something in the background, but end users shouldn't
| need to talk to init.
| lrvick wrote:
| Today you still have this functionality as an
| unprivileged user via systemd --user units in .config.
| Unlike nohup you get proper logging and processes can
| even restart automatically on reboot if you want.
| xdfgh1112 wrote:
| They broke tmux too:
|
| https://superuser.com/questions/1372963/how-do-i-keep-
| system...
|
| Systemd does a lot of good but they like to move fast and
| break things. Making tmpdir per process, their homedir
| changes etc are all good for security but tend to break
| things in unexpected ways
| dinosaurdynasty wrote:
| They've never done tmpdir per process... There's a
| PrivateTmp option for services, but that has to be
| enabled explicitly
| teddyh wrote:
| Unix traditionally has never had proper seat and/or
| session management, with all the chaos this entails. With
| systemd, they added it. You're effectively proposing that
| systemd (or anything else) should _never_ implement
| session management. The most reasonable solution seems to
| me to be that nohup is instead adapted to do the
| semantically correct thing and tell systemd in the modern
| way that it should run the nohup command in a detached
| session.
| WastingMyTime89 wrote:
| > The most reasonable solution seems to me to be that
| nohup is instead adapted to do the semantically correct
| thing and tell systemd in the modern way that it should
| run the nohup command in a detached session.
|
| That was proposed to nohup when systemd introduced the
| modification. It's what nohup does on macOS.
|
| A very productive discussion was happening but then the
| anti-systemd mob showed up with pitchforks, brigaded the
| discussion on the bug tracker and made sure nothing good
| would come out of it.
|
| That's when I personally decided Linux was a lost cause
| and definitely switched to macOS.
| erik_seaberg wrote:
| I'm guessing you don't mean setsid(2), but when you say
| "seat and/or session management," what does that mean
| concretly? Why should init be involved instead of
| something under the user's control?
| teddyh wrote:
| systemd-logind(1) manages user sessions. If you want to
| replicate the functionality of what "nohup" used to give
| you, I am reliably informed that "systemd-run --scope
| --user $command" does the right thing. Or, you can enable
| it permanently for your user with "loginctl enable-
| linger".
| erik_seaberg wrote:
| When I see "manages user sessions," I don't know what
| that phrase means. What is a "session" (again assuming
| not a POSIX session leader) and what are we concretely
| doing to "manage" it?
|
| Is there a guide that explains the bare minimum that
| typical end users need to know to stop systemd from
| breaking use cases that have worked for years? I would
| never expect a non-sysadmin to have read the "systemd-
| run" or "loginctl" manpages or know how to find them. I'm
| a nerd and even I don't know how to get to the point of
| understanding what https://man7.org/linux/man-
| pages/man1/systemd-run.1.html is trying to tell me.
| teddyh wrote:
| I mentioned systemd-logind. Its manual page systemd-
| logind(8) states1: "See sd-login(3)2 for information
| about the basic concepts of logind such as users,
| sessions and seats.".
|
| 1. https://manpages.debian.org/stable/systemd/systemd-
| logind.8....
|
| 2. https://manpages.debian.org/bullseye/libsystemd-
| dev/sd-login...
| kaba0 wrote:
| How is systemd not under the user's control? It is an
| init and service management system and long-running
| processes are services. Where else should it be managed?
| Systemd is the only component that knows whether you are
| logged in/out, whether you still have another seat open,
| etc. And its responsibility is to properly close
| resources, and not let unannounced processes to linger
| needlessly in the background.
| kaba0 wrote:
| Nohup is a disgusting hack from a previous century. I
| don't see how having less information on what is
| happening to a process good -- nohup interprets
| supposedly meaningful signals never meant for this misuse
| differently.
|
| If you want to continue to run a process you have to
| start a service which is exactly that.
| Nursie wrote:
| No, I don't have to do that at all, I can in fact use the
| standard unix way of making a process not terminate on
| SIGHUP by telling it to ignore SIGHUP.
|
| SIGHUP is not a signal to shut down, it's a signal that
| says the controlling terminal is gone. The action taken
| by the process at that point is the decision of the
| process and the user that launched it, not the init
| system. This is _exactly_ what it is for.
|
| Changing that without understanding what people used it
| for across UNIX vendors for decades, was dumb. And it
| showed off just how little the writers of the service
| knew about how users actually use their systems. Huge red
| flag.
|
| It's not just random long-running batch jobs it killed
| either, it seems that it would kill all sorts of useful
| stuff people run for reliability. The irony of the init
| system killing screen/tmux sessions which people run
| specifically to keep their shell going in case of a
| disconnect!
| kaba0 wrote:
| >And it showed off just how little the writers of the
| service knew about how users actually use their systems.
| Huge red flag.
|
| Why do you assume they didn't know about this quite basic
| mechanism? They added 2 configuration options, one at
| compile time (to set the default) and another
| configurable by the user. In fact, distro maintainers
| didn't look up what it did and they just compiled it as
| is, resulting in the surprising behavior of killing
| lingering processes.
|
| Also, it is an init and service management system and
| long-running processes are services. If you want to run
| something for "reliability" you should create a service
| for it, or just run the command with "systemd-run", to
| properly communicate with the responsible process manager
| what it supposed to do when the user logs out (and to
| actually make it reliable, e.g. you can then set it to
| auto-restart on failure, etc) Safely killing lingering
| processes and cleaning up after them is the correct
| default behavior, so systemd just tries to enforce that -
| they actually communicated with nohup maintainers to
| optionally add this systemd communication, so that "nohup
| whatever" would still work, but they were not open to it.
| grepLeigh wrote:
| I've developed a distrust for anyone who hates on systemd in
| 2022, especially if their rationale is vague dogma like "it
| does more than 1 thing, it's not Unix-like!"
|
| It's usually a signal that the person is not a practioner.
|
| Systemd is the most important and well-developed Linux
| framework, besides the Linux kernel itself.
| traverseda wrote:
| I mean have you actually used the alternatives? I find most
| of the people with that opinion are young pups who jumped
| on the linux train after most of the systemd bugs have been
| ironed out, but who still have zero experience with the
| alternatives.
| lrvick wrote:
| I have used all the alternatives, and written my own init
| systems from 0.
|
| Systemd is really well designed and makes Linux
| workstation use predictable and more secure across
| distros in numerous ways. You can have any service you
| want now, even xorg/ wayland, as an unprivileged user. It
| basically removes all need to use root if used correctly.
|
| Systemd however is however not designed for server use,
| but neither is OpenRC or any of the alternatives. Servers
| filesystems should contain a kernel, a shim init binary,
| and a static binary for a target service.
|
| When you want to upgrade your fleet you compile a new
| bundle of those three things into a new filesystem image
| and boot servers from the new image.
| traverseda wrote:
| I mean it's pretty hard to debate the merits of systemd
| as a server init system when you think we should all be
| using come kind of containerization system :p
| lrvick wrote:
| I did not say anything about containers.
| traverseda wrote:
| One service per server? That seems incredibly wasteful.
| lrvick wrote:
| One service per kernel. Hypervisors allow you to run many
| kernels on the same physical hardware.
| iotku wrote:
| Feigned certainty is often a indication of the opposite. In
| many cases people just absorb someone else's opinion on
| topics just in an effort to feel informed.
|
| I'm not going to say I'm never guilty of it myself, but
| often asking even for the slightest bit of further
| explanation collapses that or otherwise just leads to
| repetition.
| Jach wrote:
| I don't trust anyone's opinion, for or against, unless
| they've used alternatives. I've used systemd, I'll probably
| use it again, and I'll keep hating on it if someone gets me
| started. Fortunately on my own systems I've been a happy
| OpenRC user instead.
| grepLeigh wrote:
| My S/O is a Gentoo maintainer so this comes up often in
| my household!
| Jach wrote:
| As a longtime user I thank your S/O, you're lucky to have
| them!
| boudin wrote:
| I've used both (OpenRC and systemd). I like the
| simplicity of OpenRC and still uses it on a few servers
| running on Gentoo, but on a laptop/desktop I think
| systemd is a better fit, having user services with user
| level logging for example.
| agumonkey wrote:
| It started with bad press because author made pulseaudio and
| its design didn't appeal to many (lots of features but
| missing pieces, not due to dev but market forces and
| drivers). So when the same guy says he's gonna rewrite pid1
| with a radically different design people went ballistic.
|
| My personal opinion is that proper dependency based init
| systems are amazing but I'm not fond of some slightly
| superficial aspect of systemd (syntax, parameters, logic,
| config files).. to the point I think in a few years someone
| may make a cleaner variant.
| UI_at_80x24 wrote:
| On my laptop, systemd is awesome; I love it. Everything works
| together nicely. On my servers, systemd gets in my way, tries
| to do too many things, and gets in my way more then it helps.
|
| On a laptop things are much more dynamic. From
| sleep/hibernation/wifi-LAN-wifi (+/- VPN) switching/etc....
| these fiddly bits were much harder to manage on Linux for
| DECADES then they are now. The reboot interval on laptops is
| huge compared to servers. An init system (plus all the extra
| plumbing) work well together.
|
| On servers however; I HATE systemd. For logging, networking
| (and DNS) alone systemd wastes so much more of my time and
| gets in my way. I think the need for an 'improved' init
| system was always a red herring. I've never had a service
| race-condition, or other conflict that didn't take more then
| 10 minutes to fix in the 30 years I've managed *nix servers.
| There was one time where I was stumped why my VPN server kept
| failing to start at boot but came up fine if I restarted
| manually. My dyslexic ass inverted the script number (ie. 13
| instead of 31 or something like that). That was just a face-
| palm embarrassment.
| lrvick wrote:
| Systemd should never be used on a server. Or any other
| desktop init system for that matter.
|
| Production systems should never be changed or administered
| in place, only replaced. Servers should be immutable
| appliances. They do not need a package manager, or systemd,
| or ssh, or even a shell. Such things are developer tools
| and only belong in development environments like
| workstations.
|
| A production filesystem should contain a kernel, an init
| binary, and either a container runtime or a static binary
| of your target application. At most a production init
| binary just needs to setup virtual filesystems and be a
| reaper for a target application binary.
| terom wrote:
| By a vocal minority.
| oconnor663 wrote:
| It's one of those things where people who hate it talk a lot
| about that, but people who like it don't have much to say.
| ruuda wrote:
| There are two types of software: those that everybody
| complains about, and those that nobody uses.
| esarbe wrote:
| Absolutely.
|
| I've started managing my user services using systemd --user and
| portable services and it's just amazing how well the individual
| components work together to create fully isolated,
| containerized, per-user services.
|
| I'm lovin' it and I'm not missing the hot mess of the dozens of
| shell scripts that I needed before.
| conradev wrote:
| From an outsider perspective these stick out to me as most
| important:
|
| - Unified logging subsystem
|
| - On-demand launching, memory limits, and general resource
| management
|
| - Advanced security features, i.e. sandboxing, DynamicUser
|
| - Well thought out and implemented given the constraints (feels
| like Linux quality)
|
| In general it represents a shifting of code from daemon
| developers (who previously handled daemonization themselves) to
| the system.
|
| On-demand launching is good for performance: work can be
| deferred from boot and inactive daemons can be stopped. This is
| critical on battery and RAM constrained devices
| okasaki wrote:
| I had to chattr +i /etc/resolv.conf because my resolv.conf
| would keep getting truncated (as in empty) every time I
| restarted an lxd container. Rock solid my ass.
| chris_wot wrote:
| How is that a systemd issue?
| tyingq wrote:
| systemd-resolved
| encryptluks2 wrote:
| Never had this issue. Sounds like they need to recreate
| the symlink.
| tyingq wrote:
| It apparently needs specific tweaking for lxd: https://li
| nuxcontainers.org/lxd/docs/master/howto/network_br...
| lmz wrote:
| Maybe I'm wrong, but that just seems to show that if you
| want to resolve lxd domains (hostnames?), you need to
| inform systemd-resolved to ask lxd for those domains,
| which is... sensible?
|
| > you should notify resolved of the domains that LXD can
| resolve
|
| You'd have the same issues if you replaced systemd-
| resolved with e.g. dnsmasq. Split DNS always needs
| resolver configuration.
| tyingq wrote:
| I think it's just someone unhappy that they used to be
| able to edit resolve.conf before systemd-resolved took it
| over. I recall being annoyed about it as well, but that
| was some time ago.
| dsr_ wrote:
| Other direction: people used to feel secure that nothing
| was going to edit resolv.conf away from what they set up.
| lmz wrote:
| It was always a contended file, before systemd e.g.
| https://wiki.debian.org/resolv.conf names _two_ software
| packages (choose one) to manage that file.
| tyingq wrote:
| >It was always a contended file
|
| For people using dhcp, yes. The surprise of systemd-
| resolved was it taking over the file on a typical server
| that didn't use dhcp.
| boudin wrote:
| lxd is not part of systemd.
| Avamander wrote:
| Why is lxd touching that file?
| tsujamin wrote:
| +1 for systemd-networkd too: it let me declaratively describe
| some netns/ipvlan interfacing the other day that netplan et al
| simply couldn't.
|
| It could use with some more netns awareness but its pretty
| great at the current stage
| normaler wrote:
| systemd-networked + systemd-resolved is also really awesome.
|
| It lets you configure DNS Server per link and resolve only
| certain domains via a specific DNS Server configured from a
| link.
|
| e.g. multiple customer specific wireguard Tunnels that
| resolve the specific project related domains, but dont
| resolve all your other DNS.
| Avamander wrote:
| You can still let netplan use systemd-networkd as the
| renderer, though in some cases some overrides are necessary.
| pluijzer wrote:
| ...the year of the Linux Desktop
|
| I keep wondering about this year of the Linux Desktop. So often
| I see it used as a snide towards Linux users (not by you). I
| think it shows naivety.
|
| What does it mean? Is it about having a stable easy to maintain
| and full featured Linux Desktop. I really do think we have
| reached that point. Especially now that many workflows have
| moved to the web I am having a hard time coming up with use
| cases for which Linux would really not be suited. Even gaming
| has become very viable.
|
| Or does it mean that Linux for overtake the market share of
| Windows and macOS. For that I would caution to be careful about
| what you wish for. Being an underdog brings an added benefit of
| having more flexibility and the option to think outside of the
| box. For Linux to overtake Windows it would slowly turn into
| Windows itself in my opinion.
| AnIdiotOnTheNet wrote:
| > Is it about having a stable easy to maintain and full
| featured Linux Desktop. I really do think we have reached
| that point. Especially now that many workflows have moved to
| the web I am having a hard time coming up with use cases for
| which Linux would really not be suited. Even gaming has
| become very viable.
|
| Damning with faint praise. The success of Linux gaming is due
| to the efforts of projects that re-implement Windows APIs,
| and things moving to the web are obviously not targeting
| Linux either.
| tapoxi wrote:
| I'd argue the success of the Steam Deck is evidence of the
| Linux desktop's maturity. The normal game UI is just another
| Wayland session, and it's a fully functional PC running Arch
| Linux. KDE is installed and easily accessible.
| fullstop wrote:
| It's also worth mentioning that the Steam Deck uses systemd
| as well.
| AnIdiotOnTheNet wrote:
| I'd say the success of the Steam Deck is a testament to the
| maturity of the Windows API[0]. Old enough and reliable
| enough that it is a better target for games on Linux than
| Linux Desktop's own shit show.
|
| [0] and of course the efforts of the WINE project and proton.
| tristanbvk wrote:
| qbasic_forever wrote:
| I wish Windows ran systemd--seriously. Windows services and low
| level functionality is just a hot mess of cruft, decade plus
| old UI and configs, etc. Please jettison it all and give a
| consistent declarative way to manage it all like systemd does
| for Linux.
| cat_plus_plus wrote:
| Yeah, imagine if Windows was made up of many simple and
| interchangeable components for which alternatives were easily
| available from sources other than Microsoft? Don't like
| services? Choose among half a dozen alternative background
| process management options, without affecting logging or file
| system layout, or listening to inbound network connections...
| pjmlp wrote:
| Yes, because it has been such a success conquering the
| desktop workloads.
| lrvick wrote:
| You can run virtually any Windows application on top of
| Systemd already via Wine.
|
| Unless you have some particular attachment to the NT kernel,
| there near zero reasons to use Windows today.
| dTal wrote:
| If only that were true. "Virtually any Windows application"
| is a fantasy I'm afraid, many important applications run
| poorly or not at all on Linux. Then there's the "particular
| attachment to the NT kernel" caused by driver support for
| $HARDWARE - there's tons of niche hardware that just can't
| be driven from Linux.
|
| If you use a computer for actual industrial _work_ , you
| will hit one of these problems _very_ quickly.
| lrvick wrote:
| Can you give an example? Even modern AAA games run as
| well, and often better, on Linux these days.
| blueflow wrote:
| "rock-solid".
|
| Right now my mom is nagging me to fix her Ubuntu laptop, which
| doesn't shutdown anymore because some of the units got messed
| up. I'm at the verge of telling her to install windows.
| encryptluks2 wrote:
| That is a really simple fix. Sounds like one of the units is
| hanging. This actually shouldn't prevent shutdown but may
| make it hang for like 2 minutes.
| Scarbutt wrote:
| Alpine linux seems to be doing fine without systemd.
| stevefan1999 wrote:
| But I almost never saw anyone using Alpine as the
| infrastructural distro for their, say like desktop
| environment akin to Manjaro and Fedora. Without systemd,
| bootstrapping a complicated desktop environment would be a
| hot mess.
|
| Well, maybe you would say Alpine is not intented to run
| heavyweight stuff like that and is mostly focused on security
| and containers.
|
| That's exactly what Alpine is, the OpenBSD of Linux distros.
| OpenBSD likewise cannot be used as your production powerhouse
| as well.
| HNDV wrote:
| >never saw anyone using Alpine as the infrastructural
| distro for their, say like desktop environment akin to
| Manjaro and Fedora
|
| Alpine runs musl libc. This makes it buggy with all sorts
| of software that rely on glibc-isms, that makes it
| incompatible with proprietary drivers like NVIDIA and make
| it harder to run proprietary/binary software on the
| userland.
|
| musl is developed by people with that sort of break-
| everything attitude :
| https://twitter.com/RichFelker/status/994629795551031296
|
| There is a world of pain that awaits anyone with the
| expectation that this sort of distro could be used on a
| workstation.
|
| Musl is really meant to be run.. with software vetted by
| communities like https://suckless.org/
|
| Meaning things like dwm, dmenu, st.
|
| Which may or may not be one's cup of tea. It certainly
| ain't mine.
| blueflow wrote:
| Bad argument, glibc and musl are not always compatible,
| and you can use that as argument against either. When it
| comes to standards, musl is actually the more conformant
| one.
|
| The glibc 2.26 release with the ucontext breakages made
| me stick with musl.
|
| Plus, when i did multiarch support in Alpine later, i
| found that LDSO paths for musl are much more
| systematically and don't have name collisions like glibc.
| WastingMyTime89 wrote:
| Musl is mostly a good libc.
|
| There are some very unfortunate ideological choice made
| by its author but they are not the one you quote. The
| reluctance to give developers a way to detect Musl from C
| code would be a better exemple. It's both annoying and
| counterproductive.
| biorach wrote:
| That's an inaccurate and quite uncharitable
| representation of what musl is about.
| blueflow wrote:
| Now you do! I'm writing you right now from a Alpine Laptop.
|
| > Without systemd, bootstrapping a complicated desktop
| environment would be a hot mess
|
| startx on tty1, i3 being launched from xinitrc. Same
| procedure that i use on any other distro or BSD.
| cultofmetatron wrote:
| alpine linux is a minimalist distro intended for running a
| single process within a container. I guarantee the base OS
| the container is running on us running systemD.
| gizzlon wrote:
| No: _" Alpine Linux is an independent, non-commercial,
| general purpose Linux distribution designed for power users
| who appreciate security, simplicity and resource
| efficiency._"
| cultofmetatron wrote:
| who out there is using alpine as their daily driver
| desktop? the only time I've ever seen it used is as the
| base image for docker containers precisely because its so
| minimal (ie: lower attack surface area)
| kosolam wrote:
| I use systemd and I like it. Because it works. Every question
| that pops up I can easily find the answer by googling.
| gorgoiler wrote:
| It feels like the time is ripe for something simpler and more
| modern to replace* systemd. The timing of this release coincides
| with me being bitten with _yet another_ bug** on the weekend.
|
| How long until "Systemd: The Good Parts"?
|
| *The most trivial new name would be _systeme_ which would at
| least be in keeping with the French naming.
|
| **In Debian stable if you create a new user, ssh in as that user,
| logout, then delete the user, you can't because systemd is still
| running a detached housekeeping process as that user. If you wait
| a bit then the systemd process goes away but that, to me, makes
| it a worse bug not a better one.
| dark-star wrote:
| Wait, what French naming?
| seszett wrote:
| I don't know if it was intended, but "systeme D" in French
| means hacking together something with whatever you have
| available. D meaning "demerde" (literally getting out of shit
| or a shitty situation) or "debrouille" depending on the
| language registry you want.
|
| It's a rather common expression.
| dark-star wrote:
| ah, that makes sense, thanks for the explanation.
| justsomehnguy wrote:
| Funny tidbit, sure. Basically "[made] from shit and
| sticks".
| mekoka wrote:
| "e" following "d" in the alphabet, the successor to systemd
| would be called "systeme", which is the french translation
| (systeme) for "system".
| dark-star wrote:
| Thanks, but I was refering to the "...in keeping with the
| French naming" part, as if systemd previously had a french
| name or something
| lotharcable wrote:
| > It feels like the time is ripe for something simpler and more
| modern to replace* systemd.
|
| Well then do what Poettering did and write it.
|
| It's threads like this why I am eternally grateful that Linux
| kernel uses a merit driven approach and not concessus driven
| one.
| Shorel wrote:
| Ubuntu had the alternative software called Upstart.
|
| It was killed because of the Red Had power behind Systemd.
|
| Technically, I don't know which one is better, but
| politically, Systemd was a power move by Red Hat.
| traverseda wrote:
| Yeah, but Redhat has been slowly getting control of more of
| the infrastructure. Want to make your own? Well even if you
| make something backwards compatible with Gnome or udev, get
| popular and they will probably find some way to break your
| compatibility.
|
| You end up needing to fork all the projects that Redhat has
| gotten their tentacles around.
| kasabali wrote:
| > Well then do what Poettering did and write it.
|
| This is such a superficial and ignorant take I'm having hard
| time forcing myself to believe it was written in good faith.
|
| Dozens of alternatives already exist. The problem isn't
| writing, problem is having politicial power Poettering had.
| (ie. He was employed by Red Hat and had close connections
| with other Freedesktop developers.)
| rainbow29822 wrote:
| That isn't "political power" it's called knowing your
| audience and knowing what they want. The audience here is
| Linux distribution upstreams who also participate in
| Freedesktop. The other alternatives had ample time to talk
| to these people and copy the features of systemd and
| improve on them but they refuse to do it. They seem more
| interested in building for their own niche use cases and
| ignoring everyone else. That's their decision, they can't
| say it's anyone else's fault.
| cies wrote:
| I expect there will be a system that is not necessarily less
| complex (as what systemd does IS quite complex); but is more:
|
| * safe (uses Rust with unsafe)
|
| * modular (systemd is pretty all-or-nothing)
|
| * open access (less RedHat dominated)
|
| Probably it will be using some of the same standards as systemd
| or at lease be BW compatible to some extend. Once Debian picks
| it up, it's game over systemd.
| HeckFeck wrote:
| It happened for PulseAudio, perhaps something compatible but
| leaner can emerge for systemd.
| phoronixrly wrote:
| It happened to Pulse after the project stopped being a moving
| target. Just look at the changelog of this systemd release.
| McDyver wrote:
| Just because the project is moving, doesn't mean it's
| moving in the right direction.
|
| What I like about linux in general, is that there are lots
| of small tools, with a reduced and specific scope, that do
| their job well. Systemd seems to want to do and control
| everything.
| ciupicri wrote:
| From the _logind.conf_ man page [1]:
|
| > KillUserProcesses=
|
| > Takes a boolean argument. Configures whether the processes of
| a user should be killed when the user logs out. If true, the
| scope unit corresponding to the session and all processes
| inside that scope will be terminated. If false, the scope is
| "abandoned", see systemd.scope(5), and processes are not
| killed. Defaults to "no", but see the options KillOnlyUsers=
| and KillExcludeUsers= below.
|
| > In addition to session processes, user process may run under
| the user manager unit user@.service. Depending on the linger
| settings, this may allow users to run processes independent of
| their login sessions. See the description of enable-linger in
| loginctl(1).
|
| > Note that setting KillUserProcesses=yes will break tools like
| screen(1) and tmux(1), unless they are moved out of the session
| scope. See example in systemd-run(1).
|
| [1]:
| https://www.freedesktop.org/software/systemd/man/logind.conf...
| gorgoiler wrote:
| Ahhh, thanks. Now you mention it, wasn't there some major
| scandal about this when it first shipped?
| Nursie wrote:
| There were a lot of noises made about it, yes, because
| people had been "nohup"ing things for decades, and using
| stuff like screen and tmux to keep sessions going over poor
| connections.
|
| All of a sudden, without much warning, someone made the
| decision to kill all user processes on logout. It broke a
| lot of folks workflow.
| Shorel wrote:
| One would be tempted to say that deleting a user and
| logging out are definitely different operations with
| expected different outcomes.
| SahAssar wrote:
| The "scandal" was the exact opposite of your complaint.
| People where SSHing in, starting a screen/tmux,
| disconnecting and complaining about the process being
| killed.
| PetitSasquatch wrote:
| Don't we already have multiple, alternate systems that are
| significantly simpler?
|
| The primary reason why I don't use systemd at all, on any
| desktop or server I manage, is not that I think it isn't
| powerful or reliable but, I cannot fit it into my head.
|
| The scope and complexity of it goes beyond what I'm personally
| willing to invest into any one subsystem designed to regulate
| my operating system.
|
| I find that because I can't easily integrate day to day systemd
| operations into my general knowledge of the Unix / Linux shell
| environment, it essentially creates a cognitive switching cost
| that I'm not willing to pay given the efficiency and utility I
| get from my existing knowledge and skills.
|
| Systemd seems to work well for a lot of people, but doesn't
| sell itself to me given my objective, and capacity, to
| internalize simpler tools for high levels of mastery.
|
| That's why I don't use systemd but do use other, more simpler
| systems, that are readily available.
___________________________________________________________________
(page generated 2022-11-01 23:02 UTC)