Apologies for making things unclear. I brought macOS to illustrate a corner case, but now that we are talking about it, here’s the as-detailed an explanation as I can muster.
The TLDR; is that getcwd and s6-dirname do not provide a desired answer when something messes with the process cwd and argv[0].
The objective of the exercise is to make the s6 supervision suite “portable": packaged in an .app bundle (together with other services I use/develop) that allows me to download it to any of my machines and instantly have most of my services ready to go, running form any path of my choice. (Yes there are ways to install things into a fixed path, with homebrew, with some kind of download/build scripts, configure an mdm, or whatever, but in this exercise we want a single download to provide everything already ready to go). All in all, very handy for switching machines and bringing all my tools with a single download. If one is used to mac-style, of course.
Once started, the bundle’s main program installs a so-called LaunchDaemon, which is a service configuration file (a là s6-svscan directory, or a systemd unit file) that will tell launchd what binary to run from my .app bundle. The OS takes care of installing, authorizing, and launching the daemon per the definition in Contents/.../LaunchDaemons folder of the bundle.
App bundles are just folder trees the OS treats specially, and a user treats as a single file. My bundle contains a bin folder with s6 supervision suite, and launchd is configured to run a “BundleExecutable” on a path relative to the bundle, wherever the bundle is on disk. (In most cases, it ends up in /Applications folder, but I don’t want to hard-code that for reasons).
Bundle structure looks like this:
DevServ.app/
└── Contents
├── Library
│ └── LaunchDaemons
├── MacOS
├── Resources
├── Versions
│ ├── 2.13.1.0
│ │ ├── bin
│ │ ├── include
│ │ │ ├── execline
│ │ │ ├── s6
│ │ │ ├── s6-rc
│ │ │ └── skalibs
│ │ ├── lib
│ │ │ └── skalibs
│ │ │ └── sysdeps
│ │ └── libexec
│ └── Latest -> 2.13.1.0
└── _CodeSignature
Launchd uses only stuff configured in the LaunchDaemon configuration: path, stdin, stdout, stderr, cwd, etc. No possibility to specify variables—almost everything has to be specified with absolute paths (save for this BundleExecutable, which is bundle-relative). Even argv[o] is to be specified.
<plist version="1.0">
<dict>
<key>Label</key>
<string>app.devserv.s6-svscan</string>
<key>BundleProgram</key>
<string>Contents/Versions/Latest/bin/s6-svscan</string>
<key>ProgramArguments</key>
<array>
<string>s6-svscan</string>
<string>/Volumes/Devel/services</string>
</array>
<key>KeepAlive</key>
<true/>
<key>StandardOutPath</key>
<string>/Volumes/Devel/var/log/s6-svscan.log</string>
<key>StandardErrorPath</key>
<string>/Volumes/Devel/var/log/s6-svscan.log</string>
</dict>
</plist>
The launched process receives this very minimal environment: default path, CWD set to /, and the name of the service; launched executable is wired to stdout and stdin as configured (or /dev/null by default if not specified).
Inspecting the launched process gives us:
default environment = {
PATH => /usr/bin:/bin:/usr/sbin:/sbin
}
environment = {
XPC_SERVICE_NAME => app.devserv.s6-svscan
}
One can obviously set any env variable in the configuration plist file, but PATH will only contain absolute path definitions—since CWD is /, anyway . One can also configure a different CWD, but again, to an aboslute path. Not much use for a location-agnostic bundle.
If we don’t specify a PATH variable, and manage to somehow ignore the default environment, s6-svscan has its cwd set to scandir, and its own hard-coded PATH of last resort. So it won’t find s6-supervise in the same bin folder.
Since the bundle is code-signed, one cannot dynamically change any configuration parameter in this file. So, obviously, we can’t reconfigure the daemon’s path dynamically.
getcwd and s6-dirname read their working directory as / due to the process cwd being set to /, so the trick with bundle executable being "getcwd PATH s6-svscan scandir" doesn’t work.
I want to run my app bundle from a volume other than /, and from a directory other than /Applications. The only way to do that seems to be to inject the path dynamically so that s6-svscan knows how to find s6-supervise and other stuff it needs.
The idea of getdirname is that: not to rely on process cwd to get the path to the binary, and use it to inject the right PATH variable.
Does that make more sense?
In conclusion, no problems with macOS unixiness. No problem with any of the tools. Just an interesting corner case for getcwd and s6-svscan when launched through a restricted environment of launchd.
--
Damir
> On 31 Mar 2025, at 19:36, Laurent Bercot <ska-skaware_at_skarnet.org> wrote:
>
>
>> I’ve run into a curious problem while trying to package s6 supervision suite in a macOS .app bundle. As I’d like the bundle to work regardless of the folder it is in (not just in /Applications), I cannot set the PATH env variable in the bundle configuraiton (the plist file). Without an absolute PATH, s6-svscan cannot find s6-supervise.
>
> I'm not familiar with the way .app bundles operate, can you please
> explain? PATH is normally a setting that is set at run time, not at
> build/installation time. If you have not used --enable-absolute-paths
> in your configure invocation (which, unless you *know* what your
> final installation directories will be, you shouldn't), s6-svscan will
> rely on the run-time value of PATH to look for s6-supervise, and a
> correct configuration will make all binaries accessible via PATH.
>
> This is the standard way Unix applications work; what does macOS do
> that prevents it from working?
>
>
>> Setting the bundle executable to `getcwd PATH s6-svscan` sadly also fails, as macOS launchd sets the process cwd to / and argv[0] to naked executable name, resulting in PATH being set to /.
>
> Yes, PATH has nothing to do with the cwd of an executable; it is expected
> that it wouldn't work.
>
>
>> So I modified getcwd into this getdirname utility that is supposed to use os-specific mechanisms to find its own path. This solved the problem, at least on a mac. Didn’t test on linux yet, though, and have no access to a BSD machine.
>>
>> Wondering if this is of interest to propose as a patch to execline repo? I’m not experienced with skarnet coding style, any comments, pointers, reviews are most welcome.
>
> Normally, this whole thing should not be necessary. Binaries should be
> accessible via the runtime PATH of their caller, that's the convention;
> if launchd (or anything else) calls s6-svscan, then it should have
> s6-svscan's directory in its PATH, and transmit its PATH to s6-svscan
> (which will make s6-supervise accessible).
> Short of that, if you know in what directory s6 binaries will reside,
> you can hardcode it at configuration time with --enable-absolute-paths.
>
> If neither of these methods work, then MacOS may be on the way to
> diverging too much from other Unices to be worth supporting. It's already
> halfway there on several aspects, unfortunately. But breaking PATH is a
> big step that I doubt Apple would take without at least a transitional
> period, so I think we're missing something here.
>
> --
> Laurent
>
Received on Mon Mar 31 2025 - 20:48:16 CEST