Closed talyz closed 2 years ago
I'm using this PR, and I'm seeing this behavior.
...
updating GRUB 2 menu...
activating the configuration...
mount already exists at '/etc/machine-id', ignoring
reloading user units for cole...
setting up tmpfiles
Frustratingly there's a sort of silent rollback there and the new generation is not activated or marked as the running generation. I guess I can just reboot after I set the system profile every time, but that's not ideal...
Seems like it fixed it!
Great! Thanks again for trying it out!
What's the state on this PR? Is it going to be merged soon?
I think it's done, but I would prefer to get some more testing and reviews before merging it.
Ping @etu @lovesegfault @cole-h
I'm going to test this today without fault.
Seems to be working AOK :)
bind-foo
, link-bar
, instead of bindOrLink-foo
, bindOrLink-bar
impermanence
on them would be good? This way a user knows what they are when looking at systemctl
@lovesegfault I think having impermanence-
as a prefix is necessary to be able to distinguish between link-foo
and bind-bar
while still having a simple "namespace".
@lovesegfault Well, the problem is that we don't know wether we'll link or bind mount until the service runs, so I think bindOrLink
is as accurate as it gets. We could of course append impermanence
or maybe persistence
, since that's what the option is called. It would make the names very long, but maybe that's okay.
@lovesegfault Well, the problem is that we don't know wether we'll link or bind mount until the service runs, so I think
bindOrLink
is as accurate as it gets. We could of course appendimpermanence
or maybepersistence
, since that's what the option is called. It would make the names very long, but maybe that's okay.
How about just persist-$path
?
Yeah, that sounds good!
@lovesegfault Changed! :)
@cole-h All done! I kept the names of the ExecStart
and ExecStop
scripts, since I found the names more descriptive than something like persist-start-*
, but all the other instances were changed.
Thank you for tackling this @talyz!
Manage files by creating a systemd oneshot service for each file. The service links or bind mounts the file as appropriate on start and removes the link or unmounts it when stopped. Whether a symlink or bind mount is used is determined by if the target exists - if it does, it's bind mounted, otherwise symlinked. To make sure files are available early enough, also run the start portion in the activation script.
This lifts the restriction on files being placed in
/etc
and should finally close #1.