Systemd is an annoying turd. Still hate dealing with it to this day. I have to refer to the man pages every. single. time.
Systemd, ten years later: a historical and technical retrospective
441–450 of 458 posts
Re: Systemd, ten years later: a historical and technical retrospective
#442Earlier quoted context omitted.
Are you perhaps confusing something? > A "bad" daemon might not print anything to stdout when invoked (which goes to dmesg) but regardless, this whole comment just reeks of someone who hasn't actually dealt with systems before 2014. The daemons never print to dmesg -- they may print to syslog, but not all do. The only daemon that I know of that prints to dmesg is systemd :) To be specific, let's do a simple example.…
log_warning_msg is a function which is wrapping 'echo'. if you 'echo' it will go to the console. Your distro can/does log everything that goes to the boot console. The function 'log_warning_msg' is provided by the sourced bash file: /lib/lsb/init-funtions ; you can find a copy here: http://www.linuxfromscratch.org/lfs/view/7.0/scripts/apds02.... It's just doing echo. If you add "echo" it will print. I promise. And an…
Which distro logs tty0 console output from echo ? Debian does not. Fedora does not. Gentoo used to, but it broke.
Both /var/log/dmesg and /var/log/messages log printk output from inside the kernel. They do not log echo output from userspace.
Are you sure you are an admin?
Re: Systemd, ten years later: a historical and technical retrospective
#443Earlier quoted context omitted.
log_warning_msg is a function which is wrapping 'echo'. if you 'echo' it will go to the console. Your distro can/does log everything that goes to the boot console. The function 'log_warning_msg' is provided by the sourced bash file: /lib/lsb/init-funtions ; you can find a copy here: http://www.linuxfromscratch.org/lfs/view/7.0/scripts/apds02.... It's just doing echo. If you add "echo" it will print. I promise. And an…
Which distro logs tty0 console output from echo ? Debian does not. Fedora does not. Gentoo used to, but it broke. Both /var/log/dmesg and /var/log/messages log printk output from inside the kernel. They do not log echo output from userspace. Are you sure you are an admin?
> Which distro logs tty0 console output from echo ? Debian does not. Fedora does not. Gentoo used to, but it broke.
None, anymore, that's a little bit the point.
Devuan does, so does Debian 7 and RHEL6.
I just tested it on all three in a VM.
yes, I'm sure I'm an admin.
Re: Systemd, ten years later: a historical and technical retrospective
#444Earlier quoted context omitted.
> Face it: the linux userspace has always sucked. Linus punted on it way-back-when (to be fair, he was a solo dev working on a kernel, he had his hands full) and opted for the gnu tools, but those (other than the compiler and libc and a few other spots like grep) have never been best-in-class. Which userspace are you claiming is better then? Linux used to offer the best userland experience in the world, because you h…
> pressured other projects to hard-depend on it (e.g. Gnome). GNOME wasn't pressured in depending on it. There deciding to depend on logind over ConsoleKit. Initially logind could be used without systemd, that changed after a systemd version due to cgroups v2. There's quite a bit of overlap between the people maintaining ConsoleKit and the people wanting to make use of logind, so there was a push by some GNOME mainta…
Ignore him? Ignores decades upon on decades of hard earned experience?
Re: Systemd, ten years later: a historical and technical retrospective
#445Earlier quoted context omitted.
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).
Linger does more than just keeping the session open after logout. It also means that the session gets started automatically on boot, which is necessary if you want to have systemd units for that user autostart. Case in point, the PulseAudio setup on my homeserver: https://github.com/majewsky/system-configuration/blob/2f93ff...
Re: Systemd, ten years later: a historical and technical retrospective
#446Earlier quoted context omitted.
> No one is forcing you to change your broken buggy 30-year old shell scripts, you can always continue using them. How about usernames that start with a digit? Am I still allowed to use those? * https://ma.ttias.be/giving-perspective-systemds-usernames-st...
POSIX says that any tool should always translate usernames into userids at the earliest possible point, and pass UIDs to children it spawns. Now assuming I have a user called 1000 with UID 2000, and a user called 2000 with UID 1000. Now what do you think is gonna happen if multiple POSIX-compliant tools call each other? This is clearly broken, and the reason why BSDs don’t actually implement POSIX cleanly, instead al…
The weblog post has an user called '0day', i.e., "zero day". This breaks systemd as outlined in the post. This is a WONTFIX per the systemd folks.
Re: Systemd, ten years later: a historical and technical retrospective
#447Earlier quoted context omitted.
POSIX says that any tool should always translate usernames into userids at the earliest possible point, and pass UIDs to children it spawns. Now assuming I have a user called 1000 with UID 2000, and a user called 2000 with UID 1000. Now what do you think is gonna happen if multiple POSIX-compliant tools call each other? This is clearly broken, and the reason why BSDs don’t actually implement POSIX cleanly, instead al…
The weblog post has an user called '0day', i.e., "zero day". This breaks systemd as outlined in the post. This is a WONTFIX per the systemd folks.
That’s one of the possible options, the other would be replacing chown, chmod, ls, etc (as the BSDs do)
Re: Systemd, ten years later: a historical and technical retrospective
#448Earlier quoted context omitted.
> Should any user on a shared university computer be able to spawn processes to run for all eternity? That's for the university IT to decide, of course. Software should focus on providing general mechanism, not policy. > Should your desktop environment crashing lead to all software continuing to run, for all eternity, leaking memory like there’s no tomorrow? AIUI, that's pretty much what might happen if you're forced…
> the fact that it doesn't manage to interoperate cleanly with the likes of tmux and screen is a pretty blatant papercut. Interoperating with broken hacky solutions is nothing admirable. At some point, you have to introduce a new API, which handles this properly, and introduce a way to give/take permissions for these things (so e.g. zoom doesn’t just run their dataminer forever through the same mechanism).
I've never understood this argument. What keeps, in your example, Zoom from just setting the Linger state via the new API?
Re: Systemd, ten years later: a historical and technical retrospective
#449Earlier quoted context omitted.
Slackware doesn't use it, and Patrick Volkerding recently got a Patreon account set up so Slackware 15.0 or 14.3 will hopefully be out soonish with updated packages. I'm writing this on 14.2 and have been running it since it came out with basically no issues. Also have it on a backup server, runs great.
But it’s 2020, and we need package management.
It's 2020, and nix and guix both run on top of Slackware just fine.
Re: Systemd, ten years later: a historical and technical retrospective
#450Earlier quoted context omitted.
> the fact that it doesn't manage to interoperate cleanly with the likes of tmux and screen is a pretty blatant papercut. Interoperating with broken hacky solutions is nothing admirable. At some point, you have to introduce a new API, which handles this properly, and introduce a way to give/take permissions for these things (so e.g. zoom doesn’t just run their dataminer forever through the same mechanism).
I've never understood this argument. What keeps, in your example, Zoom from just setting the Linger state via the new API?
You can grant or remove the linger state permission from users and applications.
Default is usually that either any user can have any software lingering, or that any user can authenticate (as you'd do with e.g. sudo) to set this state. This would work via PolicyKit and elevated permissions, similar to the UA prompt on Windows.
You can also white- or blacklist individual applications and services from this :)
That's what I meant with "proper" API in contrast to old tmux/nohupd.
And as service management is the init system's task, it's clear this is something where you have to interface with the init system (as the init system is actually even supposed to reap any process reparented to it to reduce zombie processes).