MySQL5, OS X 10.4.10, startups, etc.
I am trying to get mysql to start/restart properly on my system. sudo port install mysql5 +darwin_8 +server ... I get the output ---> Creating launchd control script ########################################################### # A startup item has been generated that will aid in # starting mysql5 with launchd. It is disabled # by default. Execute the following command to start it, # and to cause it to launch at startup: # # sudo launchctl load -w /Library/LaunchDaemons/ org.macports.mysql5.plist ########################################################### I finish up (after the installation) with sudo launchctl load -w /Library/LaunchDaemons/org.macports.mysql5.plist nothing found to load hmmm - any ideas why this isn't found/loaded/etc ? 8) ---------------------------------- Chris Janton - face at CentosPrime dot COM Netminder for Opus1.COM
On 9/30/07, Chris Janton <face@centosprime.com> wrote:
I am trying to get mysql to start/restart properly on my system.
sudo port install mysql5 +darwin_8 +server ...
I get the output
---> Creating launchd control script ########################################################### # A startup item has been generated that will aid in # starting mysql5 with launchd. It is disabled # by default. Execute the following command to start it, # and to cause it to launch at startup: # # sudo launchctl load -w /Library/LaunchDaemons/ org.macports.mysql5.plist ###########################################################
I finish up (after the installation) with
sudo launchctl load -w /Library/LaunchDaemons/org.macports.mysql5.plist nothing found to load
hmmm - any ideas why this isn't found/loaded/etc ?
what does `locate org.macports.mysql5.plist` give you? I get: /Library/LaunchDaemons/org.macports.mysql5.plist /opt/local/etc/LaunchDaemons/org.macports.mysql5/org.macports.mysql5.plist file /Library/LaunchDaemons/org.macports.mysql5.plist /Library/LaunchDaemons/org.macports.mysql5.plist: symbolic link to `/opt/local/etc/LaunchDaemons/org.macports.mysql5/org.macports.mysql5.plist' The symlink will allow to keep the file(s) MacPorts needs in the /opt/local tree and still get them to fire at boot time. 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 ## ##########
-- Paul Beard / www.paulbeard.org/ <paulbeard@gmail.com/paulbeard@mac.com>
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).
On Sep 30, 2007, at 10:55, Chris Janton wrote:
I am trying to get mysql to start/restart properly on my system.
sudo port install mysql5 +darwin_8 +server
FYI, you do not need to specify +darwin_8; +darwin_8 is auto-selected for you on Darwin 8 (a.k.a. Mac OS X 10.4) systems.
I get the output
---> Creating launchd control script ########################################################### # A startup item has been generated that will aid in # starting mysql5 with launchd. It is disabled # by default. Execute the following command to start it, # and to cause it to launch at startup: # # sudo launchctl load -w /Library/LaunchDaemons/ org.macports.mysql5.plist ###########################################################
I finish up (after the installation) with
sudo launchctl load -w /Library/LaunchDaemons/ org.macports.mysql5.plist nothing found to load
hmmm - any ideas why this isn't found/loaded/etc ?
That's odd. I only get the message "nothing found to load" when a plist file does not exist. Does it exist? Here's how it is on my system: $ ls -l /Library/LaunchDaemons/org.macports.mysql5.plist lrwxr-xr-x 1 root wheel 74 Sep 10 21:49 /Library/LaunchDaemons/ org.macports.mysql5.plist -> /opt/local/etc/LaunchDaemons/ org.macports.mysql5/org.macports.mysql5.plist $ ls -l /opt/local/etc/LaunchDaemons/org.macports.mysql5/ org.macports.mysql5.plist -rw-r--r-- 2 root wheel 981 Oct 1 01:29 /opt/local/etc/ LaunchDaemons/org.macports.mysql5/org.macports.mysql5.plist If you do not have these items, what does "port contents mysql5" tell you? Is the plist shown there? $ port contents mysql5 | grep plist /Library/LaunchDaemons/org.macports.mysql5.plist /opt/local/etc/LaunchDaemons/org.macports.mysql5/ org.macports.mysql5.plist Do you have the latest MacPorts and port definitions? "sudo port selfupdate"
On 9/30/07, Ryan Schmidt <ryandesign@macports.org> wrote:
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/ -- Paul Beard / www.paulbeard.org/ <paulbeard@gmail.com/paulbeard@mac.com>
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.)
On 10/1/07, Ryan Schmidt <ryandesign@macports.org> wrote:
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.
This assumes that people deactivate or otherwise that allow MacPorts to clean up after itself. rm -rf /opt/local would leave those broken symlinks. They don't really matter but as I said earlier, the "nothing outside /opt/local" rule is bent in some cases, this being one. And as for invoking launchct load statements, how is this different? launchctl load /opt/local/etc/LaunchDaemons/org.macports.dbus/org.macports.dbus.plist launchctl load /opt/local/etc/LaunchDaemons/org.macports.apache2/org.macports.apache2.plist launchctl load /opt/local/etc/LaunchDaemons/org.macports.mysql5/org.macports.mysql5.plist from putting the plists in launchd's default search path? As configured, launchctl looks in two places for plists: in /System/Library/LaunchDaemons, for Apple-owned stuff, in /Library/LaunchDaemons for user-installed/third-party stuff. I don't see a big deal about another repository for plists. Maybe in future releases launchd will allow additional directories to be added instead of individual lines. 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.
see above: if launchctl works as it says on the tin, there is not different between symlinks that point to /Library/LaunchDaemons and the lines I have in /etc/launchd.conf. 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?
I'm not arguing in favor of it. I'm just explaining it. I have a hard time believing that, given the power on tap, that there is no way to add a commented line to /etc/launchd.conf launchctl load /opt/local/etc/LaunchDaemons/org.macports.dbus/org.macports.dbus.plist # installed by macports and add a # character to the beginning of the line containing the comment: sed -e s/^launchctl/#&/g <- yes, I know that won't work, but you get the idea: sed is not my native language. 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.)
Is there no pre-install step that could stop the service with the existing plist, install, restart? Again, I'm not arguing in favor of doing it this way, I'm just explaining it. Perhaps if it's more clearly understood, a comparison can be made. -- Paul Beard / www.paulbeard.org/ <paulbeard@gmail.com/paulbeard@mac.com>
On Oct 1, 2007, at 17:52, paul beard wrote:
On 10/1/07, Ryan Schmidt wrote:
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.
This assumes that people deactivate or otherwise that allow MacPorts to clean up after itself. rm -rf /opt/local would leave those broken symlinks. They don't really matter but as I said earlier, the "nothing outside /opt/local" rule is bent in some cases, this being one.
Yes, we do want MacPorts to install as much as possible inside $ {prefix}. But currently some things do get installed outside of the prefix. But IMHO the current uninstall instructions adequately address this issue. BTW, "rm -rf /opt/local" is not the extent of the uninstall instructions: http://trac.macosforge.org/projects/macports/wiki/ FAQ#HowdoIremoveoruninstallMacPorts
And as for invoking launchct load statements, how is this different?
launchctl load /opt/local/etc/LaunchDaemons/org.macports.dbus/ org.macports.dbus.plist launchctl load /opt/local/etc/LaunchDaemons/org.macports.apache2/ org.macports.apache2.plist launchctl load /opt/local/etc/LaunchDaemons/org.macports.mysql5/ org.macports.mysql5.plist
from putting the plists in launchd's default search path? As configured, launchctl looks in two places for plists: in /System/ Library/LaunchDaemons, for Apple-owned stuff, in /Library/ LaunchDaemons for user-installed/third-party stuff. I don't see a big deal about another repository for plists. Maybe in future releases launchd will allow additional directories to be added instead of individual lines.
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.
see above: if launchctl works as it says on the tin, there is not different between symlinks that point to /Library/LaunchDaemons and the lines I have in /etc/launchd.conf.
Wait. Currently, MacPorts automatically puts the symlinks in /Library/ LaunchDaemons, then instructs you how to load (start) and unload (stop) as needed. Your proposition as I understood it was that the user would manually add and remove lines in /etc/launchd.conf. Are you now suggesting instead that MacPorts would automatically put the lines in /etc/launchd.conf? If so, why is that preferable to the current way? Currently, we add symlinks in /Library/LaunchDaemons, which is outside of ${prefix}. You propose modifying /etc/ launchd.conf, which is also outside of ${prefix}. At least the symlinks in /Library/LaunchDaemons have "macports" in the filenames so they're easier to find, and getting rid of them is as simple as a single "rm" command. Getting rid of a line in a conf file is more involved. Also, since I'm not familiar with /etc/launchd.conf, I assume that the file is only scanned at system startup. Is that the case? If so, then adding to that file is worse than what we have now, where "launchctl load" will load the service immediately, and cause it to start at every subsequent system startup. Unless you're suggesting that the user should modify /etc/launchd.conf, and then also use the launchctl command to start the service now. If so, you've just added an extra step for the user, again for no apparent benefit.
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?
I'm not arguing in favor of it. I'm just explaining it. I have a hard time believing that, given the power on tap, that there is no way to add a commented line to /etc/launchd.conf
launchctl load /opt/local/etc/LaunchDaemons/org.macports.dbus/ org.macports.dbus.plist # installed by macports
and add a # character to the beginning of the line containing the comment:
sed -e s/^launchctl/#&/g <- yes, I know that won't work, but you get the idea: sed is not my native language.
Yes, of course it's possible to write something with sed or similar that adds or removes a specific line from a file. My point is that it's more difficult than executing a single launchctl statement. And since the current way works, I didn't understand why you think it's better to complicate things.
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.)
Is there no pre-install step that could stop the service with the existing plist, install, restart?
I don't think MacPorts should be stopping or starting any services automatically. That could be unexpected and bad. I've been meaning to submit bug reports about these situations but hadn't gotten around to it yet.
Again, I'm not arguing in favor of doing it this way, I'm just explaining it. Perhaps if it's more clearly understood, a comparison can be made.
Ok. Then I'll say that I acknowledge that MacPorts could do it your way instead of how it does it now, but I don't see any advantage to making that change at this point, rather I currently see disadvantages, so I don't think MacPorts should change this right now, until someone shows why it's better.
On 10/1/07, Ryan Schmidt <ryandesign@macports.org> wrote:
On Oct 1, 2007, at 17:52, paul beard wrote:
On 10/1/07, Ryan Schmidt wrote:
Yes, we do want MacPorts to install as much as possible inside $ {prefix}. But currently some things do get installed outside of the prefix. But IMHO the current uninstall instructions adequately address this issue. BTW, "rm -rf /opt/local" is not the extent of the uninstall instructions:
Um, yes, I realize that. Allow the possibility that someone will just do rm -rf /opt/local when they get stuck without realizing that they are leaving some cruft behind.
And as for invoking launchct load statements, how is this different?
launchctl load /opt/local/etc/LaunchDaemons/org.macports.dbus/ org.macports.dbus.plist launchctl load /opt/local/etc/LaunchDaemons/org.macports.apache2/ org.macports.apache2.plist launchctl load /opt/local/etc/LaunchDaemons/org.macports.mysql5/ org.macports.mysql5.plist
from putting the plists in launchd's default search path? As configured, launchctl looks in two places for plists: in /System/ Library/LaunchDaemons, for Apple-owned stuff, in /Library/ LaunchDaemons for user-installed/third-party stuff. I don't see a big deal about another repository for plists. Maybe in future releases launchd will allow additional directories to be added instead of individual lines.
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.
see above: if launchctl works as it says on the tin, there is not different between symlinks that point to /Library/LaunchDaemons and the lines I have in /etc/launchd.conf.
Wait. Currently, MacPorts automatically puts the symlinks in /Library/ LaunchDaemons, then instructs you how to load (start) and unload (stop) as needed. Your proposition as I understood it was that the user would manually add and remove lines in /etc/launchd.conf. Are you now suggesting instead that MacPorts would automatically put the lines in /etc/launchd.conf? If so, why is that preferable to the current way? Currently, we add symlinks in /Library/LaunchDaemons, which is outside of ${prefix}. You propose modifying /etc/ launchd.conf, which is also outside of ${prefix}. At least the symlinks in /Library/LaunchDaemons have "macports" in the filenames so they're easier to find, and getting rid of them is as simple as a single "rm" command. Getting rid of a line in a conf file is more involved.
Easy to find if someone knows to look for them. Also, since I'm not familiar with /etc/launchd.conf, I assume that
the file is only scanned at system startup. Is that the case? If so, then adding to that file is worse than what we have now, where "launchctl load" will load the service immediately, and cause it to start at every subsequent system startup. Unless you're suggesting that the user should modify /etc/launchd.conf, and then also use the launchctl command to start the service now. If so, you've just added an extra step for the user, again for no apparent benefit.
man launchd.conf? if you understand how launchd/launchctl works, you would know that a launchctl load statement means "load this plist file and do what it says until instructed otherwise." It doesn't matter if it's loaded on the command line or at boot time: once the instructions are loaded, they stay there.
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?
I'm not arguing in favor of it. I'm just explaining it. I have a hard time believing that, given the power on tap, that there is no way to add a commented line to /etc/launchd.conf
launchctl load /opt/local/etc/LaunchDaemons/org.macports.dbus/ org.macports.dbus.plist # installed by macports
and add a # character to the beginning of the line containing the comment:
sed -e s/^launchctl/#&/g <- yes, I know that won't work, but you get the idea: sed is not my native language.
Yes, of course it's possible to write something with sed or similar that adds or removes a specific line from a file. My point is that it's more difficult than executing a single launchctl statement. And since the current way works, I didn't understand why you think it's better to complicate things.
Perhaps I don't think it's complicated. It's not clear that the other way works optimally. The process of starting up daemons since Tiger is a departure and for a lot of people it doesn't always work properly (check the subject line of this thread and see if there are any others similarly named in the archives). What I'm hearing is "this way works because I understand it, and I don't understand your way. Different == bad." I really don't care what anyone uses. I found a way that works for me, even if it repeats steps that MacPorts already does.
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.)
Is there no pre-install step that could stop the service with the existing plist, install, restart?
I don't think MacPorts should be stopping or starting any services automatically. That could be unexpected and bad.
Hmm. Sounds like that was what you were asking for. I think upgrading a process and having it stopped and *not* restarted is worse. I have my FreeBSD installation set to restart any process for which an rc script is installed. So at upgrade time, stop the process with its plist file, do the upgrade, then let the administrator know that the port is upgraded and not running, with the requisite launchctl instruction to start it. Conversely, I would make automatically starting upgraded daemons an option for people in high-availability environments. I've been meaning to submit bug reports about these situations but
hadn't gotten around to it yet.
Again, I'm not arguing in favor of doing it this way, I'm just explaining it. Perhaps if it's more clearly understood, a comparison can be made.
Ok. Then I'll say that I acknowledge that MacPorts could do it your way instead of how it does it now, but I don't see any advantage to making that change at this point, rather I currently see disadvantages, so I don't think MacPorts should change this right now, until someone shows why it's better.
Again, I simply offer this an alternative way that leverages the launchd/launchctl infrastructure. I'm done with this thread. It's diverged quite a bit and not very productively. -- Paul Beard / www.paulbeard.org/ <paulbeard@gmail.com/paulbeard@mac.com>
participants (3)
-
Chris Janton
-
paul beard
-
Ryan Schmidt