I am looking for strategies how to manage enabling and disabling of systemd services on a read-only filesystem. It's not possible as the multi-user.target.wants directory contents get modified.

Keeping /etc/systemd/system as the default location for services, has anyone tried ways to manage the launch 'table' / multi-user.target.wants directory such that an application or script running on the target can still enable or disable a specific service (or services) even though the filesystem is RO?

I have thought to symlink the multi-user.target.wants directory to a location on a small rw "config" partition and switch between pre-set multi-user.target.wants directories on boot/reboot according to the need. Alternatively, I suppose a script or application could directly modify this symlinked location by adding or removing entries from it.

I have not tested that yet; I wanted to see if anyone has experience with this, possible strategies, or know of a more standardized approach to this? Thank you.

  • Since filesystem is readonly, you will not be able to make user.target.wants a symbol link. Enabling or Disabling services means permanently change config, which requires a writable filesystem. Try to use an overlayfs as your root filesystem Commented Jul 21, 2022 at 16:37
  • Thank you for this suggestion. I need to enable dm-verity on the rootfs and this is the reason to pursue read only. Do you know, is it possible to use dm verity with overlay fs (can it be targeted to only apply to the lower fs)?
    – chameleon
    Commented Jul 21, 2022 at 17:03

1 Answer 1


Not a full answer, but too much detail for a comment.

To make a change, you need write access to that filesystem. I'm guessing you have write-access now, but you want to lock-it-down read-only while still being able to make these changes later.

systemd will search for unit paths in several places in /run which will not be read-only. There may be an opportunity for you to load a service very early and create/edit some units in one of these load paths:

Reference: https://www.freedesktop.org/software/systemd/man/systemd.unit.html#Unit%20File%20Load%20Path

Path Description
/etc/systemd/system.control Persistent and transient configuration created using the dbus API
/run/systemd/system.control "
/run/systemd/transient Dynamic configuration for transient units
/run/systemd/generator.early Generated units with high priority (see early-dir in systemd.generator(7))
/etc/systemd/system System units created by the administrator
/run/systemd/system Runtime units
/run/systemd/generator Generated units with medium priority (see normal-dir in systemd.generator(7))
/usr/local/lib/systemd/system System units installed by the administrator
/usr/lib/systemd/system System units installed by the distribution package manager
/run/systemd/generator.late Generated units with low priority (see late-dir in systemd.generator(7))

It may be possible for you to write an application which runs very early during boot which connects to a socket to your command-center, gets instructions for units, then uses the dbus-API to create units in /run/systemd/system.control

Another option is writing a generator. See systemd.generator(7) for details. Generators are programs that are executed by systemd early in the boot-process (before unit files are loaded). These generators are expected to generate unit files, drop-ins, or symbolic links in places like /run/systemd/generator/. That would be outside of your read-only filesystem.

An example of a generator is systemd-fstab-generator which reads /etc/fstab and generates native systemd *.mount units.

  • thank you very much for this detailed response. I will review this in detail next week when I have more time. I suspect I can find my solution somewhere here!
    – chameleon
    Commented Jul 22, 2022 at 15:16

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .