On May 5, 2014, at 19:08, Eric Gallager wrote: > If you want to try modifying the launchd sources, you might want to > have a look at the openlaunchd fork of it, as it seems to be more > up-to-date than the version on opensource.apple.com at least: > https://github.com/rtyler/openlaunchd
I don’t think modifying the launchd sources is going to be a satisfying resolution to this issue. It’s the first process the OS starts, so it’s highly important it works correctly. I don’t want to be responsible for introducing a problem into that mechanism. Getting any change in that process is likely a major QA testing issue as well. And any change we might be able to get approved would be unlikely to ever make its way to older OS X versions. I would rather look for a way to fix this in MacPorts. If it is the case that launchd requires the disk on which the plist lives to be available at boot time, and if a secondary volume that MacPorts might be installed on won’t necessarily get mounted in time by launchd, then we should modify MacPorts’ strategy to accommodate that. For example, instead of installing a symlink to the plist to /Library/LaunchDaemons, we could install the actual plist file. I think we used to do this, and I don’t know why we changed to installing a symlink, and putting the real file in the MacPorts prefix, other than perhaps a thought that it was tidier. But if it doesn’t actually work reliably, tidyness is irrelevant; it needs to function correctly first. Then, we could modify the plist to use the PathState key to ensure the MacPorts prefix exists before the OS tries to start any programs living there: http://stackoverflow.com/questions/19449288/how-to-instruct-launchd-to-wait-for-volume-mount _______________________________________________ macports-users mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-users
