Support systemd's watchdog feature and enable it by default in the unit
file, so that ejabberd is auto-restarted if the VM becomes unresponsive.
Also, set the systemd startup type to 'notify', so that startup of
followup units is delayed until ejabberd signals readiness. While at
it, also notify systemd of configuration reload and shutdown states.
Note: "NotifyAccess=all" is required as long as "ejabberdctl foreground"
runs the VM as a new child process, rather than "exec"ing it. This way,
systemd views the ejabberdctl process itself as the main service
process, and would discard notifications from other processes by
Daemons started by systemd shouldn't fork into the background if
possible, because if multiple forked processes exist, systemd has
a hard time determining the main process ID.
In a memory constrained environment, the OOM killer may cause
ejabberd to exit without any trace. Because epmd keeps running,
systemd wouldn't notice the error condition, and as a result it
won't restart the server.
With ejabberd running in foreground, systemd is able to obtain the
correct exit code (137 in this case, instead of 0) and schedules a
restart. The administrator can then see what happend by looking at
systemctl status ejabberd.
With "ProtectSystem", /usr is mounted read-only, so things will fail
when e.g. /usr/local is used as the installation prefix. Whether such
options make sense depends on the environment, so they should rather be
set by package maintainers and/or admins.
Make sure the "ExecStop" command line blocks until ejabberd is actually
stopped. This prevents systemd from killing the ejabberd process(es)
Also, let the "ExecStart" command line block until ejabberd's startup is
completed. This makes sure that services which depend on ejabberd
aren't started up too early.
Admins might expect ejabberd to be able to access data below /home or
/tmp. For example, they might use those locations to dump/restore
Mnesia backups, or as a document root for mod_http_fileserver or