ChanServ changed the topic of #nixos-systemd to: NixOS <3 systemd | https://jitsi.nixcon.net/systemd | Next meeting 08.12.2020 14:00 UTC (every two weeks)
<lukegb>
andi-: I'm tempted to just write a program that makes the systemd service calls directly
<lukegb>
but yes
<Mic92>
andi-: yes
<Mic92>
especially on my server which has many services not so much on my other machines
<andi->
For me it turned out to be once service that never finished starting (type was one-shot)
<andi->
s/once/one/
<gchristensen>
I wonder if that would cause problems with ordering, which perhaps systemd handles correctly when it knows the full scope
<gchristensen>
oh your comment nvm
<andi->
Ordering is already totally f*cked
<andi->
Only way to properly switch is to reboot ;-)
<Mic92>
Especially this would help with acme services that have no dns access on rebuild for some time
<andi->
Yeah
<andi->
See a few months ago when I had the discussion with dam/jan in here about that and a solution.
<andi->
IMO it is a systemd bug but those seem to think our use-case is weird.
<Mic92>
I wonder how it would be to re-implement the dependency ordering that systemd does and have our own diff engine to restart services
<andi->
The problem is that targets, once they are reached, have been reached forever.
<andi->
Unless you stop a target (which you do not want to do while switching (unless it disappears?!)) you can't re-run it's dependencies
<andi->
So we would have to look at which services (of which target) are long-running (aka still active) and restart those based on the reconstructed target ordering.
<andi->
At that point I wouldn't want to write the code as that logic should be in systemd.
<andi->
How are they handling switching ostrees with different service sets?
<gchristensen>
maybe we rename multi-user.target to multi-user-HASH.target
<andi->
arianvp already tried that and used `systemd isolate multi-user-<hash>.target`
<andi->
but that also tears down your X11
<andi->
and your SSHd
<gchristensen>
finally, the ideal computer
<andi->
for some of us, yes
<gchristensen>
;)
tlater[m] has quit [Quit: Idle for 30+ days]
<gchristensen>
andi-: yesterday(?) you said it was probably an antipattern to use package's systemd unit files out of th ebox
<gchristensen>
today, I think I came across a package updated to use automatic systemd units not in our systemd
<gchristensen>
so I'm inclined to agree :P
<gchristensen>
oh ... maybe I'm nuts. I dunno what I'm talking about.
<andi->
gchristensen: have a link to the PR?
<gchristensen>
ehh I just need to look a bit closer first