Table of Contents
Most Linux distributions are based on Sysv init scripts. Linuxconf supports
them. But various things may be said about this technology.
- It is very handy for packagers and distribution makers. You
drop a script here and there and a new service will become
- They are very simple to do.
- They are completely non informative about the process they start
and the configuration files related to them.
- They are completely useless for a framework which pretends to
be able to compute the proper course of action required to make
effective any configuration changes.
So a more "informative" control file is needed. In Linuxconf it is called
a dropin. Like a SysV init script, a dropin is just "droped in" place
to make some packages enabled. Dropins are simple configuration
file using the CONFDB object (same format as /etc/conf.linuxconf).
Dropins are currently roomed in
They may be stored at other place, potentially right in the various
sysv init directories (/etc/rc.d/rcX.d).
A dropin carry the following information
- A name.
- A description.
- A revision number (not used right now).
- A start command. The corresponding Sysv init script is often
used there. So the dropin enhance the process while being compatible.
- A stop command. If this command is not provided, Linuxconf compute
the name of the process from the start command and kills it.
- A checkbox telling Linuxconf that the service is smart enough
to notice configuration changes. Samba is one such a service and does
not require a restart after
- A reload command. Some services have the ability, when told to
reload new configurations without being restarted. If there is
no reload command and the check-box above is not set, Linuxconf
will stop and start the service when needed.
- A boot time cleanup command. One may hook whatever command needed.
They are executed at the end of the first boot script, just before
- Process name. Often, a sysv startup script has a name unrelated
to the effective daemon running. One may provide the process name
- PID file. If a PID file exist, one may enter it there. In this
case, this clears out all confusion about which process should
be monitored and potentially killed.
- Module name or path. This is how Linuxconf learns about modules.
Providing a module with a dropin is optional.
A dropin may be completly empty, except for the name and a module.
For example, the netadm dropin simply instructs Linuxconf
to load the netadm module. There is no services related to this
- A list of config files. This files will be probed to see
if they are newer than the running daemon. Without those file
Linuxconf has no clue if the services must be restarted.
Beware that this scheme to decide what has to be done is bare bone.
For complex service, the module may provide more sophisticated
checks and generated much sophisticated commands.
Linuxconf provides a user interface to create those dropins. Further
the content of a dropin may be locally changed without changing
the dropin file itself.
to store the various changes done locally.
The dropin stores other informations telling Linuxconf when to
start the service. This could be potentially changed for the case
where a dropin is stored in a startup directory normally containing
SysV init scripts. This will have to be evaluated. Both strategies
may be used at once. Here are the informations stored in the dropin
for activation control.
- Start after which service. One can specify after which other
service the dropin need to be started. The service could be
any builtin service of Linuxconf or any other dropin.
- Start at run-level. Linuxconf defines internally 3 level of
networking: Local, Client and Server. This is particularly useful
for notebook users and also for workstation users who need to
boot the station when the network is down. They can control
this at boot time and switch from one level to another from
Linuxconf control panel.
- Stop at run-level. this tells at which network run-level a service
must be stopped. The option "Never stop" is available also.
Table of Contents