Adding Systemd to PostmarketOS

https://postmarketos.org/blog/2024/03/05/adding-systemd/

by MartijnBraam • 2 years ago

56 41 2 years ago

postmarketos.org

hiAndrewQuinn• 2 years ago

Oh hell yeah! The cell phone server idea just became a lot more viable for this Sysadmin.

seba_dos1• 2 years ago

Just now? pmOS was probably the last popular mobile distro that didn't default to systemd yet.

akho2• 2 years ago

It's also the only one that worked on first try on my OnePlus 6.

(For a certain value of "worked")

I don't think most other ones are viable outside of a Pinephone.

SuperNinKenDo2• 2 years ago

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.

yjftsjthsd-h• 2 years ago

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.

SuperNinKenDo2• 2 years ago

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?

theamk3• 2 years 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• 2 years ago

socket activation

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

egberts1• 2 years ago

what about tmpfiles? systemd-tmpfiles?

NewJazz3• 2 years ago

Most non-systemd-init distros use systemd-tmpfiles.

BobbyTables2• 2 years 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??

theamk3• 2 years 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• 2 years 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.

theamk3• 2 years 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.

AdmiralAsshat• 2 years ago

Is Alpine cool with this?
We have shared this blog post with the Alpine devs before this publication, and we hope that they understand our reasoning.

So then they weren't cool with it, huh?

kllrnohj• 2 years ago

Seems like kinda a weird Q&A question regardless, who cares if Alpline is cool with it or not? It doesn't actually matter?

MartijnBraam2• 2 years ago

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.

sam_lowry_• 2 years ago

Hm... time to move to bare Alpine for my Pinebook Pro.

I do not really need Gnome nor KDE.

bsimpson• 2 years ago

Did you read the post?

It's an option now. If you don't want it, don't install it.

Shared404• 2 years ago

I do not really need Gnome nor KDE.

Then it's unlikely that this change will impact you. You probably already need to build your own image, just build without systemd.

colinsane2• 2 years ago

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.

johnea• 2 years ago

Resistance is futile, you will be assimilated...

palata• 2 years ago

It seems like the biggest reason is "KDE and GNOME need systemd, so we need systemd".

In other words, systemd is winning because systemd is winning. Not because it's better.

MartijnBraam2• 2 years ago

Exactly, this is straight up pressure from GNOME to get systemd everywhere.

generalizations• 2 years ago

Eh, I'd say it's more likely pressure from RedHat. They benefit hugely from a complex ecosystem that creates demand for their consulting business.

johnny222• 2 years ago

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

jeppesen-io• 2 years ago

  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."

colinsane2• 2 years ago

  - 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.

NewJazz3• 2 years ago

Same as ten years ago.

infogulch• 2 years ago

"systemd is a microkernel" - https://x.com/mycoliza/status/1765058565956587757

captn3m0• 2 years ago

It doesn’t actually answer the libc question.

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.

What’s the path here? Running glibc on Alpine?

foul2• 2 years ago

Either that or something else, like Mobian, with apk I guess.

foul2• 2 years ago

"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!

lproven• 2 years ago

Dupe: https://news.ycombinator.com/item?id=39624181 (0 comments)

Adding Systemd to PostmarketOS

Related Stories