What are /r/systemd's favorite Products & Services?

From 3.5 billion Reddit comments

> Primary: Where can I read about the valid values for /etc/systemd/sleep.conf ?

These are not documented by systemd, because they depend on your kernel version and configuration. You can actually read /sys/power/disk and /sys/power/state to see what values are available.

They are documented in the kernel documentation. It would be good to have this referenced in systemd's documentation.

> Secondary: How do I always hibernate on sleep?

It's not quite clear what you mean by "sleep", since that isn't actually one the four power-saving modes systemd knows about.

The systemctl utility has suspend, hibernate, hybrid-sleep and suspend-then-hibernate verbs, which essentially trigger suspend.target, hibernate.target, hybrid-sleep.target and suspend-then-hibernate.target respectively.

You will note the sleep.conf file has default values commented out:

#HibernateMode=platform shutdown #HibernateState=disk

These are the settings used when the hibernate.target is started (actually, it's systemd-hibernate.service; this is brought in by that target). If you want all of the power-saving modes to work the same, just copy these values to SuspendMode=/SuspendState= and HybridSleepMode=/HybridSleepState=`, and then there will be no difference between any of them.

I don't know of any read made tool to rebuild your .identity file. But https://systemd.io/USER_RECORD/ and https://systemd.io/HOME_DIRECTORY/ contain all the info you need to rebuild it.

The details depend on the encyption you used, if any. If you were using LUKS then there is another copy in your LUKS records you could use without needing to generate a new file.

> I've set up my desktop system to connect automatically to Ethernet and VPN, and it does. But I suspect there is no guarantee that every single access during system startup and login will go through the VPN. Early accesses may be leaking my IP address to destination sites, and revealing domain names or destination IP addresses to my ISP, for example.

> Has anyone tested this ? Is there such a guarantee ? Does systemd have the concept of guarantees or policies that will be followed ?

systemd does interact with your use case to some extend. But from my reading your use case is not the focus of systemd so you won't find a ready made solution.

There are some tools for you in the systemd documentation.

However, if I was looking for some sort of guarantees I would start looking into Linux networking namespaces. My Idea being that you put most processes in a networking namespace that only allows access to the VPN interface and doesn't allow access to the real network interface. systemd user units might help with that. I haven't done it myself though.

> Maybe I could make a feature request ?

I suggest you do.

Based on my knowledge of how the journal file format works, I'm pretty sure that this would only be possible by completely rewriting the existing files; i.e. by replaying the existing entries out into a set of new files. The data structures used by the journal are specifically designed to only support append operations. Having data structures that allowed arbitrary changes to the stored set of entries would make the data structures larger and more complicated, and this would penalise everybody that didn't need this facility.

(I should point out that this is essentially what you have to do when dealing with text files, so it's not as if the journal is any "worse" at this than plain text files. There's no way to punch out specific lines from a text file and leave the remaining lines alone.)

Consider the following snipped and change to your needs....

[Unit]
Description=ProtonVPN CLI Auto-Start
Wants=network-online.target

[Service]
Type=forking
Environment=SUDO_USER=<user where protonvpn is initialised>
ExecStart=/usr/local/bin/protonvpn c IS-DE#1
ExecReload=/usr/local/bin/protonvpn c IS-DE#1
ExecStop=/usr/local/bin/protonvpn disconnectRestart=always

[Install]
WantedBy=multi-user.target

Follow the link in my previous answer...