#12029 closed defect (fixed)
BUG: openldap shouldn't add launchdaemon by default
Reported by: | cyflea@… | Owned by: | macports-tickets@… |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | 1.4.40 |
Keywords: | openldap slapd launchdaemons | Cc: | markd@…,sfiera@…,landonf (Landon Fuller),bchesneau@… |
Port: |
Description
I upgraded the openldap package as part of rebuilding the apache2 port with LDAP support - I'm already running Apple's OpenDirectory on this machine and only had openldap installed as a build/run-time dependency. After rebooting the server after applying Security Update 2007-005, OpenDirectory was hanging, 'cause of the org.macports.slapd LaunchDaemon. Removing it manually fixed everything.
Shouldn't the LaunchDaemon bit be a variant, rather than a default action?
Change History (9)
comment:1 Changed 17 years ago by markd@…
Cc: | markd@… added |
---|---|
Summary: | openldap shouldn't add launchdaemon by default → BUG: openldap shouldn't add launchdaemon by default |
comment:2 Changed 17 years ago by sfiera@…
Cc: | sfiera@… added |
---|
I don't know if that's actually true. I was under the impression that launchd loaded all non-disabled launchd scripts (those without <key>disabled</key><true/>
) from the standard directories (including /Library/LaunchDaemons) at startup, which would explain why the problem was deferred until a restart.
cyflea: Was this the first time you restarted following the install?
comment:3 Changed 17 years ago by markd@…
Cc: | landonf@… added |
---|
I thought the launchd scripts were installed using the disabled key. I guess not. Well then since the openldap port can be used only for the client libraries, I suppose there should be a "server" variant to install the startupitem. Pinging maintainers for comments.
comment:4 Changed 17 years ago by sfiera@…
Cc: | landonf@… bchesneau@… added; landonf@… removed |
---|
Fixing Cc
comment:5 Changed 17 years ago by markd@…
Resolution: | → fixed |
---|---|
Status: | new → closed |
Updated the port to provide a server variant. The startupitem and backend openldap stuff is now only installed when the variant is invoked. Thanks for reporting.
comment:6 Changed 17 years ago by landonf (Landon Fuller)
I've slightly modified the change -- I use slapd for running software unit tests that require a working LDAP server. They automatically start slapd with a per-case configuration file and custom data, and do not rely on an actual running instance of slapd. Disabling the slapd build in "non-server" mode hoses me, so I turned it back on.
It's too bad that startup items are enabled by default -- who wants to recompile an entire piece of software just to get a launchd plist?
comment:7 Changed 17 years ago by landonf (Landon Fuller)
Just to clarify, I left the +server variant in place to create the actual startup item.
comment:8 Changed 17 years ago by markd@…
Thanks for the explanation. But I just realized something. Here is the text generated when startup items are made. Something is amiss here and I should have verified before rather than assuming I had misunderstood. I'll follow up on this.
########################################################### # A startup item has been generated that will aid in # starting vm-pop3d 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.vm-pop3d.plist ###########################################################
comment:9 Changed 17 years ago by markd@…
Okay, the portstartupitem.tcl code was modified in r 25785 so it actually does what the help text claims it does. So the server variant can be removed after the next release of MacPorts.
The startupitem doesn't do anything unless the user activates it using lauchctl. Did you activate it with launchctl? If not I don't understand how that would have been the problem.