Open Jannik2099 opened 3 years ago
Remote FS? I suppose you use btrfs on iSCSI?
Yes I do. This would also conflict with NBD or (god forbid) loopback on NFS
In a earlier incarnation, it was even started earlier... But I'm not sure about WantedBy
because I don't see it as a multi-user daemon - it does nothing for users...
The man page says we have all important mount points ready at basic.target
. It also says that all late boot-time service should order after this.
For multi-user.target
it says that services need to "want" it if they are required for operating a multi user system. That's not true for bees.
So, I propose that After should changed to local-fs.target at least. But remote-fs.target looks a little bit too special. If you're doing fancy stuff like iSCSI or NBD, then it's probably expected to require some special configuration - also for other services. Drop-ins should work fine here. I'd even propose that a btrfs on iSCSI should probably be mounted through an auto-mount, so that will act as synchronization point for all services trying to access it.
It also says that all late boot-time service should order after this.
oh sorry, I totally misremembered that - ignore the WantedBy part then
But remote-fs.target looks a little bit too special
Where's the hurt in setting it though? It'd delay bees activation by a few seconds until DHCP is configured but provide a more reliable out of the box experience
I'd even propose that a btrfs on iSCSI should probably be mounted through an auto-mount, so that will act as synchronization point for all services trying to access it.
I am mounting it with fstab, however this requires the _netdev mount option (since otherwise it tries mounting before iscsi is ready), which moves it from local-fs to remote-fs
I am mounting it with fstab, however this requires the _netdev mount option (since otherwise it tries mounting before iscsi is ready), which moves it from local-fs to remote-fs
Did you try if adding x-systemd-automount
to the fstab options works for you? If it does, it will setup an automount that triggers the mount on first access, pulling in the required services and pauses the process which triggered all this, until the mount point is ready. So it should act as the synchronization point you're asking for. But I never tried iSCSI, so I'll have to leave it to you to test it. ;-)
I'm using that for all mount points that are only lazily needed, like NFS storage, backup partitions etc. It speeds up booting by a good amount.
An alternative would be to tell the bees@.service
to RequiresMountsFor=
but that's cumbersome if you could instead setup just automounts. Otherwise there's duplicate configuration effort for the bees instances.
beesd finds disks by looking for uuid, not mount path. Hence x-systemd-automount did not work:
INFO: Find 47d3ebf5-6e77-414b-8833-3b6d4cfa5790 in /etc/bees//backup.conf, use as conf INFO: Check: Disk exists ERROR: Missing disk: /dev/disk/by-uuid/47d3ebf5-6e77-414b-8833-3b6d4cfa5790
Yeah, that's a problem I'd rather solve... I moved away from the beesd start script here meanwhile. Actually, bees itself does not need UUIDs at all, it's that script that plays too much magic.
This is what I'm currently using:
$ systemctl cat bees.service
# /etc/systemd/system/bees.service
[Unit]
Description=Bees
Documentation=https://github.com/Zygo/bees
After=sysinit.target
RequiresMountsFor=/mnt/btrfs-pool
RequiresMountsFor=/mnt/xfs-storage
[Service]
Type=simple
Environment=BEESHOME=/mnt/xfs-storage/bees
Environment=BEESSTATUS=%t/bees
ExecStart=/usr/libexec/bees --no-timestamps --strip-paths --thread-factor 0.5 --loadavg-target=5 --verbose=5 /mnt/btrfs-pool
CPUWeight=12
IOSchedulingClass=idle
IOSchedulingPriority=7
KillMode=control-group
KillSignal=SIGTERM
Nice=19
Restart=on-abnormal
RuntimeDirectory=bees
StartupCPUWeight=25
WorkingDirectory=/run/bees
[Install]
WantedBy=basic.target
# /etc/systemd/system/bees.service.d/override.conf
[Service]
Slice=maintenance.slice
IOWeight=10
StartupIOWeight=25
The systemd unit currently uses WantedBy=basic.target , the default is multi-user.target though
Furthermore, the unit may start before remote filesystems are ready. For this, After=sysinit.target has to be replced with After=remote-fs.target