6 ms·

> The systemd notification protocol could have been as simple as just writing a newline to a pipe It basically is. libsystemd links to liblzma for other featur

> The systemd notification protocol could have been as simple as just writing a newline to a pipe It basically is. libsystemd links to liblzma for other features not related to notifications. (The protocol is that systemd passes the path to a unix socket in the `NOTIFY_SOCKET` env variable, and the daemon writes "READY=1" into it.)

agwa 3y ago
Is that protocol documented/stable? For whatever reason, daemons are choosing to link to libsystemd instead of implementing it themselves. It doesn't matter that libsystemd links to liblzma for other reasons. It's still in the address space of any daemon that is using libsystemd for the notification protocol.
- wickberg 3y ago
  I know Golang has their own implementation of sd_notify(). For Slurm, I looked at what a PITA pulling libsystemd into our autoconf tooling would be, stumbled on the Golang implementation, and realized it's trivial to implement directly.
  - pkaye 3y ago
    Can me point me to the Golang implementation? Is it a standard package?
    - yencabulator 3y ago
      Most likely https://github.com/coreos/go-systemd https://github.com/coreos/go-systemd
  - tripflag 3y ago
    indeed; it should be trivial in any language. Here's python: https://github.com/9001/copyparty/blob/a080759a03ef5c0a6b06c697f37ae4e00812739f/copyparty/svchub.py#L1019-L1038 https://github.com/9001/copyparty/blob/a080759a03ef5c0a6b06c...
    - cesarb 3y ago
      It should be trivial in any language which has AF_UNIX. Last time I looked, Java didn't have it, so the only way was to call into non-Java code.
      - reftel 3y ago
        Then I suggest you have another look =) https://inside.java/2021/02/03/jep380-unix-domain-sockets-channels/ https://inside.java/2021/02/03/jep380-unix-domain-sockets-ch...
        fullstop 3y ago
        Under Limitations: Datagram support
        reftel 3y ago
        It appears you are correct. What an odd limitation!
      - fullstop 3y ago
        At first I thought that this surely could not be true as of today, but it looks like it is. There is AF_UNIX support, but only for streams and not datagrams: https://bugs.openjdk.org/browse/JDK-8297837 https://bugs.openjdk.org/browse/JDK-8297837 What an odd decision. I suppose that you could execute systemd-notify but that's a solution that I would not like.
        cesarb 3y ago
        > I suppose that you could execute systemd-notify but that's a solution that I would not like. What I did was to use JNA to call sd_notify() in libsystemd.so.0 (when that library exists), which works but obviously does not avoid using libsystemd. I suppose I could have done all the socket calls into glibc by hand, but doing that single call into libsystemd directly was simpler (and it can be expected to exist whenever systemd is being used).
  - KerrAvon 3y ago
    Caveat is that golang is not a good enough actor to be a reliable indicator of whether this interface is supported, though. They’ll go to the metal because they can, not because it’s stable.
tonyg 3y ago
Strange protocol. Why not pass a path to a file that should be `touch`d and/or written to, I wonder? Would avoid the complexity of sockets.
- Bu9818 3y ago
  Services may be in a different mount namespace from systemd for sandboxing or other reasons (also means you have to worry about filesystem permissions I suppose). Passing an fd from the parent (systemd) is a nice direct channel between the processes
  - NewJazz 3y ago
    But systemd precisely doesn't pass an FD. If it did, you would just need to write() and close().
    - Bu9818 3y ago
      Yeah I was wrong about that, I confused it with socket-activation passing. The systemd-side socket is available from the process.
wiml 3y ago
> libsystemd links to liblzma for other features not related to notifications Which is pretty emblematic of systemd's primary architectural fault!
- IAmNotACellist 3y ago
  systemd getting its tentacles everywhere they can squeeze is a feature, not a bug
yrro 3y ago
The funny thing is that libsystemd _used_ to be split into several different libraries. I certainly remember libsystemd-journal (which is presumably the part of libsystemd that pulls in liblzma) being separate to libsystemd-daemon (which is the part that implements sd_notify, as used by OpenSSH [after patching by distros]). If that split had never happened, then liblzma wouldn't have ended up being linked into sshd...

agwa 3y ago

Is that protocol documented/stable? For whatever reason, daemons are choosing to link to libsystemd instead of implementing it themselves. It doesn't matter that libsystemd links to liblzma for other reasons. It's still in the address space of any daemon that is using libsystemd for the notification protocol.

wickberg 3y ago
I know Golang has their own implementation of sd_notify(). For Slurm, I looked at what a PITA pulling libsystemd into our autoconf tooling would be, stumbled on the Golang implementation, and realized it's trivial to implement directly.
- pkaye 3y ago
  Can me point me to the Golang implementation? Is it a standard package?
  - yencabulator 3y ago
    Most likely https://github.com/coreos/go-systemd https://github.com/coreos/go-systemd
- tripflag 3y ago
  indeed; it should be trivial in any language. Here's python: https://github.com/9001/copyparty/blob/a080759a03ef5c0a6b06c697f37ae4e00812739f/copyparty/svchub.py#L1019-L1038 https://github.com/9001/copyparty/blob/a080759a03ef5c0a6b06c...
  - cesarb 3y ago
    It should be trivial in any language which has AF_UNIX. Last time I looked, Java didn't have it, so the only way was to call into non-Java code.
    - reftel 3y ago
      Then I suggest you have another look =) https://inside.java/2021/02/03/jep380-unix-domain-sockets-channels/ https://inside.java/2021/02/03/jep380-unix-domain-sockets-ch...
      - fullstop 3y ago
        Under Limitations: Datagram support
        reftel 3y ago
        It appears you are correct. What an odd limitation!
    - fullstop 3y ago
      At first I thought that this surely could not be true as of today, but it looks like it is. There is AF_UNIX support, but only for streams and not datagrams: https://bugs.openjdk.org/browse/JDK-8297837 https://bugs.openjdk.org/browse/JDK-8297837 What an odd decision. I suppose that you could execute systemd-notify but that's a solution that I would not like.
      - cesarb 3y ago
        > I suppose that you could execute systemd-notify but that's a solution that I would not like. What I did was to use JNA to call sd_notify() in libsystemd.so.0 (when that library exists), which works but obviously does not avoid using libsystemd. I suppose I could have done all the socket calls into glibc by hand, but doing that single call into libsystemd directly was simpler (and it can be expected to exist whenever systemd is being used).
- KerrAvon 3y ago
  Caveat is that golang is not a good enough actor to be a reliable indicator of whether this interface is supported, though. They’ll go to the metal because they can, not because it’s stable.

tonyg 3y ago

Strange protocol. Why not pass a path to a file that should be `touch`d and/or written to, I wonder? Would avoid the complexity of sockets.

Bu9818 3y ago
Services may be in a different mount namespace from systemd for sandboxing or other reasons (also means you have to worry about filesystem permissions I suppose). Passing an fd from the parent (systemd) is a nice direct channel between the processes
- NewJazz 3y ago
  But systemd precisely doesn't pass an FD. If it did, you would just need to write() and close().
  - Bu9818 3y ago
    Yeah I was wrong about that, I confused it with socket-activation passing. The systemd-side socket is available from the process.

wiml 3y ago

> libsystemd links to liblzma for other features not related to notifications Which is pretty emblematic of systemd's primary architectural fault!

IAmNotACellist 3y ago
systemd getting its tentacles everywhere they can squeeze is a feature, not a bug

yrro 3y ago

The funny thing is that libsystemd _used_ to be split into several different libraries. I certainly remember libsystemd-journal (which is presumably the part of libsystemd that pulls in liblzma) being separate to libsystemd-daemon (which is the part that implements sd_notify, as used by OpenSSH [after patching by distros]). If that split had never happened, then liblzma wouldn't have ended up being linked into sshd...