Build a busy hive and make lots of honey in Hive Time, releasing this month https://www.gamingonlinux.com/articles/build-a-busy-hive-and-make-lots-of-honey-in-hive-time-releasing-this-month.15528 #GodotEngine #Simulation #IndieGame #Upcoming
@HexDSL and I am not on crack! https://peertube.social/videos/watch/0c18e708-a739-4f42-954e-0b073be2f236
nderstanding #systemd # 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.
The Linux and gaming Sunday round-up paper is here https://www.gamingonlinux.com/articles/the-linux-and-gaming-sunday-round-up-paper-is-here.15518 #Round-up
Understanding #systemd # 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 #systemd # 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.
Curate your own Fediverse
* Use filters liberally to remove posts that annoys you
* Mute or block other people or bots who get boosted into your timeline if you don't want to see them again
* Try to remember to not click on CW's for stuff that will leave you feeling worse
And you never have to explain why
You can do so for reasons that are entirely "selfish" or "petty"
E.g. "Their jokes were crass so I muted them"
Make the Fediverse a place that's good for you
Understanding #systemd # 11b
Description=Flatpak automatic updater
ExecStart=/usr/bin/flatpak --user -y update
Description=Flatpak automatic updater timer
Understanding #systemd # 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.
The Witcher - Professional Monsterslayer at work [Linux, MoveMaster] https://www.pscp.tv/w/cLKzmDFYSlFrZG9iT3luS0x8MU9kS3JMcGVPWXZKWFtqNUBUB7xcz8cD0t7x_k0gGrpDLXUws5L3QSXBp8_H
Understanding #systemd 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 #systemd # 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 #systemd # 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 #systemd # 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).
I reserve the right to be wrong about EVERYTHING. :-D
Linux Geeks doing what Linux Geeks do..