I downloaded the latest iso
(https://ci.guix.gnu.org/build/6060923/details from yesterday) and tried
to install opensmtpd in there.
After the reconfigure i got the 'failed to privilege <binary>: Success'
warning but upon reboot things were working.
I think I know what is happening now:
The *first* time we try to privilege something it fails because the
group does not yet exist. After a reboot it is succeeeding because it is
using the group info from the previous boot, because that has not been
recreated yet.
This seems to work for groups because the getgrnam error "group does not
exist" is a 'system-error being caught by the exception handler, while
the getpwnam-error "user does not exist" is a 'misc-error instead,
causing a backtrace which aborts further activation scripts (that would
create the user)
As a simple workaround we could catch the getpwnam error too but this is
not really solving anything and relies on previous state which might be
incorrect. This is also really fragile.
Another idea would be to run the account+user creating scripts as early
as possible. Or as a more thorough solution model the dependency on
users/groups directly to enforce the ordering (might be problematic
because some activation scripts also requrie a user/group to set
permissions which would make the extension graph not acyclic (accounts
-> activation -> accounts). Maybe this is doable with a more minimal
accounts service that only knows about users/group names?
I am surprised this has not been causing issues earlier as also a lot of
direct activation-extensions set ownership on directories (that this
works seems like a lucky coincidence in how
service-extension/service-folding works rather than a design consideration).
