Tracking issue for improving launchd support

[Enzime]

• Make sure all nix-darwin managed units are loaded in
• Back up existing files before replacing them
• Restore backed up files when uninstalling nix-darwin
• Replace usage of {un,}load and boot{out,strap}
• Use more descriptive names than sh for Login Items in System Settings

[Samasaur1]

Should this also include the work that needs to be done to have them show with nicer names in System Settings, or should that be its own tracking issue?

[Enzime]

Updated 👍

[lloeki]

Replace usage of {un,}load and boot{out,strap}

I've opened an issue heavily related to that, because for LaunchAgents it can get tricky: #1255

[Samasaur1]

Use more descriptive names than sh for Login Items in System Settings

also I've said this on Matrix before but just to get it down on GitHub, the plan for this is:

1. merge Allow linking files into place anywhere on the system #1205

2. merge upcoming followup PR that allows copying files into place

3. replace this section:

   nix-darwin/modules/launchd/default.nix

   Lines 82 to 96 in ba9b317

   	config = {
   	command = mkIf (config.script != "") (pkgs.writeScript "${name}-start" ''
   	#! ${stdenv.shell}
   	${config.script}
   	'');
   	serviceConfig.Label = mkDefault "${cfg.labelPrefix}.${name}";
   	serviceConfig.ProgramArguments = mkIf (config.command != "") [
   	"/bin/sh"
   	"-c"
   	"/bin/wait4path /nix/store && exec ${config.command}"
   	];
   	serviceConfig.EnvironmentVariables = mkIf (env != {}) env;
   	};

   with an implementation that builds a binary wrapper with the a filename equal to the service name that calls /bin/wait4path on the Nix store and then executes config.command, copies that binary somwhere not in the Nix store, and then sets up a plist that calls that copied binary

[lloeki]

copies that binary somwhere not in the Nix store

I'm curious, why is that?

[Samasaur1]

copies that binary somwhere not in the Nix store

I'm curious, why is that?

For the same reason that our current implementation uses wait4path: if the executable is on a volume that isn't the root, and that volume hasn't mounted by the time the launchagent or launchdaemon starts, the service will fail repeatedly until it is put in the "penalty box" and then won't start at all. By copying the binary onto the root volume, we avoid this error, and then that binary waits for the Nix store before running the actual executable

[lloeki]

Ah yes of course, what a brain glitch on my part.