Wrapping activation scripts into subshell?

Development
1

Hi,

I stumbled a number of times over various influences between multiple activation scripts. At the moment they are simply concatenated strings and have no semantic barriers. I think this is to optimize for performance which I completely support.

However, we had a few scripts that required setting umasks and the activation script early on sets up a umask that is “promised” to the snippets so that one has to take care of not influencing other scripts.

Is there a reason not to simply wrap all snippets into a () subshell? Would this be prohibitive from a time/space perspective? We started doing so for our individual snippets (and might do this in our wrapper automatically). An alternative option could be to add an option to snippets to “fence” them off by wrapping them, however, having to discover this option would mean someone could just write the () themselves.

I’d like to consider whether having the activation snippets being fenced off like this by default is worthwhile …

2

Subshells can have significant performance implications when part of critical loops, see: Avoid subshells by xzfc · Pull Request #69131 · NixOS/nixpkgs · GitHub

At the moment they are simply concatenated strings and have no semantic barriers.

Is this an issue if you structure the activation scripts using systemd? Besides usage of extraXXX for some modules, I’m not aware of another common “concatenate some more code” paradigms.

I would say having extremely long activation scripts is an anti-pattern, but I’m not sure of the use case.

1 Like
3

Hmm. Interesting. I’d rather use a subshell in many cases than using as many full blown systemd jobs.

The activation scripts are not long at all but doing stuff that requires some isolation (like not accidentally overwriting variables or re-setting stuff that others implicitly rely on). I can happily convert ours into sub-shells and I don’t think those are running in tight loops. I can try to do performance measurements though.