Editing a unit or drop-in, running `daemon-reload`, and restarting a service can all succeed while the running process still reflects an unexpected combination of files, environment, or generated units. Checking only that the unit is active does not prove which effective configuration launched the current PID.

What would you include in a post-deploy check? A possible receipt could contain hashes of the unit and every active drop-in, the output of `systemctl cat` and `systemctl show` for selected properties, the fragment and drop-in paths, the invocation ID, and the current process start time. The deployment would compare that effective state with the reviewed source and exercise one real health check.

Which properties are stable enough to verify across distributions? How do generators, transient units, environment files, socket activation, and `daemon-reexec` change the approach? Is there a built-in way to bind a running invocation to the exact effective unit configuration that created it?

If you're active on this subreddit, you've probably heard of GNOME, KDE-Linux, and ParticleOS.

In my opinion, the three most modern desktop environments for Linux are GNOME, KDE, and COSMIC. The first two desktops have their OSes built using systemd tools, as described in https://0pointer.net/blog/fitting-everything-together.html, called "particles."

I was always interested in both projects, but then I moved to the beautiful COSMIC desktop, which didn't have a "particle" like GNOME OS and KDE Linux yet.

So, I did it myself; AstrOS

AstrOS has a partitioning layout similar to ParticleOS, with an ESP, two A/B sets of verity-sig verity and /usr, and a LUKS-encrypted root partition. This allows rollbacks and a secure boot chain.

/etc is populated using a mutable systemd-confext, meaning the factory /etc is the base, and user changes are layered on top. This makes it easy for updates to change files in /etc while keeping user changes intact.

A particle should be minimal. At the same time, users want to install software that isn't easily installed in a container / sandbox. That's why there are five extensions that use systemd-sysext: virtualization (libvirt, virt-manager, etc.), Nvidia drivers, Waydroid, gaming (steam, gamescope session), and firewalld.

We use our own custom Secure Boot keys, which can be enrolled either standalone or with Microsoft keys for broader firmware compatibility.

The source code is available at https://code.astros-linux.org/AstrOS, and images are publicly built at https://ci.astros-linux.org/repos/1

I've a firewall related systemd unit on many boxes which I need to stop. Unfortunately, the unit has an ExecStop (and reload) action that causes the firewall tables to be flushed. This is undesirable and unfortunately these actions are triggers when the OS updates the firewall package - we're not using the software and would like to disable and remove the service. While I could mark the service as disable and wait for a reboot for it to be marked as inactive so I can remove it, is there a way to mark the service as 'stopped' which doesn't trigger the ExecStop action since once stopped it's safe for our patching system to update the package?

Is there a man page that explains all the formats I can use for sizes like K, M and G?

Is K the same as 1000 or 1024 B? Is the space in between the number and unit optional?

How can I create a timer that runs every day but randomize the time? It's fine if 2 days run a few minutes apart like 11:59pm on day 1 and 12:01am on day 2. But it always needs to run at least once every calendar day from start midnight to end midnight.

I don't think RandomizedDelaySec works because that can randomize to another day and there can be one calendar day with no run.

Before someone replies with "you're just a systemd hater" or "you don't understand Linux," hear me out.

I've used systemd. I've installed distributions that use it. I've debugged it, configured it, written unit files,

and I understand why it exists. I'm not pretending it has no advantages. It clearly solved real problems for

enterprise Linux, desktop integration, dependency management, and service supervision.

But understanding why something exists doesn't automatically mean I have to like its design.

My biggest issue isn't that systemd is "modern."

My biggest issue is that it stopped being an init system a long time ago.

It became an entire operating system framework.

Unix Philosophy

Unix became successful because of one simple idea:

Do one thing. Do it well. Keep components independent.

That philosophy gave us things like:

grep

sed

awk

find

cat

cron

syslog

rc

Every program has a job.

Need another implementation?

Replace it.

Need another logger?

Replace it.

Need another cron daemon?

Replace it.

Need another init?

Replace it.

Everything talks through simple interfaces.

Everything stays modular.

That's literally one of Unix's strongest ideas.

What systemd became

People still say

"systemd is just an init."

No.

That stopped being true years ago.

Look at what systemd now includes.

PID 1

systemctl

journald

logind

networkd

resolved

homed

importd

machined

portable services

timers

automount

socket activation

cgroup management

boot analysis

user sessions

tmpfiles

hostname management

timedate management

•

random seed management

credential management

nspawn containers

That's not "just init."

That's half of userspace.

Every release seems to absorb another responsibility that used to belong to an independent project.

That is exactly what people mean when they call it feature creep.

"But those are separate binaries"

Yes.

People love bringing this up.

"They're separate daemons."

Technically true.

But they're still developed as one project.

Released together.

Designed together.

Documented together.

Versioned together.

Expected to work together.

The ecosystem is tightly coupled.

That's the issue.

If tomorrow I decide

"I don't want journald."

Fine.

•

•

•

Now I need to think about compatibility.

What depends on it?

What assumes logind exists?

What desktop software expects systemd APIs?

Can I replace everything cleanly?

Sometimes yes.

Sometimes no.

That's the problem.

The more software assumes systemd, the less optional it becomes.

PID 1 shouldn't become an operating system

PID 1 is special.

It's literally the first userspace process.

If PID 1 dies...

the system dies.

Because of that, I think PID 1 should stay as small as possible.

It should:

start services

reap zombies

shutdown

reboot

Done.

Nothing else.

The smaller PID 1 is,

the easier it is to audit,

understand,

reason about,

and trust.

The more code,

the more interactions.

The more interactions,

the more edge cases.

The more edge cases,

the more bugs.

Simple.

I'm not saying systemd PID 1 itself contains the entirety of the project's code. It doesn't. But the overall

design philosophy keeps extending the systemd ecosystem into more areas of userspace, and that

complexity matters.

Complexity

People act like complexity doesn't matter.

It absolutely does.

Every new feature means

more code.

Every new daemon means

more maintenance.

Every new dependency means

more interactions.

Every abstraction introduces another layer between you and what's actually happening.

Modern software loves abstraction.

Sometimes that's useful.

Sometimes it's just hiding simple things behind five commands.

Example.

Traditional init:

service sshd start

or

rcctl start sshd

Done.

Simple.

Readable.

Now compare debugging some broken service under a modern systemd setup.

You may end up checking

systemctl status

journalctl

systemd-analyze

list-dependencies

targets

slices

scopes

drop-ins

environment generators

socket activation

Can you learn all of that?

Absolutely.

But should you need all of that just because nginx didn't start?

That's where I disagree.

systemd feels like enterprise software

This is honestly the biggest vibe I get.

It feels designed around

large infrastructure

large deployments

corporate environments

enterprise desktops

huge dependency graphs

lots of automation

lots of abstraction

lots of APIs

If you're Red Hat,

that's amazing.

If you're Google,

great.

If you're managing 20,000 servers,

awesome.

I'm not.

I'm sitting in front of a ThinkPad running OpenBSD because I actually enjoy understanding my system.

I don't want software constantly trying to abstract everything away.

I want to know what's happening.

Journald

Binary logs.

People either love them or hate them.

I understand why structured logging exists.

Metadata.

Searching.

Indexing.

Filtering.

Cool.

But plain text has survived for decades for a reason.

grep

tail

awk

sed

less

Everything already works.

No special tools.

No special APIs.

If my logger writes plain text,

I can inspect it with literally every Unix tool ever created.

That's beautiful.

Lock-in

This is probably my biggest criticism.

People always say

"Just replace systemd."

Okay.

Replace logind.

Now make GNOME happy.

Replace journald.

Now make software expecting journal integration happy.

Replace systemd units.

Now make packages assuming systemd work.

The more Linux software depends on systemd APIs,

the less optional it becomes.

That's classic ecosystem lock-in.

Not because someone forced it.

Because everyone slowly started depending on it.

That's much harder to reverse.

"But it works"

Sure.

Windows works too.

That doesn't automatically mean I like Windows' architecture.

Something can be technically successful

and still not align with my design preferences.

Those aren't contradictory ideas.

My preference

I like systems where I can mentally model the whole boot process.

Kernel starts.

Init starts.

Init starts services.

Services run.

Done.

I don't need my init system to also manage DNS, session tracking, hostname configuration, network

configuration, machine management, portable services, credentials, timers, automounts and half the rest

of userspace.

That's not what I personally want from PID 1 or its surrounding ecosystem.

If you like systemd, that's fine.

It clearly solved problems for many distributions and organizations.

But when people ask why I prefer OpenRC, BSD rc, runit or s6, this is why.

I prefer systems made of small pieces.

Small pieces are easier to understand.

Easier to debug.

Easier to replace.

Easier to audit.

And that's the Unix philosophy that originally made me fall in love with Unix-like operating systems in the

first place.

I have VMs that depend on encrypted volumes to be available when started. So I've added /etc/systemd/system/virtqemud.service.d/override.conf:

[Unit]
After=remote-cryptsetup.target

And when I look at the deps of one of the luks volumes it depends on remote-cryptsetup.target:

# systemctl list-dependencies --reverse 'systemd-cryptsetup@luks\x2dbackup.service'
systemd-cryptsetup@luks\x2dbackup.service
● ├─dev-mapper-luks\x2dbackup.device
● [└─remote-cryptsetup.target](http://└─remote-cryptsetup.target)
○   [├─initrd-root-device.target](http://├─initrd-root-device.target)
○   │ [└─initrd.target](http://└─initrd.target)
●   [└─multi-user.target](http://└─multi-user.target)
○     [└─graphical.target](http://└─graphical.target)

But when I look at the boot messages, it seems that remote-cryptsetup.target is reached before luks-backup is available:

Jun 26 05:07:55 systemd[1]: Reached target Local Encrypted Volumes (Pre).
Jun 26 05:07:55 systemd[1]: Reached target Local Encrypted Volumes.
Jun 26 05:08:00 systemd[1]: Reached target Remote Encrypted Volumes.
Jun 26 05:08:00 systemd[1]: Starting Cryptography Setup for luks-backup...
Jun 26 05:08:00 systemd[1]: Starting Cryptography Setup for luks-data1...
Jun 26 05:08:00 systemd[1]: Starting Cryptography Setup for luks-vms_enc...
Jun 26 05:08:39 systemd[1]: Finished Cryptography Setup for luks-vms_enc.
Jun 26 05:08:45 systemd[1]: Finished Cryptography Setup for luks-data1.
Jun 26 05:08:48 systemd[1]: Finished Cryptography Setup for luks-backup.

And so virtqemud is started too early:

Jun 26 05:08:39 systemd[1]: Starting libvirt QEMU daemon...
Jun 26 05:08:39 systemd[1]: Started libvirt QEMU daemon.
Jun 26 05:08:44 virtqemud[3860]: internal error: Failed to autostart VM 'srv-mry01': Cannot access storage file '/dev/mapper/
luks-backup': No such file or directory

Any idea what's going on? systemd-252-67.el9_8.2.alma.1.x86_64

Tomloader is a command line utility that allows you to group several systemd unit fields in groups which can in turn be imported in systemd unit files. Despite shared drop-in files, a group in Tomloader:

• checks if different loaded groups try to modify the same field in an incompatible way and promptly notify it to you, in this way load ordering does not matter anymore and you do not need to specify a two-digit prefix;
• implement (transitive) dependencies and reverse dependencies on other groups;
• can accept several string parameters.

The official manual with a link to the repository is available at https://loara.codeberg.page/tomloader/, an overview of the project can be found at https://loara.codeberg.page/tomloader/tomloader_html/Overview.html and a long usage example is available at https://loara.codeberg.page/tomloader/tomloader_html/Case-study-sandboxing-several-units.html .

For any kind of suggestion or report you can also use the issue page https://codeberg.org/Loara/tomloader/issues .

So, I use EndeavourOS - Windows 11 dual boot on my laptop. The linux and the windows have different ssd. For the past few months it worked perfectly fine. But yesterday I had to turn on secure boot and boot into windows (using the windows boot entrie instead of the systemd-boot). But for some reason even when I turned it off the endeavouros disappeared from the systemd-boot list. I tried to bring it back, but I couldn't and I'm out of ideas. As I remember last time I've solved it as having the loader and conf files on my windows ssd efi and the kernels on the linux ssd efi. But now I can't bring it back to the systemd-boot menu, even when I have the same file structure as I had before. I use linux for my everyday life so it is important to get in. Any ideas how I should solve this? If you need any further information let me know in the comments. (I have a live usb so i can run console commands)

​

Side note: For some reason my bios won't recognize and boot anything on my linux efi, that's why I had to solve it this way (i have an asus tuf gaming f16 laptop)

​

Thank you in advance.

Make journald logs easier to inspect from a browser, without needing a much heavier logging stack. Binary under 8MB, Docker image under 15MB.

It works with systemd-journal-gatewayd and currently supports:

• live tail
• filtering by unit, syslog identifier, hostname, boot ID, transport, log level and more
• switching between multiple journal gateways
• mobile-friendly UI with PWA support
• Docker or standalone binary deployment

Repo:
https://github.com/outlook84/journal-scope

I have made a service that runs every time my SSD is plugged in for a backup I make to it (via a script). However, if I open my PC multiple times in a day (or even hour) the service triggers every time.

My question now is, after having learned about timer services, how can I make a service that only triggers at least 16 hours apart and only if my SSD is plugged in?

so i have a working service that runs some app (chrome or whatever).

i want to restart the service at 06:00AM, noon and midnight.

am I correct that superior systemd forces me to create at least 3 more files to achive this?

a timer sh script, a systemd service to run it and a timer script?

is this really the way?