I would like to convert the slapd LDAP server init script to an Upstart service. However, I have very little knowledge of SysV init scripts (and the LSB(?) stuff). Specifically, I'm interested in the respawn capability of Upstart.

The slapd init script from Ubuntu 14.04 is here. The Upstart service I have come up with is here.

Have I migrated enough things from the sysv script? Have I made mistakes? Things I haven't understood from the sysv script, I haven't included in the Upstart job. Could someone explain this sysv init script to me?

The relevant files are posted on GitHub.


I have a few LDAP servers in N-way multi-master replication. There's a known bug which may be causing memory leaks, leading to the slapd daemons occasionally falling prey to the OOM Killer.

My options include:

  1. Getting slapd to respawn (the subject of this question).
  2. Using a newer version of OpenLDAP (probably compiled from source).
  3. Throwing more RAM at the server.
  • I am analyzing this interesting question, I can now alert you to this: $remote_fs means all filesystems are mounted while when virtual-filesystems event occurs, common filesystems such as /usr may not be mounted. May be filesystem event is better.
    – Lety
    Sep 13 '14 at 19:17
  • Could you post prerm and postrm openLDAP script stored in /var/lib/dpkg/info?
    – Lety
    Sep 13 '14 at 20:45
  • @Letizia I couldn't access the servers for a few days, so didn't update. The files are have been posted on GitHub. Thanks for your inputs.
    – muru
    Sep 16 '14 at 20:25

I have written one here: https://bitbucket.org/CameronNemo/upstart-jobs/src/b5a709465304bdf420ca2507ed14f6fe67272de8/slapd.conf?at=master

A few mistakes you made:

  • There should be no -- between slapd and its options.
  • The start on events need to have an and between them.
  • virtual-filesystems should change to filesystem, as Letizia said.
  • Thanks, the -- was oversight from editing the start-stop-daemon command. I notice that you haven't depended on the filesystem or network signals in the start on stanza. Are they unnecessary?
    – muru
    Sep 16 '14 at 20:33
  • I have, indirectly. The multi runlevel event is only emitted after the filesystem and static network are up (evetns filesystem and static-network-up are a start on condition for rc-sysinit job, which emits runlevel at boot). Sep 17 '14 at 5:15

LSB Keyword

According to LSBInitScripts:

 $remote_fs all filesystems are mounted. In some LSB run-time environments,
            filesystems such as /usr may be remote. If the script need a mounted 
            /usr/, it needs to depend on $remote_fs. Scripts depending on $remote_fs
            do not need to depend on $local_fs. During shutdown, scripts that need to
            run before sendsigs kills all processes should depend on $remote_fs. 

while according to remote-filesystems man page:

 When it occurs, local filesystems such as /usr may not be mounted.  
 For most normal services the  filesystem(7)  event  is sufficient.

You should change remote-filesystems with filesystem event that:

 The  filesystem  event  is generated by the mountall(8) daemon after it
 has mounted all filesystems listed in fstab(5).


SystemV init script check $SLAPD_CONF. If is not present any type of configuration, script fail to start, and stop terminates with exit 0 without doing anything.

This check are useful in case of rebooting between the installation phase and the configuration phase or during uninstall procedure. To understand its meaning you should analyze prerm and postrm scripts in /var/lib/dpkg/info.

For example prerm attempts to stop slapd, and if it fails than unistall procedure will fail too. stop procedure without configuration file will returns 0 to allow uninstall OpenLDAP package that is installed but not configured.

Function check_for_no_start() prevent start execution based on $SLAPD_NO_START variable or if $SLAPD_SENTINEL_FILE file exists. This is a simple way for temporarily disabling startup of slapd, for examples for maintenance. Even if server reboot, slapd will not start.


SystemV script create $piddir (if doesn't exist) and gives right permission to $SLAPD_PIDFILE, this is necessary because slapd will write pid in $SLAPD_PIDFILE.

You should add this in pre_start script.

According to start-stop-daemon man page:

    -S, --start [--] arguments
              Check  for  the  existence  of  a  specified process.  If such a
              process exists, start-stop-daemon does nothing, and  exits  with
              error  status 1 (0 if --oknodo is specified).  If such a process
              does  not  exist,  it  starts  an  instance,  using  either  the
              executable  specified  by --exec or, if specified, by --startas.
              Any arguments given after -- on  the  command  line  are  passed
              unmodified to the program being started.

This is why you should remove -- in slapd command as CameronNemo said.

Finally on stop there is option --retry TERM/10 that means:

          schedule is a list of at least two items  separated  by  slashes
          (/);  each  item  may be -signal-number or [-]signal-name, which
          means to send that signal, or timeout, which means to wait  that
          many  seconds  for processes to exit, or forever, which means to
          repeat the rest of the schedule forever if necessary.

I guess that OpendLDAP need a bit of time to shutdown, so you should add the stanza kill timeout 10, which will wait 10 seconds (vs. the default 5) to send slapd the SIGKILL.

  • Instead of adding a sleep in the post-stop script, he should add the stanza kill timeout 10, which will wait 10 seconds (vs. the default 5) to send slapd the SIGKILL. Sep 15 '14 at 0:46
  • @CameronNemo Thanks! I was wrong and kill timeout 10 seems equivalent to TERM/10.
    – Lety
    Sep 15 '14 at 10:09
  • Thanks. I didn't notice that remote-filesystems and local-filesystems are emitted after virtual-filesystems. Of the four options (including filesystem), is filesystem the most preferable?
    – muru
    Sep 16 '14 at 20:26
  • As I can read on documentation, I guess yes.
    – Lety
    Sep 16 '14 at 21:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.