Live data from Hacker News

Systemd by Example (2021)

seb.jambor.dev

31–40 of 115 posts

Re: Systemd by Example (2021)

#31

Earlier quoted context omitted.

Neither are systemd timers. I don't think there's a single system out there implementing the systemd timer interface.

What do you mean? There's a single implementation as far as I know, deployed on many distributions and working identically.

> There's a single implementation as far as I know

That's exactly what I mean.

Systemd itself, including timers, is deeply coupled with the Linux API, and cannot be (easily) ported on any other system. Cron, on the other hand, exists on almost every UNIX-like system.

Re: Systemd by Example (2021)

#32
I am not having a good time with systemd on my embedded device.

Somewhat complicated scenario, I need to change the mode of a wifi driver (which I do via modprobe), use iw to create a second interface for that wifi device, and finally use networkmanager to create a wifi hotspot based on the host name of the device. We set the hostname based on the mac address of wlan0.

There are a lot of places this can go wrong, and you need a lot of deep knowledge of systemd to get it right.

I start with three services, one to set the hostname, one to create the wlan0_ap device, and one to start up the wifi hotspot using nmcli.

Alright, simple enough, this is the kind of thing systemd is good at, right?

Well no, (and pardon me if my memory isn't perfect on this, it's tricky to debug weird race conditions) sometimes setting the hostname fails. Why? Well sometimes wlan0 doesn't exist, there's a udev rule that renames wlan0 during start up. Apparently I can add the systemd tag to that udev rules, and it will create a `.device` dependency I can Require. Alright, use both require and after keywords just to be sure. Good enough.

Huh, onehsot services are listed as stopped even though they've run. Do some research, find out I need the `RemainAfterExit` keyword yet. Sure, dependencies are working.

Now wlan0_ap device creation sometimes fails. Why? No really, why, this is hard to debug. Well looking around at dmesg it looks like the problem is that networkmanager is trying to do something with the device at the same time I am. Looks like it's enumerating device capabilities at the same time I'm trying to create a new device? Oh well, I'll just add the retry keyword to my service.

Oh, wait, I can't add the retry keyword to one-shot services? Really? Internet tells me to change the service type to simple. Sure, we'll try that. Now that wlan0_ap device exists, let's start our access point.

Also it's still sometimes failing on the hostname step still? The set-hostname command is asynchronous I think? I'll add a line to the start_access_point script that waits until the hostname isn't the default.

Everything is looking good. Oh wait, it's sometimes failing intermittently. What the hell, why doesn't wlan0_ap exist? Service type `simple` considers a service to be started when the command first launches, not when it exit successfully. I've introduced another race condition.

How can I make a service that works like a oneshot, but that you can retry? What, write a shell script and use systemd-notify to say it's complete?

Long story short I ended up just writing a traditional shell-script based init script. Maybe I'm thinking about systemd wrong or something.

Re: Systemd by Example (2021)

#33
post #9

Personally I find systemd man pages pretty great, they comprehensively explain pretty much every thing that you need to know. Sure, they are more of a reference than a tutorial and there is lot of material to read there, but still I'd recommend reading the relevant sections whenever you are working with systemd https://www.freedesktop.org/software/systemd/man/latest/syst...

> Sure, they are more of a reference than a tutorial

Well, that's kinda the point of a `man`ual page.

Re: Systemd by Example (2021)

#34
post #21
post #13

A lot of people still probably hate on systemd, but it and journalctl are pretty nice to me.

Not a lot of people, a very loud minority. They can go use Void Linux or other niche distros which replace it with the monstrosity that were SysV init scripts. It's the type of people that never had to write one of those scripts by hand, and maybe support two or three different distros. The UX of systemd tools (systemctl, journalctl) is a bit crap, to be honest, but systemd does what it needs to do well and it is an…

>The UX of systemd tools (systemctl, journalctl) is a bit crap....

And this is easily 80% of why I don't like it. I _know_ it's better* but my use-cases have never clashed with the limitations of init.d.

*better: I've recently had an issue that I was trying to troubleshoot while using `journalctl -fu service-name` and it just wasn't giving me enough information/the same content that /var/log/messages was giving me on my other OS (FreeBSD). Perhaps there was a flag I was missing (increase verbosity??) but the UX did get in the way.

Side note: I do chuckle every time I end up using the -fu flag. =)

Re: Systemd by Example (2021)

#35
post #21
post #13

A lot of people still probably hate on systemd, but it and journalctl are pretty nice to me.

Not a lot of people, a very loud minority. They can go use Void Linux or other niche distros which replace it with the monstrosity that were SysV init scripts. It's the type of people that never had to write one of those scripts by hand, and maybe support two or three different distros. The UX of systemd tools (systemctl, journalctl) is a bit crap, to be honest, but systemd does what it needs to do well and it is an…

That's serveral conjectures on your part. Give me metrics about the minority and then back up the fact that most of those people never wrote a sysinit or rc script by hand.

Like it or not Systemd breaks the Unix way and for a certain amount of people (I am not pretending to have a measuring stick) the dogma and philosophy are much more important than perceived ease of use or features.

Re: Systemd by Example (2021)

#36

I am not having a good time with systemd on my embedded device. Somewhat complicated scenario, I need to change the mode of a wifi driver (which I do via modprobe), use iw to create a second interface for that wifi device, and finally use networkmanager to create a wifi hotspot based on the host name of the device. We set the hostname based on the mac address of wlan0. There are a lot of places this can go wrong, and…

> I need to change the mode of a wifi driver (which I do via modprobe)

Is that something that could be added to modprobe.conf to have it work right without any modprobe calls?

> Huh, onehsot services are listed as stopped even though they've run. Do some research, find out I need the `RemainAfterExit` keyword yet. Sure, dependencies are working.

Yeah I've also been burned not having RemainAfterExit=y in a oneshot unit. What's worse, such an unit can get started multiple times.

> Well looking around at dmesg it looks like the problem is that networkmanager is trying to do something with the device at the same time I am. Looks like it's enumerating device capabilities at the same time I'm trying to create a new device?

To be fair such race condition could have happened in any init system.

> Oh well, I'll just add the retry keyword to my service.

Perhaps having a dependency to start your service before network-manager would have solved this.

> Long story short I ended up just writing a traditional shell-script based init script. Maybe I'm thinking about systemd wrong or something.

It's perfectly fine IMO to have small shell script services for such stuff.

Probably some of the problems are due to network-manager being mostly designed/used for desktop use cases. It also likes to take complete control of all the interfaces so calling iw/ifconfig behind it's back will cause tears (as you found out).

I do agree that race conditions caused by parallel service startup really suck in embedded devices. Systemd really could use a "please be as deterministic as possible" mode for embedded (if it already doesn't have).

Re: Systemd by Example (2021)

#37

I wish I could make friends with systemd like y'all. I spent at least a week wrestling unsuccessfully with systemd (admittedly starting from complete ignorance) to make a service that synchronizes a local directory on a laptop with a remote directory on a server after a docker container is stopped but before the filesystems and network stack are torn down during poweroff. It was easy enough to accomplish by manually…

Naively, I'd expect `ExecStop=` to just work™. Is this not the case?

Re: Systemd by Example (2021)

#38
post #21

Earlier quoted context omitted.

Not a lot of people, a very loud minority. They can go use Void Linux or other niche distros which replace it with the monstrosity that were SysV init scripts. It's the type of people that never had to write one of those scripts by hand, and maybe support two or three different distros. The UX of systemd tools (systemctl, journalctl) is a bit crap, to be honest, but systemd does what it needs to do well and it is an…

>The UX of systemd tools (systemctl, journalctl) is a bit crap.... And this is easily 80% of why I don't like it. I _know_ it's better* but my use-cases have never clashed with the limitations of init.d. *better: I've recently had an issue that I was trying to troubleshoot while using `journalctl -fu service-name` and it just wasn't giving me enough information/the same content that /var/log/messages was giving me on…

You can see the raw message with `-o verbose` (or json/json-pretty/...). You can also pick just the fields you want with `--output-fields`.

  $ journalctl -f -u sshd

  Feb 15 13:21:56 vm sshd[4844]: pam_unix(sshd:session): session opened for user user(uid=1000) by user(uid=0)
vs

  $ journalctl -f -u sshd -o verbose
 
  Thu 2024-02-15 13:21:56.886724 UTC [...]
    PRIORITY=6
    _SYSTEMD_SLICE=system.slice
    _BOOT_ID=8e87dffc55844df1b122cfa31010b1df
    _HOSTNAME=vm
    _RUNTIME_SCOPE=system
    _UID=0
    _GID=0
    _CAP_EFFECTIVE=1ffffffffff
    _TRANSPORT=syslog
    SYSLOG_IDENTIFIER=sshd
    SYSLOG_PID=4844
    SYSLOG_TIMESTAMP=Feb 15 13:21:56 
    _PID=4844
    _COMM=sshd
    _EXE=/usr/bin/sshd
    _CMDLINE="sshd: user [priv]"
    _SYSTEMD_CGROUP=/system.slice/sshd.service
    _SYSTEMD_UNIT=sshd.service
    _SYSTEMD_INVOCATION_ID=4065f778bd534ab98f1849d858d0f49e
    SYSLOG_FACILITY=10
    MESSAGE=pam_unix(sshd:session): session opened for user user(uid=1000) by user(uid=0)
    _SOURCE_REALTIME_TIMESTAMP=1708003316886724

Re: Systemd by Example (2021)

#39
post #21
post #13

A lot of people still probably hate on systemd, but it and journalctl are pretty nice to me.

Not a lot of people, a very loud minority. They can go use Void Linux or other niche distros which replace it with the monstrosity that were SysV init scripts. It's the type of people that never had to write one of those scripts by hand, and maybe support two or three different distros. The UX of systemd tools (systemctl, journalctl) is a bit crap, to be honest, but systemd does what it needs to do well and it is an…

> which replace it with the monstrosity that were SysV init scripts

Void does not use SysV init scripts. Neither do the other distros I know of that do not use systemd.

Re: Systemd by Example (2021)

#40

Earlier quoted context omitted.

What do you mean? There's a single implementation as far as I know, deployed on many distributions and working identically.

> There's a single implementation as far as I know That's exactly what I mean. Systemd itself, including timers, is deeply coupled with the Linux API, and cannot be (easily) ported on any other system. Cron, on the other hand, exists on almost every UNIX-like system.

I'm sure the few people who run BSD systems will be fine with cron's arcane syntax.
Post reply on HN