#systemd
I think the more I learn about systemd and the various programs within the suite, the more I like it. I might start using run0 in place of sudo
Finally came around to set up an automatic, encrypted backup on my Linux. When searching online you'll often find that the best option is to store your credentials unencrypted in a plaintext file.
Don't listen to these posts, you can store credentials encrypted in systemd:
After switching to #Niri each time I tried to wake up my #Surface it immediately got suspended again.
Only way to get into system was to spam Alt+Super+F2 to get into console during resume. It got suspended again, but next time I hit the power button, it stayed awake in console.
I was pretty sure that it was something in Niri but not completely sure and quick search didn't help.
It would be pretty short story, but it really seems like I'm incapable of heeding my own advice "never change more things at once". So not only I switched to Niri, but at the same time I moved part of my configuration to #Guix Home and "tuned" my suspend configuration. Completely nuked previous compositor. And removed sddm which I used for login. And I installed Niri from Guix ofc, so I wasn't sure what was the cause. Did I broke suspending? Maybe some problem between #ArchLinux and Guix Home? Systemd Login change? `HandlePowerKey` missbehaviour?
So long story short, last night I finally had some time to look into this and find out that #systemd (which is currently used for suspend) had usefull command `systemd-inhibit --list` and it was immediately clear:
niri 1000 kepi 125538 niri handle-power-key Power key handling block
Ok, it really is Niri. And I looked over the configuration ofc, but I search engines sucks these days and in documentation, I went mainly over bindings configurations and totally missed General Settings in Input section https://yalter.github.io/niri/Configuration:-Input#disable-power-key-handling
So key takeaway? Never change more things at once. I hope that this will be natural and much easier while I'm fully moving into Guix world :)
Second, I installed PHP. This required some undocumented steps (seems like Arch differs in default PHP configuration and packages with Ubuntu (yeah, Movim installation document assumed that one would use Ubuntu or Debian; however, if I were a maintainer I would do the same thing)).
The biggest struggle was UNIX file permissions (and that’s when I remembered that my sysadmin errors were always about permissions).
So, I am using Caddy as a reverse proxy server (instead of nginx or Apache because their configuration is a nightmare, I have been there, nevermore). Therefore I put caddy user and group in systemd service files, php-fpm pools, /var/www folders recursively. Double, triple checked that I haven’t missed anything. And it still didn’t work!
I mean, PHP server was rendering an error page referring to a detailed error message it put in the log. I’m checking the log, it’s empty. Strange.
Для загрузки я использую systemd-boot вместо загрузчика. И почему-то у меня перестало показываться меню. Хотя timeout в loader.conf и стоит.
В чём дело? Раньше-то всё работало. #systemd
Okay, I'm sure a lot of people already know about this one, but it's new to me. I just found out you can do one of these in your systemd service itself:
Environment=SOME_SILLY_NAME=%i
And then reference that specific variable from inside of that environment, instead of using whatever variable was already there anyway, that usually works even though it's not actually made for that.
The problem I've been running into is that X11 cares about $DISPLAY, and so usually if you're gonna reference %i from a script from within an X11 environment, you would use that and it would work; but then if you're on Wayland, that doesn't mean anything to Wayland itself, because it calls it $WAYLAND_DISPLAY instead; WHICH MEANS that if you're on a Wayland compositor to start with, but you're also running XWayland, then you have both variables set automatically.
I'm on Niri with xwayland-satellite, and so I have both (I never had $DISPLAY in Niri until after I installed xwayland-satellite). This is a huge problem because neither of those variables actually have anything to do with the systemd instance by design, and I can't just make one of them go away (without giving myself more problems). There is no variable that's ever set by default, that is specifically put there to refer to the exact same thing as %i does in the unit itself, that I know of.
Now I can just do this instead, and never have to worry about my stuff getting mixed up with my other stuff. 😀
1️⃣0️⃣ Here's the 10th post highlighting key new features of the upcoming v259 release of systemd. #systemd259 #systemd
This one is quick, and basically just a continuation of the previous episode: in order to show the current state of the NvPCRs, you may now use "systemd-analyze nvpcrs". This closely mirrors the existing "systemd-analyze pcrs" that shows you the current state of all regular PCRs.
Haskell/Rust/Bash/systemd is a good combination, right? :myGenuineReaction: :myGenuineReaction: :myGenuineReaction:
My Ubuntu experience ended, welcome OpenSUSE
In the second half of October, I replaced Ubuntu 24.04 with OpenSUSE Tumbleweed. This marked the end of my Ubuntu experience. Well, for the moment, at least, because you never know how tomorrow's going to be.
This decision was not made lightly. After several months using Ubuntu 24.04, I was happy with the system. I was even using GNOME after using KDE Plasma for most of the last few years, because I liked Ubuntu's default experience on that desktop environment and found it better than the default one. [...]
https://infosec.press/brunomiguel/my-ubuntu-experience-ended-welcome-opensuse
Chrome, Xfce и очень страшное кино
Сейчас вы снова убедитесь, что знание языка С сопоставимо с навыками самообороны, поскольку в современном мире мега-корпораций и победившего киберпанка на простых пользователей всем и давно плевать.
I mean, I didn't become a #BSD user overnight. It was an itch in the back of my mind for several years. When I had spare hardware that I wasn't using for anything else, I slapped #OpenBSD on it, and it mostly just worked. Then I had the pleasure of learning a brand new-to-me system, and adapting my various scripts to it.
A couple years later, when I had an opportunity to spend a little less than $200 on another laptop, I asked for a recommendation for one that worked best with #NetBSD, and was recommended the Thinkpad X260, which I'm typing on now.
If it's something you're curious about trying, don't make it an all-or-nothing zero-sum thing. It's a slow burn into increasing nerdiness. 😅
I must say, however, that my exploration of BSD was spurred on by the fusillade of non-sequiturs and logical fallacies I received whenever I questioned the wisdom of trends like #systemd-everything in the Linux space.
weird but #distrobox is not in the @VoidLinux repos. tho it's easy to install, i created this simple project to build an xbps package automatically
https://git.ralen.top/ralen/distrobox-xbps/
if you want to uninstall it, you can use uninstall.sh after packaging, tho simple "xbps-remove distrobox" should be enough - the official script does not seem to contain any different logic for removing containers etc
now i can play factorio and windows games from my void installation through distrobox! lutris doesn't work on #void, tho i could manage to run one of my #wine games with void's wine, but other return some wow64 errors and can only be run with prepackaged proton with umo... so i run them from #lutris from distrobox instead.
had to create user services to run #podman as a user, by default it comes with /etc/sv/podman to be linked to /var/services/podman, starting podman as root, so i *copied* the services' scripts to ~/.config/sv and linked to ~/.config/service/, and now podman runs from my user, and i can access it fine with podman-tui
so #runit services are just sets of scripts, basically you need the /var/service/name/run (~/.config/service/name/run) - executable sh script which starts the needed daemon as soon as the file is detected, and /etc/sv (~/.config/sv) is a directory where these scripts are stored
/etc/runit contains scrpts that are run at startup and shutdown, it's easy to create a custom script. for example, i have a script hx /etc/runit/shutdown.d/6-save-backlight.sh which has only 2 lines: mkdir and brightnessctl get > file, and /etc/runit/core-services/12-restore-backlight.sh that set's the brightness with brightnessctl if the file exists. and it just works! #systemd really overcomplicates things, runit is much more intuitive and easy, and everything i need is working just fine
#linuxgaming #voidlinux
I wonder if #keepinitreal is more used for keepin' it real or complaining about the #systemd #pid1 that also does init on the side
Ok, that's kinda messed up.
The latest (and basically brand new) release of #mxlinux now comes with #systemd by default:
MX-25 "Infinity" was released on 9 November 2025 and was built on Debian 13 "trixie". [...] All releases are available with Systemd. The Xfce, Xfce-AHS, and Fluxbox releases are also available in sysVint variants.
—MX Linux Wikipedia page, emphasis added.
More and more of the #ShoveOffMitigation (see explanation) of non-systemd distros in effect
I don't even care much about systemd-init. It's just the wholesale terraforming of #userspace that's concerning. At this point, systemd is already a bigger part of "Linux" than #GNU is.
Hey #devops, #selfhosting, #linux and #systemd people!
I have Ubuntu 24.04.3 with encrypted root and two encrypted partitions mounted at /srv/disk[0|1]
All 3 are remotely unlocked at boot using same key with keyscript=decrypt_keyctl. Unlock is handled via dropbear by semiautomatic tool with access to shared secret storage, where host specific encryption keys are stored.
I want to get two things at the same time:
1) if any encrypted partition is missing, host must boot regardless of that and preferably with as little timeout as possible
2) if encrypted device failed to mount due 1) or due failed unlock, mount point must be masked, to avoid any containers that might have mounts there to access them. Sadly` chattr -I` doesn't help here, because mount point is still readable by root. Yeah, root, I know but rootless docker doesn't play well with swarm and k8s is too expensive to run on my scale.
Basically, I need a degraded host that can accept *some* of scheduled workload
What’s the right approach here?
So far I tried removing fstab entry for `/srv/disk[0|1] `and adding explicit mount units
[Unit]
Description="/srv/${disk_name} filesystem"
Requires=systemd-cryptsetup@${disk_name}\x2ddata\x2dcrypt.service
After=systemd-cryptsetup@${disk_name}\x2ddata\x2dcrypt.service
ConditionPathExists=/dev/mapper/${disk_name}-data-crypt
[Mount]
What=/dev/mapper/${disk_name}-data-crypt
Where=/srv/${disk_name}
Type=ext4
Options=defaults,errors=remount-ro
[Install]
WantedBy=local-fs.target
and extra `mask-srv@.service`
[Unit]
Description=mask /srv/%i if /dev/mapper/%i-data-crypt is missing
DefaultDependencies=no
After=cryptsetup.target systemd-cryptsetup@%i\x2ddata\x2dcrypt.service target srv-%i.mount
Before=local-fs
ConditionPathExists=!/dev/mapper/%i-data-crypt
Conflicts=srv-%i.mount
[Service]
Type=oneshot
ExecStart=/usr/bin/mount -t tmpfs -o ro,mode=000,nr_inodes=1,size=4k tmpfs /srv/%i
[Install]
WantedBy=local-fs.target
But I it seems to have race condition between srv-disk0.mount and I can't figure out right set of dependencies between units here