lsbinstall -- installation tool for various types of data


/usr/lib/lsb/lsbinstall [-c | --check | -r | --remove] { -t type | --type=type } [-p package | --package=package] operand...


The lsbinstall utility may be used to install certain types of files into system specific locations, repositories, or databases. This command may be used during a package post installation script to add package specific data to system wide repositories. A user may need appropriate privilege to invoke lsbinstall.

The operand (or operands) name an object of type type (see below) that belongs to a package named package. The combination of package name, object type and object name should be unique amongst all objects installed by lsbinstall. The lsbinstall utility may rename an object if another package already owns an object of the same type with the same name.

Note: If a namespace collision is detected by lsbinstall, it is unspecified how the object is renamed, although typical implementations may prepend the package name to the object in some way (e.g. package.obj-name). The lsbinstall utility may maintain a database of the mappings it has performed during installation in order to ensure that the correct object is removed during a subsequent removal operation.

Scripts installed by lsbinstall should not make use of the script name in order to decide on their functionality.

Note: It is appropriate for such a script to use the script name in error messages, usage statements, etc. The only guarantee made by lsbinstall is the effect that an installation (or removal) should have, not where a script is installed, or how it is named.

The -p pkg or --package=pkg is required for all object types unless explicitly noted below.

If the -c or --check option is specified, lsbinstall should test to see if there is an existing object of the type specified already installed. If there is, lsbinstall should print a message to its standard output and immediately exit with a status of zero. If there is no object of the type and name specified already installed, lsbinstall should exit with a non-zero status and take no further action.

If the -r or --remove is specified, the named object of the specified type should be removed or disabled from the system, except as noted below. The behavior is unspecified if the named object was not previously installed by lsbinstall.

Note: lsbinstall may rename objects during installation in order to prevent name collisions where another package has already installed an object with the given name. Using lsbinstall --remove will remove only the object belonging to the named package, and not the object belonging to another package.

Also note that the intent of the --remove option is to prevent the effect of the installed object; it should be sufficient to disable or comment out the addition in some way, while leaving the content behind. It is not intended that --remove be required to be the exact reverse of installation.

Object Types

The -t type or --type=type option should support at least the following types:


install a profile script into a system specific location. There should be one operand, that names a profile shell script. The behavior is unspecified if this name does not have the suffix .sh.

The sh utility should read and execute commands in its current execution environment from all such installed profile shell scripts when invoked as an interactive login shell, or if the -l (the letter ell) is specified (see Shell Invocation).


ensure a service name and number pair is known to the system service database. When installing, there must be at least two operands. The first operand should have the format %d/%s with the port number and protocol values (e.g. 22/tcp), and the second operand should be the name of the service. Any subsequent operands provide aliases for this service. The -p pkg or --package=pkg option is not required for service objects, and is ignored if specified. If any of the -r, --remove, -c or --check options are specified, there should be a single operand identifying the port and protocol values (with the same format as above).

It should not be an error to attempt to add a service name to the system service database if that service name already exists for the same port and protocol combination. If the port and protocol combination was already present, but the name unknown, the name should be added as an alias to the existing entry. It should be an error to attempt to add a second entry for a given service name and protocol, but where the port number differs from an existing entry.

If the -r or --remove is specified, the system service database need not be updated to remove or disable the named service.


add an entry to the system's network super daemon configuration. If none of the -r, --remove, -c or --check options are specified, the first operand should have the format:

Otherwise, the first operand should have the format
The fields in the first operand have the following meaning, in order:


The name of this service. If the name does not contain a /, this should match the name of an already installed service (see also getservbyname()). If the name contains a / character, the behavior is unspecified.

Rationale: This version of the LSB does not specify getrpcbyname() nor the existence or format of the /etc/rpc file. Therefore, installation of RPC based services is not specified at this point. A future version of this specification may require names containing a / character to be Remote Procedure Call based services.


The name of a protocol. The name should be one of those listed in /etc/protocols. If this attribute is not specified (i.e. a null value is passed), the system should use an implementation defined default protocol.


One of the following values:


the service will use a stream type socket.


the service will use a datagram type socket.


the service will use a sequenced packet type socket.

This field is not required for the -c, --check, -r, or --remove options.


If the value of this attribute is wait, once the service is started, no further requests for that service will be handled until the service exits. If the value is nowait, the network super daemon should continue to handle further requests for the given service while that service is running.

Note: If the service has the socket_type attribute set to dgram, the wait_flag attribute should be set to wait, since such services do not have any distinction between the socket used for listening and that used for accepting.

This field is not required for the -c, --check, -r, or --remove options.


The name of a user from the user login database, optionally followed by the name of a group from the group database. The service started to handle this request should run with the privileges of the specified user and group. This field is not required for the -c, --check, -r, or --remove options.

server [arg ...] 

The name of a program to run to handle the request, optionally followed by any arguments required. The server name and each of its arguments is separated by whitespace. This field is not required for the -c, --check, -r, or --remove options.

If the implementation supports additional controls over services started through the inet super daemon, there may be additional, implementation-defined, operands.

Rationale: Systems that use the xinetd super daemon may support additional controls such as IP address restrictions, logging requirements, etc. The LSB does not require these additional controls. However, it was believed to be of sufficient benefit that implementations are granted permission to extend this interface as required.


lsbinstall --package=myapp --type=profile

Install the profile shell script for, part of the myapp package..

lsbinstall --package=myapp --check --type=profile

Test to see if the profile shell script for, as part of the myapp package, is installed correctly.

Exit Status

If the -c or --check option is specified, lsbinstall should exit with a zero status if an object of the specified type and name is already installed, or non-zero otherwise. Otherwise, lsbinstall should exit with a zero status if the object with the specified type and name was successfully installed (or removed if the -r or --remove option was specified), and non-zero if the installation (or removal) failed. On failure, a diagnostic message should be printed to the standard error file descriptor.