Macports tasks not launching at boot. policy?

[Julien T]

Just to make a confirmation on this old thread.

I reinstalled my Mac with only one partition at daemon are starting right
away.
As the matter is mostly Apple, I think what's important is mostly issue a
warning if at a moment (port update/selfupdate/sync/upgrade) we detect than
/opt is not on /

Didn't try PathState to ensure it is working as we expected.

Cheers

Julien


2014-05-07 6:33 GMT-04:00 Ryan Schmidt <ryandesign at macports.org>:

>
> 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:
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.macosforge.org/pipermail/macports-users/attachments/20140727/280cb89b/attachment.html>