Core service autostart issues when /opt is on a different partition

[vaardan]

Pre-Submit Checklist:

• Check applicable sources for existing issues:
  • Windows Known Issues
  • Linux Known Issues
  • Github Issues

What happened:
For some unknown reason unit portmaster.service doesn't exist when executing systemctl start portmaster or systemctl status portmaster.

But it does exist when executing systemctl enable portmaster. After executing systemctl enable, both systemctl start and systemctl status see the unit and work as expected.

After the restart, autostart doesn't happen and portmaster.service is once again is "gone" until systemctl enable is executed.

What did you expect to happen?
The core service is able to autostart as expected, without manual manipulations on each boot.

How did you reproduce it?:
Sadly, no clue. I'm completely confused by this systemd unit behavior.

System and installation info
OS: Fedora Linux 40 (Workstation Edition) x86_64
Kernel: 6.11.10-200.fc40.x86_64
Shell: zsh 5.9
DE: GNOME 46.6
Display server: Wayland
Portmaster version: 1.6.10
Installation method: rpm

Did I have portmaster before? Well, sort of. I tried installing it before using rpm and then using the script. Encountered the same issue, and then tried to removed it to the best of my ability.

Did I try to re-install: Yes, doesn't help.

Output of

❯ ls -lah /etc/systemd/system/portmaster.service
lrwxrwxrwx. 1 root root 41 Dec  6 20:58 /etc/systemd/system/portmaster.service -> /opt/safing/portmaster/portmaster.service

The chain of events
After doing install I immediately restarted the system and found out that it did not autostart.

I tried executing the

sudo systemctl status portmaster

and got this error

Unit portmaster.serivce could not be found

Same thing goes for

sudo systemctl start portmaster

After that I tried starting portmaster UI. Upon the start, I was greeted with the message "The portmaster service is not running" and the button "START CORE SERVICE". Clicking the button didn't help, because it tries to execute this command

/bin/bash -c echo SUDOPROMPT; systemctl start portmaster.service --no-pager

which obviously encounters the same "Unit can't be found" issue.

So then I attempted to execute

sudo systemctl enable portmaster

and that didn't return any error.

After that both status and enable worked just fine. This screenshot shows the output of the status after executing enable, but before start:

And this one after executing start:

Then, I tried rebooting my machine, but no autostart happened. enable didn't find the unit. So I decided to try execute enable and start in one command and see if that works:

sudo systemctl enable --now portmaster

it did work.

Finally, I rebooted once again, and found myself in the same situation. I tried starting the portmaster using

sudo /var/opt/safing/portmaster/portmaster-start core

it did start fine as well.

Here's the output of the journalctl -u portmaster for the latest boot (that was performed using systemctl enable). And the shutdown was imitated by the system reboot.
log.txt

There has already been a similar issue #482 reported, but it was 2 years ago. I couldn't re-open it, so I'm creating a new one.

[github-actions]

Greetings and welcome to our community! As this is the first issue you opened here, we wanted to share some useful infos with you:

• 🗣️ Our community on Discord is super helpful and active. We also have an AI-enabled support bot that knows Portmaster well and can give you immediate help.
• 📖 The Wiki answers all common questions and has many important details. If you can't find an answer there, let us know, so we can add anything that's missing.

[vaardan]

More info.

If I invoke

sudo systemctl disable portmaster

Removed "/etc/systemd/system/multi-user.target.wants/portmaster.service".
Removed "/etc/systemd/system/portmaster.service"

(Status check after that shows this):

○ portmaster.service - Portmaster by Safing
     Loaded: loaded (/usr/lib/systemd/system/portmaster.service; disabled; preset: disabled)
    Drop-In: /usr/lib/systemd/system/service.d
             └─10-timeout-abort.conf
     Active: inactive (dead)
       Docs: https://safing.io
             https://docs.safing.io

Then after the restart both systemctl status and systemctl start are able to find the portmaster.service right away.

But then, if I call systemtl enable portmaster and restart the machine, it goes back to square one. start and status can't find the unit, unless enable is called first.

[vaardan]

Ok, the issue seems to be that I have /opt as a separate logical volume. And systemd doesn't really like its units being on different partitions.

It seems that all .service files must be on the root (/) partition for it to work correctly. Meaning, that if you have /opt (or any other other location you've installed portmaster to) on a different partition, you can't just symlink portmaster.serivce from the portmaster directory.

It'd be great, if the portmaster team could handle this edge case in the installers and add warning about it to the wiki page.

Quickfix for those facing the similar issue

You can use the the installer script installation option. It gracefully handles this edge case by placing the real systemd service file into the /etc/systemd/system/portmaster.service, and then symlinking it back to the portmaster folder (i.e. the exact opposite of what the .rpm installer does).

[vlabo]

Thank you for the detailed report.
We are already working on a new installer that will place the executable in the expected location. And hopefully will solve the issue you are having.

Is this something that you have configured for your system? I dont think I have seen Fedora installation that organizes the file system like this.

[vaardan]

@vlabo

Is this something that you have configured for your system?

Yes, this is a manual setup I did so that Timeshift would exclude certain directories from being snapshoted.

I dont think I have seen Fedora installation that organizes the file system like this.

Yeah, it doesn't. Standard setup is just home and root, if I'm not mistaken. I've had that setup before, and didn't experience this autostart issue back then.