#Tag
Okay, hear me out.
#systemd has `systemd-detect-virt`, but what about `systemd-detect-fash`.
Okay, hear me out.
#systemd has `systemd-detect-virt`, but what about `systemd-detect-fash`.
👍 GNOME 49 drops support for non-systemd ; Artix Linux drops support for GNOME
｢ The problem at hand with these lockups will manifest when a #systemd unit reads lots of files from a file-system mounted with the "lazytime" mount option. #Lazytime being the option for only initially updating the access/modify/creation time on the in-memory version of the file #inode to help with performance and reduce writes to disk. The on-disk timestamps are then updated during #fsync and similar operations or when evicted from memory, among other possibilities ｣
Spent my morning figuring out why Nginx was dead on a server with many days of uptime. No reboot, no kernel panic. Just... down. Ubuntu 24.04.
The cause? An automatic unattended-upgrade of libc6. This prompted systemd to work its magic, wisely deciding to restart every running service to apply the patch. Fine.
The problem is, in the exact same minute, the systemd timer for certbot decided it was time to renew certificates.
The result:
- systemd stops Nginx.
- Port 80 becomes free.
- certbot, in standalone mode, immediately grabs it for validation.
- systemd tries to restart Nginx, which fails with "Address already in use".
The web server was knocked offline by its own certificate renewal script.
I swear, this is the kind of cascading failure that has never happened to me in years of running *BSD. With a classic cron job, certbot would have failed, logged an error, and tried again the next day. The web server would have remained untouched.
systemd was doing its job, but something failed because of the interactions.
Sometimes, too much automation and too many interconnected parts just create more spectacular ways for things to break.
👍 GNOME 49 drops support for non-systemd ; Artix Linux drops support for GNOME
Spent my morning figuring out why Nginx was dead on a server with many days of uptime. No reboot, no kernel panic. Just... down. Ubuntu 24.04.
The cause? An automatic unattended-upgrade of libc6. This prompted systemd to work its magic, wisely deciding to restart every running service to apply the patch. Fine.
The problem is, in the exact same minute, the systemd timer for certbot decided it was time to renew certificates.
The result:
- systemd stops Nginx.
- Port 80 becomes free.
- certbot, in standalone mode, immediately grabs it for validation.
- systemd tries to restart Nginx, which fails with "Address already in use".
The web server was knocked offline by its own certificate renewal script.
I swear, this is the kind of cascading failure that has never happened to me in years of running *BSD. With a classic cron job, certbot would have failed, logged an error, and tried again the next day. The web server would have remained untouched.
systemd was doing its job, but something failed because of the interactions.
Sometimes, too much automation and too many interconnected parts just create more spectacular ways for things to break.
🐧 Has the True Alternative to Systemd Just Been Born? | Youtux
C'était bien sûr #systemd le gagnant. Il avait tout mis en read-only pour ce processus.
So there's a decades-old mechanism (and actual standard) how programs lock serial ports on unix-like systems in /var/lock. it's used in practice even in 2025 and #systemd >= 258 simply breaks it with "we don't care". I am not a systemd opponent, but that kind of behaviour [without a prior community-wide discussion or providing patches for known-affected projects and a grace period] is just alienating users and developers https://github.com/systemd/systemd/issues/38563https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1110980 #systemd #debian
Why are there a bunch of different Wayland “compositors?” Why isn’t there just one good compositor that window systems can sit atop? Same with HID management, there should just be one good HID daemon.
Maybe eventually there’ll be a systemd-compositor and systemd-hid to handle this. Seems like they might be good candidates for Rust, too.
Una ayudita para algún experto de systemd. Estoy intentando hacer una unit que corre un script de shell con un usuario que no es root, y el script de shell lo que hace es iniciar un container en podman.
Ya activé el lingering para el usuario. Pero me sale este error:
Aug 22 11:36:06 localhost.localdomain systemd[1188]: create_httpd.service: Scheduled restart job, restart counter is at 5.
Aug 22 11:36:06 localhost.localdomain systemd[1188]: create_httpd.service: Start request repeated too quickly.
Aug 22 11:36:06 localhost.localdomain systemd[1188]: create_httpd.service: Failed with result 'exit-code'.
Aug 22 11:36:06 localhost.localdomain systemd[1188]: Failed to start create_httpd.service - Run an httpd container.
mas info abajo...
Una ayudita para algún experto de systemd. Estoy intentando hacer una unit que corre un script de shell con un usuario que no es root, y el script de shell lo que hace es iniciar un container en podman.
Ya activé el lingering para el usuario. Pero me sale este error:
Aug 22 11:36:06 localhost.localdomain systemd[1188]: create_httpd.service: Scheduled restart job, restart counter is at 5.
Aug 22 11:36:06 localhost.localdomain systemd[1188]: create_httpd.service: Start request repeated too quickly.
Aug 22 11:36:06 localhost.localdomain systemd[1188]: create_httpd.service: Failed with result 'exit-code'.
Aug 22 11:36:06 localhost.localdomain systemd[1188]: Failed to start create_httpd.service - Run an httpd container.
mas info abajo...
Save the date! We'll have another edition of #BoilingTheOcean in Berlin on October 3-5, right after All Systems Go. More details to follow 😎
Save the date! We'll have another edition of #BoilingTheOcean in Berlin on October 3-5, right after All Systems Go. More details to follow 😎
A space for Bonfire maintainers and contributors to communicate
