override daemon setting for templated instances #101
alois31
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "socket-activation"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
this is necessary for socket activation of daemons connections.
cc @alois31
we've tested this with https://gerrit.lix.systems/c/lix/+/4719 on our machines and it worked as expected. this should be sufficient for a while too, if we add any more socket we'll add them as named alternatives to the one socket unit we have now instead of adding more socket units
@ -17,0 +41,4 @@ExecStop = "/bin/sh -c :";};};systemd.sockets.nix-daemon.partOf = [ "nix-daemon-socket-update.service" ];Why is it needed to restart the socket unit when the
nix.confchanges to begin with? Systemd doesn't read it, only the Lix it will spawn.preparation for the future. we'll want to set posix acls on daemon sockets in the near future. if we use ExecStartPost on the socket unit we need to trigger a restart of the socket unit somehow (which we do here), but we could also move the permission setting into an entirely separate service that is started by the socket unit and changes permissions when
nix.confchanges. both have pros and cons, we chose this method because it'll let us drop the extra service once stc can restart socket units. we can also change it though, anything is fine as long as we can update socket acls whennix.confchangesNo it's fine, just missed that the ACL service is going to happen after all. I will put something similar in the NixOS module then.
no, you make a good point actually. we should check whether the socket is deleted and recreated during restart, because that would be an avoidable service interruption. if it's deleted we should use the acl-setting service instead
should be good now. once we add acls we'll set
lix-daemon-socket-permissionsas wantedby/partof the actual socket and things should just work as expectedOf course I cannot test a change like this, but it looks reasonable and inert for now. Do you think it would be reasonable (with respect to the timing, as I don't know about the plans) to ship a similar change in the NixOS module or should that wait for later?
378b5712491b45edc77fNot tested since I don't use the module, so ideally someone actually using it should do that. The code looks reasonable though.
we have tested the current version with the current cl daemon and found it to work fine