Startupitems don't work as advertised
It has come to my attention that startupitems are not disabled by default. Yet they were intended to be as shown by the message: ########################################################### # A startup item has been generated that will aid in # starting XXXX 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.XXXX.plist ########################################################### Yet startupitems have this by default: <key>Disabled</key><false/> Can anyone shed light on this behavior? Mark
Hi Mark, On Jun 1, 2007, at 12:14 PM, markd@macports.org wrote:
It has come to my attention that startupitems are not disabled by default. Yet they were intended to be as shown by the message:
########################################################### # A startup item has been generated that will aid in # starting XXXX 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.XXXX.plist ###########################################################
Yet startupitems have this by default:
<key>Disabled</key><false/>
Can anyone shed light on this behavior?
Hmm. A discrepancy between the documentation and the code. Which way should we change it? (a) Change the emitted text to say that startup item will be started at reboot or if the load command is given, or (b) Default the key to true, and leave the emitted text as it is. Personally, I think (b) is better. Your thoughts? James
On Jun 1, 2007, at 3:23 PM, James Berry wrote:
Which way should we change it?
(a) Change the emitted text to say that startup item will be started at reboot or if the load command is given,
or (b) Default the key to true, and leave the emitted text as it is.
Personally, I think (b) is better.
Your thoughts?
b I prefer having that extra chance to make sure I really want to run some daemon (especially if it's going to be listening on a network). -- Daniel J. Luke +========================================================+ | *---------------- dluke@geeklair.net ----------------* | | *-------------- http://www.geeklair.net -------------* | +========================================================+ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | +========================================================+
James Berry <jberry@macports.org> on Friday, June 1, 2007 at 12:23 PM -0800 wrote:
It has come to my attention that startupitems are not disabled by default. Yet they were intended to be as shown by the message:
########################################################### # A startup item has been generated that will aid in # starting XXXX 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.XXXX.plist ###########################################################
Yet startupitems have this by default:
<key>Disabled</key><false/>
Can anyone shed light on this behavior?
Hmm. A discrepancy between the documentation and the code.
Which way should we change it?
(a) Change the emitted text to say that startup item will be started at reboot or if the load command is given,
or (b) Default the key to true, and leave the emitted text as it is.
Personally, I think (b) is better.
Your thoughts?
I agree that B is better. Option (a) presents security problems, and making server variants only to avoid those security problems has the consequence that that a port rebuild is required just to get the .plist file. So B seems like a far better choice to me. Mark
On Jun 1, 2007, at 3:33 PM, Daniel J. Luke wrote:
On Jun 1, 2007, at 3:23 PM, James Berry wrote:
Which way should we change it?
(a) Change the emitted text to say that startup item will be started at reboot or if the load command is given,
or (b) Default the key to true, and leave the emitted text as it is.
Personally, I think (b) is better.
Your thoughts?
b
I prefer having that extra chance to make sure I really want to run some daemon (especially if it's going to be listening on a network). -- Daniel J. Luke
Seconded! -jmpp
On 01 Jun, 2007, at 15:23, James Berry wrote:
or (b) Default the key to true, and leave the emitted text as it is.
Actually, this introduces another problem; asking launchctl to load a disabled script (as many ports now do) won't cause it to run. To fix this, the text will need to be edited in all such ports. It should tell the user to edit the launchd script and change that flag. Chris
On Jun 1, 2007, at 16:03, Chris Pickel wrote:
On 01 Jun, 2007, at 15:23, James Berry wrote:
or (b) Default the key to true, and leave the emitted text as it is.
Actually, this introduces another problem; asking launchctl to load a disabled script (as many ports now do) won't cause it to run. To fix this, the text will need to be edited in all such ports. It should tell the user to edit the launchd script and change that flag.
What? No no no. That's what the -w flag to launchctl is for -- to add or remove the "disabled" key. And port already outputs instructions which tell you to use -w when calling launchctl. From the first mail in this thread:
########################################################### # A startup item has been generated that will aid in # starting XXXX 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.XXXX.plist ###########################################################
On 01 Jun, 2007, at 17:03, Chris Pickel wrote:
Actually, this introduces another problem; asking launchctl to load a disabled script (as many ports now do) won't cause it to run. To fix this, the text will need to be edited in all such ports. It should tell the user to edit the launchd script and change that flag.
Oops. It has been brought to my attention that the instructions include the "-w" flag, which has that exact behavior. My previous message can be safely ignored. Chris
participants (6)
-
Chris Pickel
-
Daniel J. Luke
-
James Berry
-
Juan Manuel Palacios
-
markd＠macports.org
-
Ryan Schmidt