3 ms·

nice! Two systemd features that would (IMHO) be especially useful in cell phones are: - socket activation (as post says, "print from your phone without having

by theamk 3y ago

nice! Two systemd features that would (IMHO) be especially useful in cell phones are: - socket activation (as post says, "print from your phone without having CUPS running all the time") - extra security. Many daemons drop privileges, but how many of them also isolate filesystem and install seccomp filters? With systemd, it could be "every one"

5d41402abc4b 3y ago
>socket activation Is there a page that lists all of systemd's features?
egberts1 3y ago
what about tmpfiles? systemd-tmpfiles?
- NewJazz 3y ago
  Most non-systemd-init distros use systemd-tmpfiles.
BobbyTables2 3y ago
It’s one thing to launch a daemon with restricted privileges, but they often need to do privileged things at startup and then drop privileges them on their own. How would systemd help with that??
- theamk 3y ago
  A lot of times you cat offload stuff to systemd. For example, a server might need privileged operations to open low port and set up logging. But with systemd, you use socket activation, so low port is opened for you, and logging is centralized, you just write to stdout. If this is not enough, you can have "ExecStartPre" command in unconfined mode. Great if you need to fix up permissions for example. And if that does not work either, you can do privilege dropping twice. For example, systemd isolates filesystem, sets capabilities and NoNewPrivileges bit, but still runs daemon with root access. Daemon does whatever init it needs to do, and then drop the remaining privileges.
mid-kid 3y ago
Does socket activation also stop the service after a while? In my experience dbus autostart services are always a huge mess, making it unpredictable what will be running after a while of using the computer, and they never stop themselves either. I generally prefer either stopping/starting a service on demand or just keeping it always on, to ensure predictability and prevent buildup of never-stopped services.
- theamk 3y ago
  When you set Accept=yes (new process per connection), then service naturally stops once connection closes. But that approach has relatively high per-connection overhead, so it cannot be used in a lot of cases. Still pretty useful for stuff like x11vnc. For Accept=no, there is no auto-stop. I think it's because once service is activated, systemd no longer has reliable information about socket and thus cannot tell if the service is idle or not. But what socket/dbus activation does is it enables services to exit on idle. And some services actually do it - systemd-timedated being one example. Any time I enter "timedatectl" I see it start and then exit.

by theamk 3y ago

5d41402abc4b 3y ago

>socket activation Is there a page that lists all of systemd's features?

egberts1 3y ago

what about tmpfiles? systemd-tmpfiles?

NewJazz 3y ago
Most non-systemd-init distros use systemd-tmpfiles.

BobbyTables2 3y ago

It’s one thing to launch a daemon with restricted privileges, but they often need to do privileged things at startup and then drop privileges them on their own. How would systemd help with that??

theamk 3y ago
A lot of times you cat offload stuff to systemd. For example, a server might need privileged operations to open low port and set up logging. But with systemd, you use socket activation, so low port is opened for you, and logging is centralized, you just write to stdout. If this is not enough, you can have "ExecStartPre" command in unconfined mode. Great if you need to fix up permissions for example. And if that does not work either, you can do privilege dropping twice. For example, systemd isolates filesystem, sets capabilities and NoNewPrivileges bit, but still runs daemon with root access. Daemon does whatever init it needs to do, and then drop the remaining privileges.

mid-kid 3y ago

Does socket activation also stop the service after a while? In my experience dbus autostart services are always a huge mess, making it unpredictable what will be running after a while of using the computer, and they never stop themselves either. I generally prefer either stopping/starting a service on demand or just keeping it always on, to ensure predictability and prevent buildup of never-stopped services.

theamk 3y ago
When you set Accept=yes (new process per connection), then service naturally stops once connection closes. But that approach has relatively high per-connection overhead, so it cannot be used in a lot of cases. Still pretty useful for stuff like x11vnc. For Accept=no, there is no auto-stop. I think it's because once service is activated, systemd no longer has reliable information about socket and thus cannot tell if the service is idle or not. But what socket/dbus activation does is it enables services to exit on idle. And some services actually do it - systemd-timedated being one example. Any time I enter "timedatectl" I see it start and then exit.