»Oook, ich mach kurz nen cronjob«
Cronjob läuft nicht
»Is ja gut, ich mach’s richtig und nehm nen systemd timer«
Timer läuft.
Danach seh ich ne Mail von cron, dass der Programmname nicht gefunden wurde. Habe $PATH vergessen…
Whatever, der #systemd timer lief natürlich einfach sofort. Ich sollte nicht dieser Versuchung erliegen, dass es mit diesem legacy-Zeug schneller geht. Tut's nicht. Und Systemd ist toll!
You know, I guess I don't really have an issue with systemd, at least not one worth getting worked up about.
Some folks get really philosophical about it, but honestly, that’s not me. I mean, sure, I’m aware of the debates and all the noise, but personally? I just let it do its thing.
Maybe deep down I care… or maybe I just can’t be bothered to pretend I do. Either way, I’m not losing sleep over it.
1. Go into thread
2. Comments "systemd bad"
3. Refuses to elaborate
4. Leaves
https://social.linux.pizza/@pid_eins@mastodon.social/112353324622157546
New to #mkosi-initrd? It’s more than a #dracut alternative; it’s a #dev-friendly, RPM-driven #initrd builder with future potential. Integrated in #systemd
Builds from known sources
Still maturing (arch/feature limits)
Explore the pros/cons from this #oSC25 talk https://youtu.be/p78J3Ql7D6s?si=JbKZpq9fFb3Oesr9
We got to work with the #systemd team to strengthen Linux
DNS lookups on Linux need to be so fast you don’t notice them, without compromising security. Our team recently helped:
extend test coverage
ensure edge cases are covered
and fix some parser bugs
Discover more about DNS security, what we did in detail + get a look at the tests we added on our blog: https://neighbourhood.ie/blog/2025/07/23/nh-stf-s01e04-systemd
The #ubuntu login loop that I encountered about a month ago is caused by specifying dependencies in a systemd automount file.
The visible symptom is a GDM login loop.
Another symptom is that /tmp/.X11-unix and /tmp/.ICE-unix will be owned gdm/gdm, instead of root/root. Changing the ownership to root/root fixes the login loop, but it returns after the next reboot.
All the gory details are spelled out here.
New blog post!
I've been using TLS certificates generated by Tailscale to access my self-hosted, private services with HTTPS for some time now, but there is one problem with them: they do not auto-regenerate.
So I used some bash and..
*thunder*, *ominous music*
systemd
to create an automated task that autoregenerates them periodically.
To crank the fun to 11, I also use https://ntfy.sh to notify me if the task succeeded or not
https://stfn.pl/blog/78-tailscale-certs-renew/
#blog #tailscale #systemd #lxc #nextcloud
Is it somehow possible to specify additional options to #journalctl's grep function?
I usually need some sort of `grep -C` for logfiles and it looks like that isn't possible using only journalctl options.
i started to understand the reasoning behind #systemd a lot more when i remembered that some people administer not just one or two (or even a dozen) linux machines, but have networks with hundreds, if not thousands, of them, and the technical/maintenance costs of any hacks that one might otherwise accept on a more traditional system multiply to become quite serious issues at that point
One of the most important feature for #NixOS in new #systemd258 #systemd is this
> * ExecStart= lines (and the other ExecXYZ= lines) now support a new '|'
prefix that causes the command line to be invoked via a shell.
https://github.com/systemd/systemd/releases/tag/v258-rc1
currently, NixOS has a `systemd.services.<name>.script` directive, that wraps everything into a Bash script with `set -e` and uses the `systemd.services.<name>.path = [ pkgs.curl ];` as a path. Soon you can write
`systemd.services.<name>.serviceConfig.execStart = ''|
for i in $(seq 42); do echo "Hello $i"; done
'';`
instead. This has the benefit of directly showing the script when using `systemctl cat <name>` and also one file less wrapped around.
Negative part of course is, with `script` you can also call the generated ExecStart line now.
Also I wonder if `ExecStop = "+| my root script"` will work or is it going to be "|+"?
Don’t systemd-analyze fdstore podman.socket, it crashes your PID 1
I haven’t actually checked if any other units would also do this if substituted for podman.socket, but it is consistently reproducible with podman.socket across NixOS on bare metal, Ubuntu in a container, and Fedora in a virtual machine
#TIL I learned, why my debian #Python #systemd service output wasn't live updating in journalctl. This was a problem which I "temporarily" solved by using screen or tmux when I need to follow the output live. (= for about a decade or so...)
Turns out I just need the flag "-u" for unbuffered output and to set the StandardOutput/-Error to "journal" (which should be the default anyway)
And then suddenly after reloading "sudo journalctl -fu my_service" will produce a live, updating output.
Manage Linux Systemd Services Easily With Systemd-manager-tui
“Managing services on a Linux system often means typing long systemctl commands or digging through logs with journalctl. But what if you could do all that from a single, easy-to-use terminal interface? That’s where systemd-manager-tui comes in.”
...continues
See https://gadgeteer.co.za/manage-linux-systemd-services-easily-with-systemd-manager-tui/
I'm trying to figure out setting up an email (SMTP) service on my little hosted machines, so I don't need to rely on any particular mail provider.
Which leads me to thinking I really like how #Podman can generate #SystemD units to automatically manage the service containers.
And that has led me to the conclusion I probably should wait for #Debian Trixie release next month, when I can migrate past Podman 4.3.
How do you manage SMTP service for yours, @mike?
Long story short, I broke my #Linux installation. Let me know if you can relate x)