[asterisk-dev] dahdi modules (un)loading and systemd
Tzafrir Cohen
tzafrir.cohen at xorcom.com
Sat Nov 7 21:38:25 CST 2015
Hi,
Most recent Linux distributions switched to systemd. Systemd keeps the
state of each service. This is normally an improvement.
In order to maintain compatibility with legacy SystemV init scripts,
Systemd considers them as services. Trying to run an init.d script will
be hijacked by systemd/systemctl (using scriptology magic). This normally
work well and helps Systemd keep the state of system services.
DAHDI has an init script that is used for loading modules at startup and
later running several other initializations. At shutdown it unloads
modules (which is completely unnecessay to do at shutdown).
Unloading the set of DAHDI modules is a non-trivial piece of code (and
is curently being handled by a recursive shell script function that is
part of the init.d script).
If, for whatever reason, loading fails and you want to run
'/etc/init.d/dahdi stop' to unload modules (those that were already
loaded), nothing will be done. Systemd sees that the service is in a
failed state (and thus stopped) and can't further stop it.
How can this be fixed?
1. Make a proper systemd unit that has Type=oneshot. This means that the
scriptology needs to be factored out of the init script.
2. But a better answer is: don't use a "DAHDI service":
2.1. No need to unload modules at shutdown.
2.2. No need to blacklist modules and load them explicitly. If you
actually have more than one device, use the assigned_spans.conf file
to set the order of spans and channels explicitly.
2.3 Udev hooks are run after a span is ready and can do the rest of the
job. Anything missing there?
If you still need to manually unload / load modules, I recently commited
a script called 'dahdi-modules' to dahdi-linux (but it is not installed
by default) that includes the module loading and unloading bits from the
init.d script.
--
Tzafrir Cohen
icq#16849755 jabber:tzafrir.cohen at xorcom.com
+972-50-7952406 mailto:tzafrir.cohen at xorcom.com
http://www.xorcom.com
More information about the asterisk-dev
mailing list