MySQL5, OS X 10.4.10, startups, etc.
Ryan Schmidt
ryandesign at macports.org
Mon Oct 1 14:40:10 PDT 2007
On Oct 1, 2007, at 12:57, paul beard wrote:
> On 9/30/07, Ryan Schmidt wrote:
>
>> On Sep 30, 2007, at 12:18, paul beard wrote:
>>
>>> Conversely, you can add the appropriate lines to launchd.conf and
>>> get things going.
>>>
>>> more /etc/launchd.conf
>>> launchctl load /opt/local/etc/LaunchDaemons/org.macports.dbus/
>>> org.macports.dbus.p
>>> list
>>> launchctl load /opt/local/etc/LaunchDaemons/org.macports.apache2/
>>> org.macports.apa
>>> che2.plist
>>> launchctl load /opt/local/etc/LaunchDaemons/org.macports.mysql5/
>>> org.macports.mysq
>>> l5.plist
>>>
>>> I would vote for MacPorts to take the latter approach, with the
>>> post-install message explaining that
>>>
>>> ########
>>> ## To get the application to run at boot time,
>>> ## echo launchctl load /opt/local/etc/LaunchDaemons/
>>> org.macports.mysql5/org.macports.mysql5.plist >> /etc/launchd.conf
>>> ##
>>> ##########
>>
>> Feel free to make a proposal to the macports-dev list if you feel
>> strongly about this. The current approach works, so you should
>> explain why your approach is better (and if there are any reasons why
>> it might be worse).
>
> I don't know that I feel strongly about it. I think it preserves
> the integrity of the host file system by editing an existing file
> rather than writing files to places outside of /opt/local. I
> realize that rule is bent and in some cases broken[*] but I think
> adhering to the infrastructure where possible makes sense. Adding
> and removing those startup items is centralized in the one file
> that is easily found, rather than looking in the active system
> hierarchy and risking mucking something up (imagine the consequence
> of a poorly-formed rm command in /Library/LaunchDaemons?)
>
> * see /Library/Tcl/macports-1.0/
In the current way, the symlink is made in the destroot and handled
just like any other file in the port's manifest. On activate, it is
installed to the right place. On deactivate, it is removed. To start
the service, you "launchctl load" it and to stop it, you "launchctl
unload" it. This is all fairly easy and works.
Your way would require someone to manually edit the file /etc/
launchd.conf, at least to remove a line from it. That's more
complicated than the current way, where a single launchctl line
starts or stops the service. Also, with your way, the service
wouldn't start or stop until the next startup. That's worse than what
we have now, where the service starts or stops immediately.
Running a single launchctl command to start or stop a service is
easy. Conversely, adding a line to a file is easy, as you showed, but
removing a line from a file requires a more elaborate script. So why
change it to make it more difficult?
There's a slight problem with the current way. If the service is
running at the time that you uninstall the port, the software stays
running. And if the service is running at the time that you upgrade
the port, the old version stays running and the new version's plist
says the software isn't running and it's inconvenient to fix that
(manually edit the plist to show that the software is running,
launchctl unload the software, launchctl load it again). Would your
new way solve either of these problems? (I haven't tried so I don't
know.)
More information about the macports-users
mailing list