startupitems using launchd and needing a wrapper fail to create the wrapper

[blb@…]

When a start, stop, restart, or init (but not both start and stop) option is given to startupitem and the system supports launchd, it wants to use a wrapper script (beginning of section​) and a startup script. The code creates a launchd wrapper which references this startup script (block which references the startup script​). However, nowhere in proc startupitem_create_darwin_launchd does it actually create this script, ${scriptdir}/${portname}.sh.

If a port is expected to create this startup script itself, it needs to be documented since the directory for it, ${prefix}/etc/startup, does not appear in any documentation I can find.

[blb@…]

See the fix in r45298 for how it was affecting dbus at least...

[markd@…]

I hope I've addressed the fact that mp does not create scripts in r45344. But I don't understand what the dbus issue has to do with this.

[blb@…]

The problem was that dbus had used startupitem.init which then caused the startupitem code to reference the startup script, but never actually created that script, so the launchd item would always fail to launch. I referenced the dbus bit since that's where I ran into this issue.

I actually have no idea if that's how startupitem is supposed to work and that script must be created by the port, or if it's a bug with startupitem itself.

[markd@…]

Ah I see. I think the problem is that startup.init should not be used with startupitem.executable. I fixed the warning note on that in the guide, which has some problems before. Here is the updated text:

Note: Since script and executable are mutually exclusive StartupItem types, the startupitem.executable keyword may not be used in a Portfile that uses any keywords listed in the Script StartupItems section.

Also, the guide startupitem.init part says: - Shell code that will be executed prior to any of the options startupitem.start startupitem.stop and startupitem.restart.

So I think we're covered in the docs now so I'll close this. Thanks for reporting it.