I'm actually really excited about this. With all the things on a phone that are constantly switching on and off, connecting and reconnecting and disconnecting and moving, etc. etc. Systemd's dependency management, etc. seems like a no-brainer. Sorry to the Systemd haters, I do get it, I don't like how programs are baking in Systemd dependency either, but to me, it's a big step in the right direction for modern computing init systems.
> With all the things on a phone that are constantly switching on and off, connecting and reconnecting and disconnecting and moving, etc. etc
Could I trouble you for an example? The only regular connection changes I can see are networking changes that are managed at a different layer, or things that are user-level applications.
Sure. Networking is the obvious one, then comes similar stuff like Bluetooth, then you've got stuff like peripherals; headphones, hardware keyboards, and to a lesser extent stuff like USB storage. You have state changes like charging and not charging. To a lesser extent stuff like switching SIMs or removing SD cards. More broadly, i.e., stuff that isn't networking or peripherals, you have stuff like the screen being on or not, wheyher the screen is locked or not, whether the phone has been unlocked since a restart (and therefore the filesystem still partially encrypted), you have power saving modes, dynamic brightness changes.
While a lot of these also apply to more traditional computing, I'd say on a phone that many of them are more prone to changing rapidly, part of a more integrated device (for instance, turning off your phone screen is usually a very different kind of action that merely turning off your monitor), and generally effect the function of the device to a greater extent. Would you agree?
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"
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.
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.
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??
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.
> Our current understanding having spoken to systemd developers is that we should be able to find a path that brings us much closer to upstream, if not entirely.
would love to see tighter collaboration between pmOS and sxmo maintainers on this one. sxmo is sort of a pmOS-exclusive right now because it does all its own service management. seems like a great opportunity while pmOS is rethinking its service management to do it in a way that helps sxmo be more multi-distro capable.
My OnePlus 6 running Kupfer (Arch Linux ARM) [0] and my Shift6mq running Mobian [1] (Debian blend) in dual boot from microSDXC card [2] would like to have a word. Droidian (Halium-based Debian) also supports the enchilada.[3]
And then, there's also NixOS mobile [4]. They all have had systemd before this.
[0] https://kupfer.gitlab.io/, setting up kupferbootstrap can be hard though, especially if you don't have docker set up on that system already.
What fancy new features will we get with systemd?
Granular privilege controls
Powerful service dependency and security analysis features
Tight cgroups integration both static and dynamic
Socket activation (so you can print from your phone without having CUPS running all the time!)
Built in boot-time analysis
also
What's wrong with the polyfills?
...
corecollector (systemd-coredumpd) 1: Not needed to run KDE and GNOME, but a very useful tool that many developers expect to be able to use to easily retrieve coredumps and associated metadata, without first figuring out how to configure them properly. It is great that there is a polyfill for it, but it is unmaintained since 2020. Plasma Mobile developer Devin wrote: "When debugging crashes, it’s incredibly useful to be able to view coredumps and attach a debugger after the fact with coredumpctl, this can help us obtain backtraces that would otherwise be hard to replicate again with a debugger attached. We can also then enable DrKonqi’s coredumpd integration, which can allow users to get notifications about process crashes and see them from a GUI. DrKonqi also has optional integration with our Sentry instance, which we can enable on developer installs to automatically send crashes to a web dashboard for us."
- Granular privilege controls
- Tight cgroups integration both static and dynamic
highlighting these in particular because of notable regressions in the systemd 254 -> 255 release. i think there's the perception that "systemd features are so easy to use" so therefore "systemd must be equally easy to maintain". it's not.
my advice to pmOS maintainers is to experience at least one systemd upgrade cycle before committing to it in any meaningful sense. that said, if the project has the bandwidth to maintain all of these different service managers/init systems, then yeah absolutely go for it.
considering gnome runs on freebsd, that's just not true. The only work those folks had to put in was implementing one interface for what logind provides
Not really, it's garbage to the point that it only runs the X11 session, mutter can't even be compiled with Wayland support because it then tries to include some Linux-only header.
I think it's quite important to have a good relation with upstream developers. You don't want to get into the situation that Manjaro got in with Arch Linux.
"Our current understanding having spoken to systemd developers is that we should be able to find a path that brings us much closer to upstream, if not entirely."
Adapt or don't offer GNOME/KDE (get fscked), classic Red Hat!
