Service not starting after condition is met

Help
1

I have a zfs pool which is not always available.
After booting I have/want to manually import the pool after unlocking the luks disks.

The config below prevent the service from starting.

    systemd.services.syncthing.unitConfig.ConditionPathIsDirectory = [ "/someDir" ];
    systemd.services.syncthing-init.unitConfig.ConditionPathIsDirectory = [ "/someDir" ];

But it won’t start the service after the directory was made available.

Does anyone have an idea?

2

from your comment i’m not sure if you’re asking “why doesn’t this work?” or “how do i make this work?”

“why doesn’t this work?” - these conditions are checked when the service starts… they don’t imply some sort of process which waits for them to be created and then starting the service - so everything is working as intended with your config here

“how do i make this work?” - probably RequiresMountsFor

good luck!

1 Like
3

tried

    systemd.services.syncthing.unitConfig.RequiresMountsFor = [ "/someDir" ];
    systemd.services.syncthing-init.unitConfig.RequiresMountsFor = [ "/someDir" ];

But it created the directory and starts the service.
It should wait for the directory to appear.

4

That’s not how services fire. What’s actually happening is the service attempts to fire when multi-user.target is reached, like you’ve declared. It sees the condition, sees that the path doesn’t exist, and immediately stops without executing anything. Now, even if the path appears, it won’t suddenly restart.

To make it work how you want, you should align it to fire after the respective mount unit comes online. In your case, it would be someDir.mount.

EDIT: One idea for that would be RequireMountsFor.

5

ah sorry about that

i guess you’ll need to figure out what systemd units take care of luks and then after is your answer…

6

Another option is to use a path unit, which watches for a path to become available, then fires the respective service unit. Depending on how the LUKS stuff happens, doing it this way might just be easier.

7

No, it’s wanted by multi-user.target. That means that when mutli-user.target is queued, so will this service. This service doesn’t wait for multi-user.target to be reached unless it had after = [ "multi-user.target" ]; (which is generally not something you should do).

There’s a couple of reasons that RequiresMountsFor isn’t helping here. First of all, the default dependencies of services (i.e. services that do not have DefaultDependencies=no set) already includes local-fs.target, which includes any automatically mounted file systems you have configured, so RequiresMountsFor is (usually) redundant for such services. Secondly, ZFS datasets are usually mounted with zfs-mount.service, not with systemd mount units; i.e. you’re probably not configuring fileSystems i.e. /etc/fstab for your ZFS datasets and instead you probably just have mountpoint=/someDir on them, which means there’s no generated mount units for RequiresMountsFor to operate with anyway.

But most importantly, I think you’re going about this the wrong way around. You want it to be that this service can run when that dataset is mounted, you don’t want it to be that this service runs as a part of bootup. i.e. You don’t need a dependency on the mountpoint, you need a trigger. This is what path units are for.

systemd.paths.syncthing = {
  wantedBy = [ "multi-user.target" ];
  pathConfig.PathChanged = "/someDir";
};
systemd.services.syncthing = {
  wantedBy = lib.mkForce [ ];
  unitConfig.ConditionPathIsMountPoint = "/someDir";
};

I’ve combined a few things here. First, there’s a path unit whose name matches the service unit that it should trigger. It watches for /someDir to change at all and starts syncthing.service when it does. When it does so, syncthing.service will check that the path is a mountpoint with ConditionPathIsMountPoint to make sure it’s actually the dataset as you wanted. You could use other conditions, like serviceConfig.ExecCondition, to be smarter than that if you want. I’ve also overridden wantedBy so it doesn’t try to start itself on boot; it should only start when triggered.

5 Likes
8

Thank you for the explanation.

I had to use pathConfig.PathExists instead of pathConfig.PathChanged

now it works for syncthing and restic.

# Syncthing:
        systemd.paths.syncthing = {
          wantedBy = [ "multi-user.target" ];
          pathConfig.PathExists = "${zfsDatasetPath}";
        };
        systemd.services.syncthing = {
          wantedBy = lib.mkForce [ ];
          unitConfig.ConditionPathIsMountPoint = "${zfsDatasetPath}";
        };


# Restic:
        systemd.paths.restic-rest-server = {
          wantedBy = [ "multi-user.target" ];
          pathConfig.PathExists = "${zfsDatasetPath}";
        };
        systemd.services.restic-rest-server = {
          wantedBy = lib.mkForce [ ];
          unitConfig.ConditionPathIsMountPoint = "${zfsDatasetPath}";

        };
        systemd.services.restic-backups-local = {
          unitConfig.ConditionPathIsMountPoint = "${zfsDatasetPath}";
        };
1 Like