plasma5: improve kbuildsycoca activation script

[jerith666]

• silence normal output from the command

• avoid running it when the data it wants to update is encrypted

• specify explicit bash in kbuildsycoca5 su command

  when the activation script runs at boot time, the users' default
  shells (typically /run/current-system/sw/bin/bash) will not be
  available. instead, specify an explicit store path for bash.

follow-on to #42910 and #44544

Things done

• Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
• Built on platform(s)
  • NixOS
  • macOS
  • other Linux distributions
• Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
• Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
• Tested execution of all binary files (usually in ./result/bin/)
• Determined the impact on package closure size (by running nix path-info -S before and after)
• Fits CONTRIBUTING.md.

[jerith666]

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?

[worldofpeace]

cc @bkchr

[infinisil]

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

[bkchr]

@infinisil good idea.

[jerith666]

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 ... ?

[infinisil]

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

[peterhoeg]

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?

[peterhoeg]

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

[peterhoeg]

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

[bkchr]

Can we not use a user systemd service for this?

[peterhoeg]

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.

[bkchr]

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

[peterhoeg]

peter@dolores:~ $ echo $DISPLAY
:0
peter@dolores:~ $ unset DISPLAY
peter@dolores:~ $ kbuildsycoca5
Error: could not determine $DISPLAY.
kbuildsycoca5 running...

[vcunat]

I believe this has been superseded by #47842.