gerowen

Systemd has all sorts of options. If a service has certain sandbox settings applied such as private /tmp, private /proc, restricting access to certain folders or devices, restricting available system calls or whatever, then systemd creates a chroot in /proc/PID for that process with all your settings applied and the process runs inside that chroot.

I’ve found it a little easier than managing a full blown container or VM, at least for the things I host for myself.

If a piece of software provides its own service file that isn’t as restricted as you’d like, you can use systemctl edit to add additional options of your choosing to a “drop-in” file that gets loaded and applied at runtime so you don’t have to worry about a package update overwriting any changes you make.

And you can even get ideas for settings to apply to a service to increase security with:

systemd-analyze security SERVICENAME

I just host everything on bare metal and use systemd to lock down/containerize things as necessary, even adding my own custom drop-ins for software that ships its own systemd service file. SystemD is way more powerful than people often realize.

I’ve had very occasional issues with it not uploading new photos in a timely manner in the past. I haven’t had any issues in a long time, but I have gotten into the habit of explicitly opening the app, clicking “Uploads” and hitting refresh and making sure everything has been uploaded.

I’m not really sure what causes it, though if I had to guess Android is putting the app to sleep in the background so it may have something to do with power saving settings. I’ve switched to the F-Droid version of the app and manually disabled the appropriate power settings as a just-in-case, though that may have nothing to do with anything.