Before this change, at boot, I saw errors like this for each user:

Aug 14 22:29:27 alpha stage-2-init: Cannot execute /run/current-system/sw/bin/bash

Now I'm getting errors like this for each user:

Aug 17 21:03:45 alpha stage-2-init: Error: could not determine $DISPLAY.
Aug 17 21:03:45 alpha stage-2-init: "applications.menu"  not found in  ()

... but I'm not sure we even really want/need to do this step at boot?

cc @bkchr

Actually, why don't we just use a systemd service for this? Would make it a lot cleaner and avoid activationScripts, and the problems you mentioned along with it

@infinisil good idea.

I'm not sure I see how a systemd service would ensure that it gets run for the current user on nixos-rebuild switch though ... ?

Make the service config depend on something that changes when the list of application changes, then it gets restarted automatically along with the nixos-rebuild

So the issue with activation scripts is that they run pretty early during boot (ref the issue above) so we really shouldn't be doing su $USER as part of that for a range of reasons:

• $HOME is not necessarily ready yet (dm-crypt, /home on nfs)
• we only process the nixos defined users. Those in LDAP are left out
• some of the things we run (such as kbuildsycoca) will try to open a connection to the X server

A system level service will not know about the individual user variables (such as $DISPLAY) but one way we might be able to deal with this is to use path activation.

Let's say the activation script (which runs as root) was to do something like this:

for d in /run/user/* ; do
  touch $d/activate
done

That would work for all currently logged on users, regardless of where they came from.

And we then have an activate.path like this (for users, not system):

[Unit]
Description = Trigger user specific activation script

[Path]
PathChanged = %t/activate
Unit = nixos-activation.service

And the corresponding service:

[Unit]
Description = User specific activation script

[Service]
Type = oneshot
ExecStart = full_path_of_the_script_that_does_the_magic

All of this is completely untested but I wanted to throw the idea out there.

Comments?

We could also use dbus of course, but this seems much simpler.

Looping in @bkchr who wrote the initial bits for the call to kbuildsycoca. Sorry about the comment spam guys.

Can we not use a user systemd service for this?

Can we not use a user systemd service for this?

Well, a system service will give us the problem with running things on behalf of users (DISPLAY for one). What I propose above is using a user systemd service that just gets triggered by the presence of a file.

Do we need $DISPLAY? I don't thing so.

I believe this has been superseded by #47842.