systemd on Linux can run your Go webapp only when it actually receives requests. With this, your Go executable will start with the first request it receives - and that first request will succeed. A lightweight alternative to running your service permanently in the background. And maybe also an alternative to deploying local web apps to Desktop systems with something heavy like Electron.
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
○ ├─initrd-root-device.target
○ │ └─initrd.target
● └─multi-user.target
○ └─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