ozoned boosted
ozoned boosted
ozoned boosted
ozoned boosted

While working on the #HiveTime release date trailer last night, I recorded myself playing to first Queen with a modest sized hive, no HUD, and no role cell upgrades. Here's 52 minutes of gameplay compressed down to 52 seconds :) #gamedev #indiedev

ozoned boosted

nderstanding # 13 addendum

Just a FYI dbus is NOT a part of systemd. It was created for Gnome, so while technically not systemd, systemd depends on it so much that they're basically inseparable.

There was work to get a kernel dbus, but it was rejected by the kernel folks. So the systemd folks are working on dbus-broker which is fully backwards compatible with dbus, but as is systemd tradition, is more expansive and better suited to systemd and other applications.

ozoned boosted

Understanding # 13

As systemd isn't actually one giant blob, it's made up of tons of smaller parts, it talks amongst itself as well with other applications via dbus.

dbus is an IPC, InterProcess Communication, device. You can run a 'busctl' to see everything currently connected to the bus.

This is why you NEVER restart dbus as then everything has to manually reconnect to the bus and a vast majority of applications don't know to reconnect. systemd has mechanisms to reconnect though.

Understanding # 12

systemd inherently gives you logging for your service started via systemd. Anything going to stdout will automatically be picked up by the journal.

The journal also opens /dev/log so is the system's standard logger.

The journal is systemd's logging mechanism. It is in a binary format, but you can access it's data via the 'journalctl' command.

Some distros have a rsyslog module that pulls data out of the journal so you have your standard rsyslog features.

ozoned boosted

Curate your own Fediverse 

ozoned boosted

linuxrocks.online is great. I can nerd out and no one judges me

Understanding # 11b

Example:

# /etc/systemd/system/flatpak-automatic-updater.service
[Unit]
Description=Flatpak automatic updater

[Service]
Type=oneshot
ExecStart=/usr/bin/flatpak --user -y update
User=desktop

# /etc/systemd/system/flatpak-automatic-updater.timer
[Unit]
Description=Flatpak automatic updater timer

[Timer]
OnBootSec=5m
OnUnitInactiveSec=1d
OnCalendar=*-*-* 00:00:00
Persistent=true

[Install]
WantedBy=graphical.target

Understanding # 11a

Instead of cronjobs, systemd has timers. They can be used to call service unit files.

systemd inherently knows how to use the timer with which service as they share a name. For instance the "MyCustomService.service" would have "MyCustomerService.timer" and systemd then just knows that the timer fires off the service.

ozoned boosted
ozoned boosted

Understanding optional

This is SUPER important! ALWAYS ALWAYS ALWAYS have great tunes going while troubleshooting systemd.

It'll keep you sane. ;-)

I personally recommend Sylvan Esso Radio on pandora as it's super chill. 😄

Understanding # 10b

Instead you should use the User= and Group= directives to tell systemd that your application needs to run as a specific user.

This does NOT do a login process, so you'll stay in the systemd.slice, so you will NOT have that user's environment variables, but that's what Environment= and EnvironmentFile= come in to play.

Check out 'systemd-cgls' for a great way to view cgroup topology.

Understanding # 10a

NEVER run a switch user inside of a script that you're using with ExecStart.

This one isn't as obvious to most folks and there are plenty out in the world that don't realize their set up is broken.

If you do a switch user that does a login 'su -' or 'runuser -l' you're falling through the pam stack and calling pam_systemd.so which is moving you into the user.slice instead of system.slice (a cgroup abstraction).

You WILL experience issues on shutdown.

Understanding # 9

Another contrary to popular belief, when you use PIDFile directive systemd does NOT create OR delete the pidfile.

This pidfile MUST be created by the application and systemd just uses this directive to help it find the proper parent to track.

systemd, however, is VERY particular about the pidfile owner and location as it is a security issue having these things all willy nilly everywhere (and yes willy nilly is a technical term).

Show more
LinuxRocks.Online

Linux Geeks doing what Linux Geeks do..