Proper Way to Restart DirectoryService?

For any process, kill -9 should only be used as a last resort because it doesn't let a process shutdown gracefully. It's a bad habit to use it as a first attempt to stop a process. Instead leave off the signal argument (the default signal is 15/TERM) and that will kill most processes. Some processes (like shells) will trap or ignore TERM, so you can use kill -1 or kill -HUP on them. You could try INT and QUIT, but I've found if TERM and HUP don't stop a process, INT and QUIT seldom do. If you've tried these kills and the process is still running then it's time to use kill -9 but keep in mind that if the process is busy writing records to disk, you will be killing it in the middle of things and you can end up with corrupted files. (eg. I'd never kill a database process with kill -9 without trying the other kills first)

As for DirectoryService, it's not really intended to be killed and restarted, but when it's not behaving properly there's not much choice but to kill it and have launchd restart it. I use 'killall DirectoryService'. This uses the default TERM signal which is what launchd uses to shutdown processes gracefully.

you could also just use launchctl itself:

sudo launchctl stop <service>
sudo launchctl start <service>

Also, the launchctl man page says that:

"Stop the specified job by label. If a job is on-demand, launchd may immediately restart the job if launchd finds any criteria that is satisfied. Non-demand based jobs will always be restarted. Use of this subcommand is discouraged. Jobs should ideally idle timeout by themselves."

I checked the openldap launch daemon plist and it is on-demand. So I'd test, but

lanuchctl stop org.openldap.slapd

might do the trick nicely.

I'm curious, how are you determining it has a memory leak? For example, you could run:

vmmap -resident `cat /var/run/DirectoryService.pid`

then parse the output and run a launchctl stop when a certain parameter reaches an unacceptable level. Put that in a launchd script that polls periodically.

-james

While normally I would recommend using launchctl start/stop for most services, I don't think that it is a good idea to use it to restart DirectoryServices. For one, once it's stopped user lookups/authentications stop working so you might find that the 'sudo launchctl start ...' doesn't work because the sudo won't be able lookup your user id. A second reason would be that in the time that you're typing commands, other processes could start having problems with lookups and authentications. The killall method leaves DirectoryServices down for a fraction of a second.

I'm not sure what org.openldap.slapd has to do with the original question. The label for DirectoryServices is com.apple.DirectoryServices.

flatrack can correct me if I'm wrong, but I'm assuming he or she is seeing the dreaded "Potential VM growth in DirectoryService ..." messages in /var/log/system.log. The bug and a workaround script are discussed here: http://davidleber.net/?p=216 Unfortunately, this bug frequently results with a unresponsive system and a forced power cycle to restart the system.

Greetings!

Have similar need to restart DirectoryService GRACEFULLY. Using sudo killall DirectoryService ultimately hangs system. Once system is restarted, it never can boot. Wanted to get some feedback before I try launchctl.

Any thoughts?

Thanx,
BR

I agree with Dean re. not using launchctl for DirectoryService.

In my experience, DirectoryService won't stop with just "killall DirectoryService". I've always had to use -9. However, I've not tried -1, and will give that a try next.

By the way, I've found that DirectoryService gets hosed a LOT less often with the "Potential VM growth" issue (at least on our high-volume email server) if you ensure launchd isn't hitting the process ceiling. See http://support.apple.com/kb/TS1659 You need to reboot after doing what that document shows, or you can issue appropriate commands inside the launchctl CLI. I also (again with mail) tuned postfix to deliver more mail per process and its seemed to help cut down on overhead.