Systemd, ten years later: a historical and technical retrospective • Hacker News Board

Re: Systemd, ten years later: a historical and technical retrospective

#381

Post by oconnor663 » Mon, May 04, 2020, 4:25 PM UTC

majewsky wrote: post #279

oconnor663 wrote: post #98

Earlier quoted context omitted.

Have you tried `sudo loginctl enable-linger [username]`? This used to be well-documented, but I don't see much about it now. It's possible things have changed since the last time I had to deal with this?

What do you mean? I still see it in `man loginctl`. > enable-linger [USER...], disable-linger [USER...] > Enable/disable user lingering for one or more users. If enabled for a specific user, a user manager is spawned for the user at boot and kept around after logouts. This allows users who are not logged in to run long-running services. Takes one or more user names or numeric UIDs as argument. If no argument is speci…

Mainly I meant that I no longer see it recommended on the Arch wiki, which I think is where I first learned it. But it looks like that might be because Arch now compiles systemd with lingering on by default (or something similar to that, I'm probably using the wrong term).

Re: Systemd, ten years later: a historical and technical retrospective

#382

Post by astrobe_ » Mon, May 04, 2020, 4:30 PM UTC

bkor wrote: post #371

astrobe_ wrote: post #298

Earlier quoted context omitted.

Debian also ran a poll a few months ago in order to reevaluate that choice, at least partially. Quite the hint that all is not jimmy-dandy. As a programmer in embedded, Systemd feels like it solves problems we didn't have, and introduces problems we didn't have. I what point is it more conservatism than "if it ain't broken, don't fix it"? God only knows. Well, every time the Systemd topic pops on HN or Reddit (and ev…

Can you reference that poll? There was a GR, which is entirely different than a poll. The outcome of that was also pretty clear, Debian as a whole is ok to depend a bit more on systemd. I don't get why you use it as an example of the opposite. See https://lwn.net/Articles/808217/ for the outcome of the GR.

It is indeed this GR.

I might be misinterpreting the result, but "Systemd but we support exploring alternatives" means, to me, that there is some unhappiness here. To begin with, I believe the GR would not have happened if there was no issue to be discussed?

Re: Systemd, ten years later: a historical and technical retrospective

#383

Post by cycloptic » Mon, May 04, 2020, 4:33 PM UTC

TA0x0 wrote: post #376

cycloptic wrote: post #239

Earlier quoted context omitted.

If you already had that feature then you are free to use your 25-year-old solution instead of systemd.

You have to, since systemd implemented the feature incorrectly. You're missing the forest for the trees.

I've already been in a forest of bash scripts and I would not go back there again. I have no comment on systemd's implementation but the implementation you're talking about is also incorrect. It has never been safe to kill random processes using a bash script running in the background, on most Unixes (and Linux) it is 100% impossible to do that without race conditions due to the limitations of procfs. Doing "ps | grep" and "killall" is a footgun. You would need to implement this in C for it to have a chance of being safe at all, and even then, you would need to rely on system-specific functionality because there is no portable way in POSIX to actually do this.

Re: Systemd, ten years later: a historical and technical retrospective

#384

Post by secabeen » Mon, May 04, 2020, 4:34 PM UTC

dijit wrote: post #339

saati wrote: post #308

Earlier quoted context omitted.

If you actually care about your logs you should log to a centralized service anyway, and if any of your computers actually ran out of disk space you should fire your sysadmins/sres for incompetence.

This comment denotes, strongly, the dissonance that occurs when talking about something so general. It’s my opinion (as an infrastructure type) that centralised binary logging is an absolute necessity above 20 instances. But that leaves out every person with a laptop, or those people with a very low volume of little instances. Structured logging is difficult, that’s why logstash is so flexible about input and convers…

> This comment denotes, strongly, the dissonance that occurs when talking about something so general.

> It’s my opinion (as an infrastructure type) that centralised binary logging is an absolute necessity above 20 instances.

> But that leaves out every person with a laptop, or those people with a very low volume of little instances.

Yep, it also leaves out people on embedded hardware, and on devices that are in remote locations without access to the Internet, or in a car, or on metered Internet, etc. It's hard to hold in your head just how broadly Linux is used these days.

Re: Systemd, ten years later: a historical and technical retrospective

#385

Post by vidarh » Mon, May 04, 2020, 4:36 PM UTC

throw0101a wrote: post #367

vidarh wrote: post #255

Earlier quoted context omitted.

Or you opt to not encrypt your home separately. But how large a proportion of machines do you think have mail delivery rely on .forward or .procmailrc in $HOME these days? In any case, procmail can be executed directly rather than from .forward in most cases, and can be configured to take the rc file to be a file in /etc/procmail-rcs/ as an alternative to $HOME/.procmailrc (at least the version of procmail in Ubuntu;…

> But how large a proportion of machines do you think have mail delivery rely on .forward or .procmailrc in $HOME these days? I help run a 500 node HPC cluster that leverages procmail. Do I count? > User crontabs on my system at least (Ubuntu) are in /var/spool/cron/crontabs/[username], not in $HOME anyway. The crontab(5) may be there, but where is the script that is actually executed? Probably in $HOME/scripts/ or s…

> I help run a 500 node HPC cluster that leverages procmail. Do I count?

You do, but you're a tiny minority, and as noted /etc/procmail-rcs/ provides an alternative to putting them in /home. If that doesn't work for you, all you need is to not configure encrypted home directions and nothing changes.

> The crontab(5) may be there, but where is the script that is actually executed? Probably in $HOME/scripts/ or some such.

So don't configure encrypted home directories, then. Nobody is forcing you to enable it. Or you can provide an alternative location, and let your users protect their data better and still be able to use cron jobs. It does not take any flexibility away from you, but it adds capabilities for those who want them.

> I have daily experiences indicating otherwise. I would hazard to guess that many other syadins in academia & research would agree. Even assuming $HOME is in /home breaks a bunch of stuff:

Your experiences with systems that are fine with accessing $HOME does not mean that there aren't plenty of systems where it has been an issue, hence why plenty of software supports alternatives.

Your point of not assuming $HOME is in /home is irrelevant to this issue. The point is that software have had to deal with a subset of users with setups where a users home directory is not necessarily accessible when the user is not logged in for many years. As such most software has options to avoid relying on a users home directory being present already, which reduces this to a relatively simple choice of whether or not you consider the ability to encrypt home directories to be worth making those changes for.

Re: Systemd, ten years later: a historical and technical retrospective

#386

Post by vidarh » Mon, May 04, 2020, 4:37 PM UTC

jcynix wrote: post #344

vidarh wrote: post #255

Earlier quoted context omitted.

Or you opt to not encrypt your home separately. But how large a proportion of machines do you think have mail delivery rely on .forward or .procmailrc in $HOME these days? In any case, procmail can be executed directly rather than from .forward in most cases, and can be configured to take the rc file to be a file in /etc/procmail-rcs/ as an alternative to $HOME/.procmailrc (at least the version of procmail in Ubuntu;…

Maybe my point wasn't stated clear enough: the crontab itself is in spool, obviously, but the scripts started from crontab entries reside in my home directory. And while a procmailrc can live in some spool too, the files to be delivered into are in my home directory too.

So then you have two choices: Move them elsewhere, and be able to encrypt the rest of $HOME, or don't encrypt $HOME. This gives you additional options for protecting your home directory if you want it. Noone is forcing you.

Re: Systemd, ten years later: a historical and technical retrospective

#387

Post by yawaramin » Mon, May 04, 2020, 4:42 PM UTC

ttctciyf wrote: post #69

yawaramin wrote: post #33

Earlier quoted context omitted.

That thread also mentions the solution that will work: https://askubuntu.com/a/904125 I.e., systemd-run --scope --user screen

Nope: [user]@[host]:~$ systemd-run --scope --user screen Job for run-r0b2a43d19a564e2c9f36b5c9b934420f.scope failed. See "systemctl status run-r0b2a43d19a564e2c9f36b5c9b934420f.scope" and "journalctl -xe" for details. [user]@[host]$ journalctl -xe | cat May 04 03:02:54 [host] systemd[918]: Failed to start /usr/bin/screen. -- Subject: Unit UNIT has failed -- Defined-By: systemd -- Support: http://www.ubuntu.com/suppor…

It might be this issue https://bbs.archlinux.org/viewtopic.php?pid=1724323#p1724323

Re: Systemd, ten years later: a historical and technical retrospective

#388

Post by downerending » Mon, May 04, 2020, 4:42 PM UTC

josteink wrote: post #167

downerending wrote: post #72

Earlier quoted context omitted.

Systemd has many pluses, but simplicity and intuitiveness are most certainly not among them.

Simple... for what? I’d like to setup a service, which depends on another service, and which must always be running, and if it goes down, it needs to have all forked processes killed, must be restarted, and it needs to run as a specific user. With systemd? 5 lines or so of boilerplate, independent of distro. I don’t know about you, but I call that simple.

I've run across a couple of cases where the "depends on" part seems to intermittently fail. That is, the implementation seems to end up with a race. That presumably means that the dependencies were specified incorrectly, but getting it right seems to be quite difficult. Or, conceivably, it's a bug in systemd, but debugging that is a lot harder than debugging a couple of tiny shell scripts.

I'm not necessarily a "remainer" on the subject of systemd, but I think it's not correct to sell it as a huge win on simplicity. Maybe it is simple when everything goes right. When it doesn't, though, systemd is fairly nasty to deal with.

Re: Systemd, ten years later: a historical and technical retrospective

#389

Post by [deleted] » Mon, May 04, 2020, 4:44 PM UTC

cycloptic wrote: post #383

TA0x0 wrote: post #376

Earlier quoted context omitted.

You have to, since systemd implemented the feature incorrectly. You're missing the forest for the trees.

I've already been in a forest of bash scripts and I would not go back there again. I have no comment on systemd's implementation but the implementation you're talking about is also incorrect. It has never been safe to kill random processes using a bash script running in the background, on most Unixes (and Linux) it is 100% impossible to do that without race conditions due to the limitations of procfs. Doing "ps | gre…

[deleted]

Re: Systemd, ten years later: a historical and technical retrospective

#390

Post by Koshkin » Mon, May 04, 2020, 4:54 PM UTC

michaelmrose wrote: post #380

tomatocracy wrote: post #261

Earlier quoted context omitted.

I noticed the ConsoleKit->logind change at the time being largely justified by support for multiseat but had forgotten about it. It seems like a rather extreme case of the tail wagging the dog but perhaps I'm missing something. How many people use multi-seat in large deployments? Where and why?

Virtually nobody is using multi-seat and none should. For most cases you would get better results by networking n cheap boxes rather than trying to buy a single beefy box to support n users on every dimension including perhaps even power usage if you used low power devices. Contention for io is a problem. Everyone wanting to say decode video simultaneously is a problem. Browsers high ram usage is a problem.

> rather than trying to buy a single beefy box to support n users

This sentiment has always felt weird to me, as I have always seen UNIX as an OS that has been designed - from the ground up (in late 1960s) to support multiple concurrent users - whether it is via a serial terminal, and now multi-seat, VNC or an X terminal. By today's standards it's not even such a "beefy box" that can easily do that.