> humble systemd
That the same cannot be said of its maintainer is another matter.
Love systemd timers
31–40 of 309 posts
Re: Love systemd timers
#32Earlier quoted context omitted.
key-value pairs where the = cannot be surrounded by spaces, so I have to write [Service] Type=oneshot WorkingDirectory={{ home }}/current/ Environment=RAILS_ENV=production ExecStart=/bin/sh -lc "bin/db-backup --verbose" which fills me with sadness
What? You absolutely can have spaces; most of mine look more like [Service] Type = oneshot WorkingDirectory = %h/current/ Environment = RAILS_ENV=production ExecStart = /bin/sh -lc "bin/db-backup --verbose"
Friend, you have changed my life
Re: Love systemd timers
#33Even better is systemd socket activation.
This is very interesting. I'm not sure what I'd use it for yet, but I imagine it could be useful for triggering ad hoc jobs over the network. Maybe have Home Assistant make a network call to kick off a daily back up when I leave the office at the end of a work day.
Re: Love systemd timers
#34Timers can work with arbitrary units (not just a similarly-named service unit) so they can be surprisingly flexible. I have a timer on my servers that starts a backup.target that fires off a full "restic backup","restic prune", "restic forget" backup cycle each morning with randomized start times and notifications. The actual restic-* units are Podman Quadlets so the whole setup runs agnosticaly of what's on the serv…
Why do you randomize your backup times?
Re: Love systemd timers
#35Even better is systemd socket activation.
This is very interesting. I'm not sure what I'd use it for yet, but I imagine it could be useful for triggering ad hoc jobs over the network. Maybe have Home Assistant make a network call to kick off a daily back up when I leave the office at the end of a work day.
I believe its original motivation was just speeding up boot times by starting fewer services, even if you'd eventually want the service running. This was achieved in the past with xinetd, but systemd made the approach more popular for the masses.
Re: Love systemd timers
#36Earlier quoted context omitted.
Never thought I'd see hackers saying INI format looked ugly of all things. It's basic, sure, but that's a good thing for something meant to be easily editable by hand from any editor. Otherwise, it's just key value pairs in named sections, how ugly can it be about that?
TOML would look a lot more quiet, but I'm not sure if TOML would be a good fit
unit files barely have any nesting, so the INI-like format is already 90% of the way towards TOML, no?
Re: Love systemd timers
#37systemd is complex on first view, but after using it you didn't want to use anything else. It's handy to manage everything using systemctl
Re: Love systemd timers
#38systemd is complex on first view, but after using it you didn't want to use anything else. It's handy to manage everything using systemctl
That and systemd having actually useful man pages.
Re: Love systemd timers
#39I have a Canon printer, I actually can't trust that their print nozzle won't get jammed up after sitting idle for a while. So I had claude setup a systemd script to print a picture of my dog every week, I ensure it has enough CMYK spectrum to stress the printer. Its a nice surprise every monday as I sit on my desk to see a sudden picture pop up from the printer :)
Re: Love systemd timers
#40Even better is systemd socket activation.
I design all my services expecting to receive sockets this way. It makes sandboxing easy as the service itself doesn't need network access to have a listening socket.
It's a shame docker never supported it. I feel like if they had got on board all those years ago there would be broad support across the software ecosystem for it and we wouldn't need half of these complicated iptables rules and proxies and service mesh. It would be a step towards a capability based system.