Check out my first novel, midnight's simulacra!

Systemd: Difference between revisions

From dankwiki
No edit summary
No edit summary
Line 22: Line 22:
* ~/.local/share/systemd/user/: package-originated, user-installed units for that user's sessions
* ~/.local/share/systemd/user/: package-originated, user-installed units for that user's sessions
* /usr/lib/systemd/user: package-originated, admin-installed units for user sessions
* /usr/lib/systemd/user: package-originated, admin-installed units for user sessions
===See also===
* [https://blog.darknedgy.net/technology/2020/05/02/0/index.html systemd: ten years later]

Revision as of 00:35, 6 May 2020

I try not to be judgmental, but if someone's complaining about "the good ol' SysVinit days", they're pretty much an idiot. systemd has its flaws, but it's infinitely better than what came before, not an insult ala Upstart, and actually got things moving, so I'm a big fan.

Remember, changes to systemd files are only reflected following systemctl daemon-reload!

Recipes

  • Reboot to system configuration (i.e. UEFI config): systemctl reboot --firmware-setup

System instance

Paths

In descending priority:

  • /etc/systemd/system: results of systemctl enable and system unit extensions
  • /run/systemd/system: runtime, systemd-originated units
  • /usr/lib/systemd/system: package-originated system units

User instances

When enabled, pam_systemd launches a single systemd --user instance for a user's first login, which is killed when that user's last login exits. User units can neither depend on nor reference system units.

Paths

In descending priority:

  • ~/.config/systemd/user: user-originated units for that's user sessions
  • /etc/systemd/user: system-wide admin-originated units for user sessions
  • ~/.local/share/systemd/user/: package-originated, user-installed units for that user's sessions
  • /usr/lib/systemd/user: package-originated, admin-installed units for user sessions

See also