Linuxconf's add-ons: Fields of the dialog

Next Previous Contents

## 3. Fields of the dialog

Many fields are optional in the dialog. Here is an explanation for them. For each, we will also present the corresponding tag needed to enhance a given Sysv script. Both dropins and Sysv init scripts are supported by the same engine in Linuxconf.

## 3.1 Package name

Simply provide a name. Each dropin has a unique name. All dropins are stored as ASCII file in `/etc/linuxconf/control`. The name is used as a key for various other services such as

- System profile versioning
- Multiple machine management
- Control service activity

## 3.2 Dropin revision

Currently unused, enter a 1 there.

## 3.3 Package description

Enter one short line of text explaining what this package is doing. Keep it short, as it will be used to build menus and dialogs.

## 3.4 start command

Provide the complete command (with argument) required to start the package or initialize it.

## 3.5 Stop command

This field is optional. Supply the complete command and argument required to stop the package. If this field is empty, Linuxconf will use the process name and kill that process. See below.

## 3.6 Reload command

This field is optional. Supply the complete command and argument required to restart or reinitialize a package. If this field is empty Linuxconf will generate a stop and a start command.

## 3.7 Probe command

This field is optional and only required for complex packages. Linuxconf does various tests, comparing the age of the processes associated with a package against the revision date of the configuration files. If the configuration files are newer, Linuxconf triggers a reload command (or a stop/start sequence) on the package.

Some packages have complex configuration files and they can't be enumerated in the dropin. Or their state is influenced by other factors. The probe command lets a package decide if it must be restarted, stopped, or started.

The probe command is only the path of the command. Linuxconf will call it with a single argument "probe". The command reacts to this argument by printing lines or nothing if nothing has to be done. Each line corresponds to a specific action. The standard actions "start", "stop" and "restart" will be interpreted by Linuxconf and it will use the supplied start, stop and reload commands to perform the action.

The probe command may also return an "unknown" (to Linuxconf) action. In that case, the probe command itself will be called to perform those actions.

### Probe functionality on Sysv script

Adding the following line to a Sysv script directs Linuxconf to execute the script with the "probe" argument. The output is used like the dropin.

> `

>             # probe: true

> `

## 3.8 Boot time cleanup

This field is optional. You enter a complete command with argument. This command will be executed by Linuxconf at boot time, just before popping the runlevel selector menu. The output of this command will be logged in the "tasks before booting" section of the Linuxconf's logs.

## 3.9 Process names

This section is optional. You must enter the name of the various processes started by the start command (persistent daemons). If you leave this section empty, Linuxconf will compute the name of each process from the start command itself. For example, if the start command is

> `

>             /usr/sbin/foo -a -b

> `

the process name is foo.

When supplying several process names, Linuxconf will look at all those process names to find out if the package is up to date when compared with its configuration files.

### Process names with Sysv script

The following tag lets you specify the process names started by the Sysv script. You can specify the tag multiple times.

> `

>             # processname: foo

> `

## 3.10 PID files

This section is optional. Some packages start multiple instances of a daemon. Linuxconf must know which one is the master and must be monitored. Most packages produce a small text file containing the process ID of the main process of the package. This file is generally stored in /var/run, with the extension .pid.

A package starting several processes may have several PID files.

### PID files with Sysv script

The following tag lets you specify the PID files associated with the Sysv script. You can specify the tag multiple times.

> `

>             # pidfile: /var/run/foo.pid

> `

## 3.11 Activation control

This section tells Linuxconf when the package must be started.

### Start after package

This field is optional. You can specify a package here. There is a help list showing all available packages. Linuxconf will start or probe the current package after the one you have entered here.

### Start at runlevel

Linuxconf defines 3 level of networking activity:

- No networking
- Client networking
- Server networking

You define here at which run-level the package must be started. A package started in a given run-level will be available in the following ones. For example, if you decide to enable you package in the "client networking" run-level, it will also be available in "server networking".

You have control over the networking run-level at boot time and from the control panel menu (switch network run-level).

### Stop at run-level

In the preceding field, you decide at which run-level you start the package. Here, you decide at which run-level it should go away. You may also select that a package should never be killed once it is started.

## 3.12 Config files

In this section, you must enumerate all configuration files (if possible) that affect the state of a package. For each configuration file you may specify if the package has the ability to auto-reload it. Auto-reloaded config files won't participate in the probing Linuxconf is normally doing to decide if a package must be restarted. As such the auto-reloaded file may be omitted. It is a good idea nevertheless to enumerate them here as they automatically participate in "system profile versioning" and "multiple machine management".

### Config files with Sysv script

The following tag lets you specify the configuration files which affect the state of a package. You can specify the tag multiple times. Optionally, each configuration file is followed by the keyword autoreload

> `

>             # config: /etc/foo.conf [ autoreload ]

> `

## 3.13 Comments

You can enter few comments about this package. This is only as reference. Linuxconf does not use those, nor displays them anywhere else.

Next Previous Contents