lvmlockd

title: lvmlockd(8)

summary: LVM locking daemon

text:
# lvmlockd(8)

## NAME
lvmlockd — LVM locking daemon

## SYNOPSIS
lvmlockd [options]

## DESCRIPTION
A shared Volume Group is a VG placed on shared storage devices, e.g. from a SAN, that can be used by all the hosts that can access the devices. A shared VG requires the use of lvmlockd, and an external lock manager.

Different hosts may activate and use LVs in the same shared VG, and different hosts can create, extend, or remove LVs in the VG. Locking, through lvmlockd, ensures this is all done safely and consistently. LVM commands request locks from lvmlockd, which passes the lock requests to an external lock manager. Each shared VG has a locktype attribute, specifying the external lock manager to use for the VG.

The lock manager options are: sanlock which places locks on storage space reserved within the VG, and dlm which uses a network locking protocol, and has additional clustering requirements.

There are three types of locking performed through lvmlockd:

•

per-VG locks protect changes to the VG metadata.

•

LV locks limit LV activation to one host at a time.

•

A Global lock protects unused PVs and the VG namespace.

## OPTIONS
lvmlockd daemon command line options:

-h|--help

Show this help information.

-V|--version

Show version of lvmlockd.

-T|--test

Test mode, do not call lock manager.

-f|--foreground

Don't fork.

-D|--daemon-debug

Don't fork and print debugging to stdout.

-p|--pid-file path

Set path to the pid file.

-s|--socket-path path

Set path to the socket to listen on.

--adopt-file path

Set path to the adopt file.

-S|--syslog-priority err|warning|debug

Write log messages from this level up to syslog.

-g|--gl-type sanlock|dlm

Set global lock type to be sanlock or dlm.

-i|--host-id num

Set the local sanlock host id.

-F|--host-id-file path

A file containing the local sanlock host_id.

-o|--sanlock-timeout seconds

Override the default sanlock I/O timeout.

-A|--adopt 0|1

Enable (1) or disable (0) lock adoption.

## SETUP
The following steps provide a quick overview of how to use shared VGs. More details can be found under SETUP DETAILS.

Devices

Identify the shared device(s) that will be used in the shared VG, and add them to each host's devices file (local device names often differ, unless a WWN-based name from /dev/disk/by-id is used.)

$ lvmdevices --adddev device

Configuration

Edit lvm.conf, setting use_lvmlockd=1 on each host using a shared VG.

Edit lvmlocal.conf, setting host_id on each host (only required when using sanlock.) The host_id is a unique integer for each host between 1 and 2000.

Locking

Start lvmlockd and the external lock manager (sanlock or dlm) on each host.

VG

Create a shared VG from one host (uses the running lock manager):

$ vgcreate --shared VG devices

Include vgcreate options to use Persistent Reservations (sanlock only):

--setpersist y --setlockargs persist,notimeout

Start Persistent Reservations for the VG (if they are used):

$ vgchange --persist start VG

Start the lockspace for the shared VG on all hosts:

$ vgchange --lockstart VG

Usage

Begin using the VG, e.g. creating LVs.

Regular shutdown steps:

$ vgchange -an VG

$ vgchange --lockstop [--persist stop] VG

$ stop lvmlockd and lock manager

Regular startup steps:

$ start lvmlockd and lock manager

$ vgchange --lockstart [--persist start] VG

## SETUP DETAILS
Identifying devices

Devices often have different local names on each host, e.g. /dev/sda on one host is named /dev/sdb on another. One method to identify the same device on each host is to run the command lsblk -o+WWN on each host, looking for the same WWN, and its corresponding local device name. Or, the WWN-based device symlinks under /dev/disk/by-id/ can be a useful way to consistently identify a device across multiple hosts.

Device access

On each host, LVM needs to be given access to the shared devices by adding them to the local system.devices file (unless the devices file feature has been disabled.) Use the local device name identified in the previous step, or a WWN-based device symlink, and run the command lvmdevices --adddev device_path to add each of the shared devices to the local system.devices file. Alternatively, after the shared VG has been created from one host, other hosts can run the command vgimportdevices VG to add devices from VG to system.devices. See lvmdevices(8) for more information.

Config files

After /etc/lvm/lvm.conf use_lvmlockd has been set to 1, lvm commands will begin attempting to acquire locks from lvmlockd. Failures to acquire the global lock from lvmlockd may appear until the first shared VG is operational. These warnings won't interfere with lvm commands doing read operations, but lvm commands attempting to write may fail with a global lock error.

The /etc/lvm/lvmlocal.conf host_id setting is only required when using VGs with lock type sanlock. Each host using sanlock VGs must be configured with a unique host_id value. Valid host_ids are integers in the range 1-2000. (The lvmlocal.conf descriptions of host_id and sanlock_align_size mention special cases with 4K disks in which the valid host_id range can be smaller, e.g. 1-250.)

Lock managers

A specific build of LVM may exclude support for sanlock or dlm lock managers. To check this, run the command "lvm version" and look for "--enable-lvmlockd-sanlock" or "--enable-lvmlockd-dlm".

With the --shared option, vgcreate searches for a running lock manager (dlm or sanlock), and uses the result for the VG lock type. In place of --shared, vgcreate --locktype sanlock|dlm can be specified directly.

When using lvmlockd in a cluster which already uses corosync and dlm, then the dlm lock type should be used for shared VGs. Otherwise, using sanlock is usually more straight forward.

Details on starting or setting up each lock manager are outside the scope of LVM. sanlock can usually be started with a simple "systemctl start wdmd sanlock". Steps for setting up and starting corosync and dlm can be more complicated.

Lock start

Shared VGs must be started before they are used via vgchange --lockstart VG. Starting the VG performs lock manager initialization that is necessary to begin using locks (i.e. creating and joining a lockspace). Starting the VG may take some time, and until the start completes the VG may not be modified or activated. When shutting down, the lockspace is stopped with vgchange --lockstop VG.

Persistent Reservations

A shared VG with locktype sanlock can take advantage of Persistent Reservations (PR) for faster and more reliable recovery. This requires all of the devices in the VG to support PR. Test if PR is supported by a device with the command:

$ lvmpersist devtest --device device

The vgcreate command options when enabling PR-based recovery with sanlock:

$ vgcreate --shared --setpersist y --setlockargs persist,notimeout

When enabled, PR needs to be started for the VG before locking:

$ vgchange --persist start VG

## TOPICS

### Displaying shared VGs
The vgs command shows the letter s in the last (sixth) attr position for a shared VG:

```
$ vgs

  VG    #PV #LV #SN Attr   VSize   VFree

  vgfoo   1   0   0 wz--ns 992.00m 736.00m
```

Or, the shared attribute can be displayed as a vgs reporting field:

```
$ vgs -o+shared

  VG    #PV #LV #SN Attr   VSize   VFree   Shared

  vgfoo   1   0   0 wz--ns 992.00m 736.00m  shared
```

The vgs command can also display the lock type:

```
$ vgs -o+locktype

  VG    #PV #LV #SN Attr   VSize   VFree   LockType

  vgfoo   1   0   0 wz--ns 992.00m 736.00m sanlock
```

On hosts that are attached to the shared devices, but do not have lvmlockd enabled, the vgs command will not display shared VGs unless the --shared option is added:

```
$ vgs --shared

  VG    #PV #LV #SN Attr   VSize   VFree

  vgfoo   1   0   0 wz--ns 992.00m 736.00m
```

### Persistent Reservations
To enable PR-based recovery ("fencing") in an existing VG:

$ vgchange --setpersist y --setlockargs persist,notimeout VG

Changing the lock args requires the VG to be stopped on all other nodes.

Once enabled, PR needs to be started before or with lockstart:

$ vgchange --persist start VG

$ vgchange --persist start --lockstart VG

Display the VG attributes configured by setpersist and setlockargs:

$ vgs -o+persist VG

$ vgs -o+lockargs VG

setpersist y

With this setting, LVM requires that PR be started before lockstart, and any VG modifications or activations require that PR is started.

setlockargs persist

This lockargs setting causes lvmlockd to remove the PR key of a failed host when a lock request fails due to a lock owned by the failed host. sanlock is then permitted to grant the lock.

setlockargs notimeout

This lockargs setting causes lvmlockd to configure sanlock leases to not time out. Removing the PR of a failed host replaces timeouts as a faster mechanism for lock recovery. With timeouts disabled, the local watchdog is not used by sanlock for the VG lockspace.

For more information, see lvmpersist(8).

### System ID
In contrast to a shared VG, a local VG can only be used by one host at a time, and does not use lvmlockd or a lock manager. If a local VG is located on shared devices, then the LVM system ID feature should be used to assign one host ownership of the VG. See lvmsystemid(7).

For additional protection, the shared devices in a local VG can be excluded from the devices file (system.devices) on all hosts except for the host that owns the VG.

### Creating the first sanlock VG
When use_lvmlockd is first enabled in lvm.conf, and before the first sanlock VG is created, no global lock will exist. In this initial state, LVM commands try and fail to acquire the global lock, producing a warning, and some commands are disallowed. Once the first sanlock VG is created, the global lock will be available, and LVM will be fully operational.

When a new sanlock VG is created, its lockspace is automatically started on the host that creates it. Other hosts need to run 'vgchange --lockstart' to start the new VG before they can use it.

Creating the first sanlock VG is not protected by locking, so it requires special attention. This is because sanlock locks exist on storage within the VG, so they are not available until after the VG is created. The first sanlock VG that is created will automatically contain the "global lock". Be aware of the following special considerations:

•

The first vgcreate command needs to be given the path to a device that has not yet been initialized with pvcreate. The pvcreate initialization will be done by vgcreate. This is because the pvcreate command requires the global lock, which will not be available until after the first sanlock VG is created.

•

Because the first sanlock VG will contain the global lock, this VG needs to be accessible to all hosts that will use sanlock shared VGs. All hosts will need to use the global lock from the first sanlock VG.

•

The device and VG name used by the initial vgcreate will not be protected from concurrent use by another vgcreate on another host.

See below for more information about managing the sanlock global lock.

### Removing a shared VG
Removing a shared VG will fail if other hosts have the VG started (it must be started on the host running vgremove.) Run vgchange --lockstop <vgname> on all other hosts before vgremove. (It may take several seconds before vgremove recognizes that all hosts have stopped a sanlock VG.)

### Starting and stopping VGs
Starting a shared VG (vgchange --lockstart) causes the lock manager to start (join) the lockspace for the VG on the host where it is run. This makes locks for the VG available to LVM commands on the host. Before a VG is started, only LVM commands that read/display the VG are allowed to continue without locks (and with a warning).

Stopping a shared VG (vgchange --lockstop) causes the lock manager to stop (leave) the lockspace for the VG on the host where it is run. This makes locks for the VG inaccessible to the host. A VG cannot be stopped while it has active LVs.

When using the lock type sanlock, starting a VG can take a long time (potentially minutes if the host was previously shut down without cleanly stopping the VG.)

To make vgchange not wait for start to complete:

vgchange --lockstart --lockopt nowait ...

lvmlockd can be asked directly to stop all lockspaces:

lvmlockctl -S|--stop-lockspaces

### Internal command locking
To optimize the use of LVM with lvmlockd, be aware of the three kinds of locks and when they are used:

Global lock

The global lock is associated with global information, which is information not isolated to a single VG. This includes:

•

The global VG namespace.

•

The set of orphan PVs and unused devices.

•

The properties of orphan PVs, e.g. PV size.

The global lock is acquired in shared mode by commands that read this information, or in exclusive mode by commands that change it. For example, the command 'vgs' acquires the global lock in shared mode because it reports the list of all VG names, and the vgcreate command acquires the global lock in exclusive mode because it creates a new VG name, and it takes a PV from the list of unused PVs.

When an LVM command is given a tag argument, or uses select, it must read all VGs to match the tag or selection, which causes the global lock to be acquired.

VG lock

A VG lock is associated with each shared VG. The VG lock is acquired in shared mode to read the VG and in exclusive mode to change the VG or activate LVs. This lock serializes access to a VG with all other LVM commands accessing the VG from all hosts. The command 'vgs <vgname>' does not acquire the global lock (it does not need the list of all VG names), but will acquire the VG lock on each VG name argument.

LV lock

An LV lock is acquired before the LV is activated, and is released after the LV is deactivated. If the LV lock cannot be acquired, the LV is not activated. (LV locks are persistent and remain in place when the activation command is done. Global and VG locks are transient, and are held only while an LVM command is running.)

lock retries

If a request for a global or VG lock fails due to a lock conflict with another host, lvmlockd automatically retries for a short time before returning a failure to the LVM command. If those retries are insufficient, the LVM command will retry the entire lock request a number of times specified by global/lvmlockd_lock_retries before failing. If a request for an LV lock fails due to a lock conflict, the command fails immediately.

### Managing the global lock in sanlock VGs
The global lock exists in one of the sanlock VGs. The first sanlock VG created will contain the global lock. Subsequent sanlock VGs will each contain a disabled global lock that can be enabled later if necessary.

The VG containing the global lock must be visible to all hosts using sanlock VGs. For this reason, it can be useful to create a small sanlock VG, visible to all hosts, and dedicated to just holding the global lock. While not required, this strategy can help to avoid difficulty in the future if VGs are moved or removed.

The vgcreate command typically acquires the global lock, but in the case of the first sanlock VG, there will be no global lock to acquire until the first vgcreate is complete. So, creating the first sanlock VG is a special case that skips the global lock.

vgcreate determines that it's creating the first sanlock VG when no other sanlock VGs are visible on the system. It is possible that other sanlock VGs do exist, but are not visible when vgcreate checks for them. In this case, vgcreate will create a new sanlock VG with the global lock enabled. When another VG containing a global lock appears, lvmlockd will then see more than one VG with a global lock enabled. LVM commands will report that there are duplicate global locks.

If the situation arises where more than one sanlock VG contains a global lock, the global lock should be manually disabled in all but one of them with the command:

lvmlockctl --gl-disable <vgname>

(The one VG with the global lock enabled must be visible to all hosts.)

An opposite problem can occur if the VG holding the global lock is removed. In this case, no global lock will exist following the vgremove, and subsequent LVM commands will fail to acquire it. In this case, the global lock needs to be manually enabled in one of the remaining sanlock VGs with the command:

lvmlockctl --gl-enable <vgname>

(Using a small sanlock VG dedicated to holding the global lock can avoid the case where the global lock must be manually enabled after a vgremove.)

### Internal lvmlock LV
A sanlock VG contains a hidden LV called "lvmlock" that holds the sanlock locks. vgreduce cannot yet remove the PV holding the lvmlock LV. To remove this PV, change the VG lock type to "none", run vgreduce, then change the VG lock type back to "sanlock". Similarly, pvmove cannot be used on a PV used by the lvmlock LV.

To place the lvmlock LV on a specific device, create the VG with only that device, then use vgextend to add other devices.

### LV activation
In a shared VG, LV activation involves locking through lvmlockd, and the following values are possible with lvchange/vgchange -a:

y|ey

The command activates the LV in exclusive mode, allowing a single host to activate the LV. Before activating the LV, the command uses lvmlockd to acquire an exclusive lock on the LV. If the lock cannot be acquired, the LV is not activated and an error is reported. This would happen if the LV is active on another host.

sy

The command activates the LV in shared mode, allowing multiple hosts to activate the LV concurrently. Before activating the LV, the command uses lvmlockd to acquire a shared lock on the LV. If the lock cannot be acquired, the LV is not activated and an error is reported. This would happen if the LV is active exclusively on another host. If the LV type prohibits shared access, such as a snapshot, the command will report an error and fail. The shared mode is intended for a multi-host/cluster application or file system. LV types that cannot be used concurrently from multiple hosts include thin, cache, raid, mirror, and snapshot.

n

The command deactivates the LV. After deactivating the LV, the command uses lvmlockd to release the current lock on the LV.

### Manually repairing a shared VG
Some failure conditions may not be repairable while the VG has a shared lock type. In these cases, it may be possible to repair the VG by forcibly changing the lock type to "none". This is done by adding "--lockopt force" to the normal command for changing the lock type: vgchange --locktype none VG. The VG lockspace should first be stopped on all hosts, and be certain that no hosts are using the VG before this is done.

### Recover from lost PV holding sanlock locks
In a sanlock VG, the sanlock locks are held on the hidden "lvmlock" LV. If the PV holding this LV is lost, a new lvmlock LV needs to be created. To do this, ensure no hosts are using the VG, then forcibly change the lock type to "none" (see above). Then change the lock type back to "sanlock" with the normal command for changing the lock type:

```
# vgchange --locktype sanlock VG
```

This recreates the internal lvmlock LV with the necessary locks.

### Locking system failures
lvmlockd failure

If lvmlockd fails or is killed while holding locks, the locks are orphaned in the lock manager. Orphaned locks must be cleared or adopted before the associated resources can be accessed normally. If lock adoption is enabled, lvmlockd keeps a record of locks in the adopt-file. A subsequent instance of lvmlockd will then adopt locks orphaned by the previous instance. Adoption must be enabled in both instances (-A|--adopt 1). Without adoption, the lock manager or host would require a reset to clear orphaned lock state.

dlm/corosync failure

If dlm or corosync fail, the clustering system will fence the host using a method configured within the dlm/corosync clustering environment.

LVM commands on other hosts will be blocked from acquiring any locks until the dlm/corosync recovery process is complete.

sanlock lease storage failure

If the PV under a sanlock VG's lvmlock LV is disconnected, unresponsive or too slow, sanlock cannot renew the lease for the VG's locks. After some time, the lease will expire, and locks that the host owns in the VG can be acquired by other hosts. The VG must be forcibly deactivated on the host with the expiring lease before other hosts can acquire its locks. This is necessary for data protection.

When the sanlock daemon detects that VG storage is lost and the VG lease is expiring, it runs the command lvmlockctl --kill <vgname>. This command emits a syslog message stating that storage is lost for the VG, and that LVs in the VG must be immediately deactivated.

If no LVs are active in the VG, then the VG lockspace will be removed, and errors will be reported when trying to use the VG. Use the lvmlockctl --drop command to clear the stale lockspace from lvmlockd.

If the VG has active LVs, they must be quickly deactivated before the locks expire. After all LVs are deactivated, run lvmlockctl --drop <vgname> to clear the expiring lockspace from lvmlockd.

If all LVs in the VG are not deactivated within about 40 seconds, sanlock uses wdmd and the local watchdog to reset the host. The machine reset is effectively a severe form of "deactivating" LVs before they can be activated on other hosts. The reset is considered a better alternative than having LVs used by multiple hosts at once, which could easily damage or destroy their content.

sanlock lease storage failure automation

When the sanlock daemon detects that the lease storage is lost, it runs the command lvmlockctl --kill <vgname>. This lvmlockctl command can be configured to run another command to forcibly deactivate LVs, taking the place of the manual process described above. The other command is configured in the lvm.conf(5) lvmlockctl_kill_command setting. The VG name is appended to the end of the command specified.

The lvmlockctl_kill_command should forcibly deactivate LVs in the VG, ensuring that existing writes to LVs in the VG are complete and that further writes to the LVs in the VG will be rejected. If it is able to do this successfully, it should exit with success, otherwise it should exit with an error. If lvmlockctl --kill gets a successful result from lvmlockctl_kill_command, it tells lvmlockd to drop locks for the VG (the equivalent of running lvmlockctl --drop). If this completes in time, a machine reset can be avoided.

One possible option is to create a script my_vg_kill_script.sh:

```
#!/bin/bash
VG=$1
```

```
# replace dm table with the error target for top level LVs
dmsetup wipe_table -S "uuid=~LVM && vgname=$VG && lv_layer=\"\""
```

```
# check that the error target is in place
dmsetup table -c -S "uuid=~LVM && vgname=$VG && lv_layer=\"\"" |grep -vw error
if [[ $? -ne 0 ]] ; then
exit 0
fi
exit 1
```

Set in lvm.conf(5):

```
lvmlockctl_kill_command="/usr/sbin/my_vg_kill_script.sh"
```

(The script and dmsetup commands should be tested with the actual VG to ensure that all top level LVs are properly disabled.)

If the lvmlockctl_kill_command is not configured, or fails, lvmlockctl --kill will emit syslog messages as described in the previous section, notifying the user to manually deactivate the VG before sanlock resets the machine.

sanlock daemon failure

If the sanlock daemon fails or exits while a lockspace is started, the local watchdog will reset the host. This is necessary to protect any application resources that depend on sanlock leases.

### Changing dlm cluster name
When a dlm VG is created, the cluster name is saved in the VG metadata. To use the VG, a host must be in the named dlm cluster. If the dlm cluster name changes, or the VG is moved to a new cluster, the dlm cluster name saved in the VG must also be changed.

To see the dlm cluster name saved in the VG, use the command:

```
# vgs -o+locktype,lockargs <vgname>
```

To change the dlm cluster name in the VG when the VG is still used by the original cluster:

•

Start the VG on the host changing the lock type

vgchange --lockstart <vgname>

•

Stop the VG on all other hosts:

vgchange --lockstop <vgname>

•

Change the VG lock type to none on the host where the VG is started:

vgchange --locktype none <vgname>

•

Change the dlm cluster name on the hosts or move the VG to the new cluster. The new dlm cluster must now be running on the host. Verify the new name by:

cat /sys/kernel/config/dlm/cluster/cluster_name

•

Change the VG lock type back to dlm which sets the new cluster name:

vgchange --locktype dlm <vgname>

•

Start the VG on hosts to use it:

vgchange --lockstart <vgname>

To change the dlm cluster name in the VG when the dlm cluster name has already been changed on the hosts, or the VG has already moved to a different cluster:

•

Ensure the VG is not being used by any hosts.

•

The new dlm cluster must be running on the host making the change. The current dlm cluster name can be seen by:

cat /sys/kernel/config/dlm/cluster/cluster_name

•

Change the VG lock type to none:

vgchange --locktype none --lockopt force <vgname>

•

Change the VG lock type back to dlm which sets the new cluster name:

vgchange --locktype dlm <vgname>

•

Start the VG on hosts to use it:

vgchange --lockstart <vgname>

### Changing a local VG to a shared VG
All LVs must be inactive to change the lock type.

lvmlockd must be configured and running as described in USAGE.

•

Change a local VG to a shared VG with the command:

vgchange --locktype sanlock|dlm <vgname>

•

Start the VG on hosts to use it:

vgchange --lockstart <vgname>

If lvmlockd or the cluster manager are not available, the lock type can be forcibly changed with:

vgchange --locktype sanlock|dlm --lockopt force <vgname>

### Changing a shared VG to a local VG
All LVs must be inactive to change the lock type.

•

Start the VG on the host making the change:

vgchange --lockstart <vgname>

•

Stop the VG on all other hosts:

vgchange --lockstop <vgname>

•

Change the VG lock type to none on the host where the VG is started:

vgchange --locktype none <vgname>

If the VG cannot be started with the previous lock type, then the lock type can be forcibly changed to none with:

vgchange --locktype none --lockopt force <vgname>

To change a VG from one lock type to another (i.e. between sanlock and dlm), first change it to a local VG, then to the new type.

### Changing a clvm/clustered VG to a shared VG
All LVs must be inactive to change the lock type.

First change the clvm/clustered VG to a local VG. Within a running clvm cluster, change a clustered VG to a local VG with the command:

vgchange -cn <vgname>

If the clvm cluster is no longer running on any nodes, then extra options can be used to forcibly make the VG local. Caution: this is only safe if all nodes have stopped using the VG:

vgchange --locktype none --lockopt force <vgname>

After the VG is local, follow the steps described in "changing a local VG to a shared VG".

### Extending an LV active on multiple hosts
With lvmlockd and dlm, a special clustering procedure is used to refresh a shared LV on remote cluster nodes after it has been extended on one node.

When an LV holding gfs2 or ocfs2 is active on multiple hosts with a shared lock, lvextend is permitted to run with an existing shared LV lock in place of the normal exclusive LV lock.

After lvextend has finished extending the LV, it sends a remote request to other nodes running the dlm to run 'lvchange --refresh' on the LV. This uses dlm_controld and corosync features.

Some special --lockopt values can be used to modify this process. "shupdate" permits the lvextend update with an existing shared lock if it isn't otherwise permitted. "norefresh" prevents the remote refresh operation.

### Limitations of shared VGs
Commands that cannot be run on shared VGs:

•

splitting snapshots from LVs

•

splitting mirrors in sanlock VGs

•

pvmove of entire PVs, or under LVs activated with shared locks

•

vgsplit and vgmerge (convert to a local VG to do this)

### lvmlockd changes from clvmd
Prior to the introduction of lvmlockd, clvmd (CLVM) existed with similar capabilities, but a very different design. Some of the visible usage differences between shared VGs (using lvmlockd) and cluster VGs (using clvmd):

•

lvm.conf(5) is configured to use lvmlockd by setting use_lvmlockd=1.

clvmd used locking_type=3.

•

vgcreate --shared creates a shared VG. vgcreate --clustered y created a clvm/clustered VG.

•

lvmlockd adds the option of using sanlock for locking, avoiding the need for network clustering.

•

lvmlockd defaults to the exclusive activation mode whenever the activation mode is unspecified, i.e. -ay means -aey, not -asy.

•

lvmlockd commands always apply to the local host, and never have an effect on a remote host. (The activation option 'l' is not used.)

•

lvmlockd saves the cluster name for a shared VG using dlm. Only hosts in the matching cluster can use the VG.

•

lvmlockd requires starting/stopping shared VGs with vgchange --lockstart and --lockstop.

•

vgremove of a sanlock VG may fail indicating that all hosts have not stopped the VG lockspace. Stop the VG on all hosts using vgchange --lockstop.

•

vgreduce or pvmove of a PV in a sanlock VG will fail if it holds the internal "lvmlock" LV that holds the sanlock locks.

•

lvmlockd uses lock retries instead of lock queueing, so high lock contention may require increasing global/lvmlockd_lock_retries to avoid transient lock failures.

•

lvmlockd includes VG reporting options lock_type and lock_args, and LV reporting option lock_args to view the corresponding metadata fields.

•

In the vgs(8) command's sixth VG attr field, "s" for "shared" is displayed for shared VGs.

•

If lvmlockd fails or is killed while in use, locks it held remain but are orphaned in the lock manager. lvmlockd can be restarted with an option to adopt the orphan locks from the previous instance of lvmlockd.

•

The lvs(8) command does not report any remote state, because lvmlockd is unable to passively check the remote active or lock state of an LV.

## SEE ALSO
lvmlockctl(8), sanlock(8), dlm_controld(8)


lynis

package: lynis

title: lynis(8)

summary: System and security auditing tool

text:
# lynis(8)

## NAME
Lynis - System and security auditing tool

## SYNOPSIS

```
lynis [scan mode] [other options]
```

## DESCRIPTION
Lynis is a security auditing tool for Linux, macOS, and other systems based on UNIX. The tool checks the system and the software configuration, to see if there is any room for improvement the security defenses. All details are stored in a log file. Findings and other discovered data is stored in a report file. This can be used to compare differences between audits. Lynis can run interactively or as a cronjob. Root permissions (e.g. sudo) are not required, however provide more details during the audit.

The following system areas may be checked:

- Boot loader files

- Configuration files

- Software packages

- Directories and files related to logging and auditing

## FIRST TIME USAGE
When running Lynis for the first time, run: lynis audit system

## COMMANDS
audit <type>

Perform an audit of the selected type

upload-only

Upload the available report data file See HELPERS section for more commands.

## SCAN TYPES
audit system

Performs a system audit, which is the most common audit.

audit system remote <host>

Provide commands to do a remote scan.

For more scan modes, see the helper utilities.

## OPTIONS
--auditor <name>

Define the name of the auditor/pentester. When a full name is used, add double quotes, like "Your Name".

--cronjob

Perform automatic scan with cron safe options (no colors, no questions, no breaks).

--debug

Display debug information to screen for troubleshooting purposes.

--developer

Display detailed information useful for developers when creating tests.

--forensics

Perform the audit on a running or mounted system (see --rootdir)

--help

Show available commands and most-used options.

--logfile </path/to/logfile>

Defines location and name of log file, instead of default /var/log/lynis.log.

--man

Show the man page. Useful for systems that do not have the man page installed.

--no-colors

Disable colored output.

--no-log

Redirect all logging information to /dev/null, prevents sensitive information to be written to disk.

--no-plugins

Do not run any of the enabled plugins.

--pentest

Run a non-privileged scan, usually used for penetration testing. Some of the tests will be skipped if they require root permissions.

--plugin-dir </path/to/plugins>

Define location where plugins can be found.

--profile <file>

Provide alternative profile to perform the scan.

--quick (-Q)

Do a quick scan (default: don't wait for user input).

--quiet (-q)

Run quietly and do not show anything to the screen. Will also enable quick mode.

--report-file <file>

Provide an alternative name for report file.

--reverse-colors

Optimize screen output for light backgrounds.

--tests TEST-IDs

Only run the specific test(s). When using multiple tests, add quotes around the line.

--tests-from-category <category>

Tests are only performed if they belong to the defined category. Use the command 'show categories' to determine all valid options.

--tests-from-group <group>

Similar to --tests-from-category. Only perform tests from a particular group. Use 'show groups' to determine valid options.

--use-cwd

Run from the current working directory.

--upload

Upload data to Lynis Enterprise server (profile option: upload=yes).

--verbose

Show more details on screen, such as components that could not found. These details are hidden by default.

--wait

Wait for user to continue. This adds a break after each section (opposed of --quick).

--warnings-only

Run quietly, except show warnings.

Multiple parameters are allowed, though some parameters can only be used together with others. When running Lynis without any parameters, help will be shown and the program will exit.

## HELPERS
Lynis has special helpers to do certain tasks. This way the framework of Lynis is used, while at the same time storing most of the functionality in a separated file. This speeds up execution and keeps the code clean.

audit

Run audit on the system or on other targets

configure <parameter>

Change or add settings to the config file

generate <parameter>

Generate specific details such as host IDs

show <parameter>

Show information, such as configuration and paths

update <parameter>

Perform activities regarding updating

To use a helper, run 'lynis' followed by the helper name.

## EXIT CODES
Lynis uses exit codes to signal any invoking script. Currently the following codes are used:

0

Program exited normally

1

Fatal error

64

An unknown parameter is used, or incomplete

65

Incorrect data encountered

66

Can't open file or directory

78

Lynis found 1 or more warnings or configurations errors (with error-on-warnings=yes)

## BUGS
Bugs can be reported via GitHub at https://github.com/CISOfy/lynis or via support@cisofy.com

## DOCUMENTATION
Supporting documentation can be found via https://cisofy.com/support/

## LICENSING
Lynis is licensed as GPLv3. The tool was created by Michael Boelen in 2007. Since 2013 its development has been taken over by CISOfy under the management of Michael Boelen. Plugins may have a different license.

## CONTACT INFORMATION
Support requests and project related questions can be addressed via e-mail: lynis-dev@cisofy.com.

branch: sisyphus


package: mailman

title: add_members(8)

text:
# add_members(8)

## NAME
add_members - Add members to a Mailman mailing list from the command line.

## SYNOPSIS
add_members [-r <file>] [-d <file>] [-y <y|n>] [-w <y|n>] [-h] listname

## DESCRIPTION
Add members from a file to a mailman list. Listname is the name of the Mailman list you are adding members to. It must already exist.

## OPTIONS
-r file, --regular-members-file=file

A file containing addresses of the members to be added, one address per line. This list of people become non-digest members. If file is `-', read addresses from stdin. Note that -n/--non-digest-members-file are deprecated synonyms for this option.

-d file, --digest-members-file=file

Similar to above, but these people become digest members.

-a [y|n], --admin-notify=[y|n]

Set whether or not to send the list administrators a notification on the success/failure of these subscriptions, overriding whatever the list's `admin_notify_mchanges' setting is.

-w [y|n], --welcome-msg=[y|n]

Set whether or not to send the list members a welcome message, overriding whatever the list's `send_welcome_msg' setting is.

-h, --help

Print a help message and exit.

## NOTES
You must supply at least one of -r and -d options. At most one of the files can be `-'.

## AUTHOR
Author of Mailman is the Mailman Cabal, see http://www.list.org/ for information. This manpage is written by Tollef Fog Heen <tfheen@debian.org> for Debian, but may be used by others.

## SEE ALSO
Mailman documentation on http://www.list.org/ and in /usr/share/doc/mailman.


title: check_db(8)

text:
# check_db(8)

## NAME
check_db - Check the integrity of a Mailman mailing list's database file

## SYNOPSIS
check_db [options] [listname [listname ...]]

## DESCRIPTION
check_db checks the integrity of a list's config.db and config.db.last database files.

## OPTIONS
-a, --all

Check the databases for all lists. Otherwise only the lists named on the command line are checked.

-v, --verbose

Verbose output. The state of every tested file is printed. Otherwise only corrupt files are displayed.

-h, --help

Print a help text and exit.

## AUTHOR
Author of Mailman is the Mailman Cabal, see http://www.list.org/ for information. This manpage is written by Tollef Fog Heen <tfheen@debian.org> for Debian, but may be used by others.

## SEE ALSO
Mailman documentation on http://www.list.org/ and in /usr/share/doc/mailman.


title: check_perms(8)

summary: Check permissions of Mailman's files

text:
# check_perms(8)

## NAME
check_perms - Check permissions of Mailman's files

## SYNOPSIS
check_perms [-f] [-v] [-h]

## OPTIONS
-f

Fix any problems found (when run as root)

-v

Be verbose

-h

Print a help message and exit

## DESCRIPTION
With no arguments, just check and report all the files that have bogus permissions or group ownership.

## AUTHOR
Author of Mailman is the Mailman Cabal, see http://www.list.org/ for information. This manpage is written by Tollef Fog Heen <tfheen@debian.org> for Debian, but may be used by others.

## SEE ALSO
Mailman documentation on http://www.list.org/ and in /usr/share/doc/mailman.


title: clone_member(8)

text:
# clone_member(8)

## NAME
clone_member - Clone a Mailman mailing list subscriber address

## SYNOPSIS
clone_member [options] fromoldaddr tonewaddr

## DESCRIPTION
Cloning a member address means that a new member will be added who has all the same options and passwords as the original member address. Note that this operation is fairly trusting of the user who runs it -- it does no verification to the new address, it does not send out a welcome message, etc.

The existing member's subscription is usually not modified in any way. If you want to remove the old address, use the -r flag. If you also want to change any list admin addresses, use the -a flag.

## OPTIONS
-l listname, --listname=listname

Check and modify only the named mailing lists. If -l is not given, then all mailing lists are scanned from the address. Multiple -l options can be supplied.

-r, --remove

Remove the old address from the mailing list after it's been cloned.

-a, --admin

Scan the list admin addresses for the old address, and clone or change them too.

-q, --quiet

Do the modifications quietly.

-n, --nomodify

Print what would be done, but don't actually do it. Inhibits the 0

fromoldaddr (`from old address') is the old address of the user. tonewaddr (`to new address') is the new address of the user.

## AUTHOR
Author of Mailman is the Mailman Cabal, see http://www.list.org/ for information. This manpage is written by Tollef Fog Heen <tfheen@debian.org> for Debian, but may be used by others.

## SEE ALSO
Mailman documentation on http://www.list.org/ and in /usr/share/doc/mailman.


title: config_list(8)

text:
# config_list(8)

## NAME
config_list - Configure a Mailman mailing list from a text file description

## SYNOPSIS
config_list [options] listname

## DESCRIPTION
This is a very powerful script which lets you view and modify a list's configuration variables from the command line. E.g. you can dump out all the list options into a plain text file (actually a valid Python file!), complete with comments explaining each variable. Or you can apply the configuration from such a file to a particular list.

## OPTIONS
-i filename, --inputfile=filename

Configure the list by assigning each module-global variable in the file to an attribute on the list object, then saving the list. The named file is loaded with execfile() and must be legal Python code. Any variable that isn't already an attribute of the list object is ignored (a warning message is printed). See also the -c option. A special variable named `mlist' is put into the globals during the execfile, which is bound to the actual MailList object. This lets you do all manner of bizarre thing to the list object, but BEWARE! Using this can severely (and possibly irreparably) damage your mailing list!

-o filename, --outputfile=filename

Instead of configuring the list, print out a list's configuration variables in a format suitable for input using this script. In this way, you can easily capture the configuration settings for a particular list and imprint those settings on another list. filename is the file to output the settings to. If filename is `-', standard out is used.

-c, --checkonly

The modified list is not actually changed. Only useful with -i.

-v, --verbose

Print the name of each attribute as it is being changed. Only useful with -i.

-h, --help

Print a small help text and exit

## NOTES
The options -o and -i are mutually exclusive.

## AUTHOR
Author of Mailman is the Mailman Cabal, see http://www.list.org/ for information. This manpage is written by Tollef Fog Heen <tfheen@debian.org> for Debian, but may be used by others.

## SEE ALSO
Mailman documentation on http://www.list.org/ and in /usr/share/doc/mailman.


title: find_member(8)

text:
# find_member(8)

## NAME
find_member - Find all Mailman mailing lists that a member's address is on

## SYNOPSIS
find_member [options] regex [regex [...]]

## OPTIONS
-l listname, --listname=listname

Include only the named list in the search.

-x listname, --exclude=listname

Exclude the named list from the search.

-w, --owners

Search list owners as well as members.

-o file, --output=file

Append the alias setting recommendations to file, in addition to printing them to standard output.

-h, --help

Print a small help text and exit

regex

A Python regular expression to match against.

## NOTES
The interaction between -l and -x is as follows. If any -l option is given then only the named list will be included in the search. If any -x option is given but no -l option is given, then all lists will be search except those specifically excluded.

Regular expression syntax is Perl5-like, using the Python re module. Complete specifications are at:

http://www.python.org/doc/current/lib/module-re.html

Address matches are case-insensitive, but case-preserved addresses are displayed.

## AUTHOR
Author of Mailman is the Mailman Cabal, see http://www.list.org/ for information. This manpage is written by Tollef Fog Heen <tfheen@debian.org> for Debian but may be used by others.

## SEE ALSO
Mailman documentation on http://www.list.org/ and in /usr/share/doc/mailman.


title: list_admins(8)

text:
# list_admins(8)

## NAME
list_admins - List all the owners of a Mailman mailing list.

## SYNOPSIS
list_admins [options] listname ...

## OPTIONS
-v=vhost, --all-vhost=vhost

List the owners of all the mailing lists for the given virtual host.

-a, --all

List the owners of all the mailing lists on this system.

-h, --help

Print a small help text and exit

## AUTHOR
Author of Mailman is the Mailman Cabal, see http://www.list.org/ for information. This manpage is written for Debian by Bernd S. Brentrup <bsb@debian.org>, but may be used by others.

## SEE ALSO
Mailman documentation on http://www.list.org/ and in /usr/share/doc/mailman.


title: list_lists(8)

text:
# list_lists(8)

## NAME
list_lists - List all Mailman mailing lists on this host

## SYNOPSIS
list_lists [options]

## OPTIONS
-a, --advertised

List only those mailing lists that are publically advertised

-V domain, --virtual-host-overview=domain

List only those mailing lists that are homed to the given virtual domain. This only works if the VIRTUAL_HOST_OVERVIEW variable is set.

-b, --bare

Displays only the list name, with no description.

-h, --help

Print a small help text and exit

## AUTHOR
Author of Mailman is the Mailman Cabal, see http://www.list.org/ for information. This manpage is written by Tollef Fog Heen <tfheen@debian.org> for Debian, but may be used by others.

## SEE ALSO
Mailman documentation on http://www.list.org/ and in /usr/share/doc/mailman.


title: list_members(8)

text:
# list_members(8)

## NAME
list_members - List all the members of a Mailman mailing list

## SYNOPSIS
list_members [-o file] [-r] [-d] [-p] [-h] listname

## OPTIONS
-o file, --output file

Write output to specified file instead of standard out.

-r, --regular

Print just the regular (non-digest) members.

-d [kind], --digest[=kind]

Print just the digest members. Optional argument can be "mime" or "plain" which prints just the digest members receiving that kind of digest.

--nomail[=why], -n [why]

Print the members that have delivery disabled. Optional argument can be "byadmin", "byuser", "bybounce", or "unknown" which prints just the users who have delivery disabled for that reason. It can also be "enabled" which prints just those member for whom delivery is enabled.

-f, --fullnames

Include the full names in the output.

-p, --preserve

Output member addresses case preserved the way they were added to the list. Otherwise, addresses are printed in all lowercase.

-i, --invalid

Print only the addresses in the membership list that are invalid. Ignores -r, -d, -n.

-u, --unicode

Print addresses which are stored as Unicode objects instead of normal string objects. Ignores -r, -d, -n.

-h, --help

Print a small help text and exit

listname is the name of the mailing list to use.

## NOTES
Note that if neither -r or -d is supplied, both regular members are printed first, followed by digest members, but no indication is given as to address status.

## AUTHOR
Author of Mailman is the Mailman Cabal, see http://www.list.org/ for information. This manpage is written by Tollef Fog Heen <tfheen@debian.org> for Debian, but may be used by others.

## SEE ALSO
Mailman documentation on http://www.list.org/ and in /usr/share/doc/mailman.


mmarch

title: mmarch(8)

text:
# mmarch(8)

## NAME
mmarch - Rebuild a Mailman mailing list's archive.

## SYNOPSIS
mmarch [options] <listname> [<mbox>]

## DESCRIPTION
Use this command to rebuild the archives for a mailing list. You may want to do this if you edit some messages in an archive, or remove some messages from an archive.

-h, --help

Print this error message and exit.

-q, --quiet

Make the archiver output less verbose.

--wipe

First wipe out the original archive before regenerating. You usually want to specify this argument unless you're generating the archive in chunks.

-s N, --start=N

Start indexing at article N, where article 0 is the first in the mbox. Defaults to 0.

-e M, --end=M

End indexing at article M. This script is not very efficient with respect to memory management, and for large archives, it may not be possible to index the mbox entirely. For that reason, you can specify the start and end article numbers.

mbox is the path to a list's complete mbox archive. Usually this will be some path in the archives/private directory. For example:

% mmarch mylist archives/private/mylist.mbox/mylist.mbox

mbox is optional. If it is missing, it is calculated.

## AUTHOR
Author of Mailman is the Mailman Cabal, see http://www.list.org/ for information. This manpage is written by Tollef Fog Heen <tfheen@debian.org> for Debian, but may be used by others.

## SEE ALSO
Mailman documentation on http://www.list.org/ and in /usr/share/doc/mailman.


mmsitepass

title: mmsitepass(8)

text:
# mmsitepass(8)

## NAME
mmsitepass - Set the Mailman site password, prompting from the terminal.

## SYNOPSIS
mmsitepass [options] [password]

## OPTIONS
-c, --listcreator

Set the list creator password instead of the site password. The list creator is authorized to create and remove lists, but does not have the total power of the site administrator.

-h, --help

Print a small help text and exit

## SECURITY
Including the admin-password on the command line is a small security risk if you have untrusted users on the system.

## DESCRIPTION
The site password can be used in most if not all places that the list administrator's password can be used, which in turn can be used in most places that a list users password can be used.

## AUTHOR
Author of Mailman is the Mailman Cabal, see http://www.list.org/ for information. This manpage is written by Tollef Fog Heen <tfheen@debian.org> for Debian but may be used by others.

## SEE ALSO
Mailman documentation on http://www.list.org/ and in /usr/share/doc/mailman.


newlist

title: newlist(8)

text:
# newlist(8)

## NAME
newlist - Create a new, unpopulated Mailman mailing list.

## SYNOPSIS
newlist [options] [listname] [listadmin-addr] [admin-password]

## OPTIONS
-l language, --language=language

Make the list's preferred language `language', which must be the (mostly two letter) language code as found under /usr/share/mailman.

-u urlhost, --urlhost=urlhost

Gives the list's web interface host name.

-e emailhost, --emailhost=emailhost

Gives the list's email domain name.

-q, --quiet

Normally the administrator is notified by email (after a prompt) that their list has been created. This option suppresses that notification and the prompting.

-h, --help

Print a small help text and exit

## SECURITY
Including the admin-password on the command line is a small security risk if you have untrusted users on the system.

## NOTES
You can specify as many of the arguments as you want on the command line: you will be prompted for the missing ones.

Every Mailman list has two parameters which define the default host name for outgoing email, and the default URL for all web interfaces. When you configured Mailman, certain defaults were calculated, but if you are running multiple virtual Mailman sites, then the defaults may not be appropriate for the list you are creating.

You also specify the domain to create your new list in by typing the command like so:

newlist --urlhost=www.example.com mylist

where `www.example.com' should be the base hostname for the URL to this virtual hosts's lists. E.g. with this setting people will view the general list overviews at http://www.example.com/mailman/listinfo. Also, www.example.com should be a key in the VIRTUAL_HOSTS mapping in mm_cfg.py/Defaults.py if the email hostname to be automatically determined.

If you want the email hostname to be different from the one looked up by the VIRTUAL_HOSTS or if urlhost is not registered in VIRTUAL_HOSTS, you can specify `emailhost' like so:

newlist --urlhost=www.example.com --emailhost=example.com mylist

where `example.com' is the mail domain name. If you don't specify emailhost but urlhost is not in the virtual host list, then mm_cfg.DEFAULT_EMAIL_HOST will be used for the email interface.

For backward compatibility, you can also specify the domain to create your new list in by spelling the listname like so:

mylist@www.example.com

where www.example.com is used for `urlhost' but it will also be used for `emailhost' if it is not found in the virtual host table. Note `--urlhost' and `--emailhost' have precedence to this notation.

If you spell the list name as just `mylist', then the email hostname will be taken from DEFAULT_EMAIL_HOST and the url will be taken from DEFAULT_URL (as defined in your Defaults.py file or overridden by settings in mm_cfg.py).

Note that listnames are forced to lowercase.

The list admin address need to be a fully-qualified address, like owner@example.com, not just owner.

## AUTHOR
Author of Mailman is the Mailman Cabal, see http://www.list.org/ for information. This manpage is written by Tollef Fog Heen <tfheen@debian.org> for Debian, but may be used by others.

## SEE ALSO
Mailman documentation on http://www.list.org/ and in /usr/share/doc/mailman.


title: remove_members(8)

text:
# remove_members(8)

## NAME
remove_members - Remove members from a Mailman mailing list.

## SYNOPSIS
remove_members [options] listname [addr1 ...]

## OPTIONS
-f file, --file=file

Remove member addresses found in the given file. If file is `-', read stdin.

-a, --all

Remove all members of the mailing list. (mutually exclusive with --fromall)

--fromall

Removes the given addresses from all the lists on this system regardless of virtual domains if you have any. This option cannot be used with -a/--all. Also, you should not specify a listname when using this option.

-n, --nouserack

Don't send the user acknowledgements. If not specified, the list default value is used.

-N, --noadminack

Don't send the admin acknowledgements. If not specified, the list default value is used.

-h, --help

Print a small help text and exit

listname is the name of the mailing list to use.

addr1 ... are additional addresses to remove.

## AUTHOR
Author of Mailman is the Mailman Cabal, see http://www.list.org/ for information. This manpage is written by Tollef Fog Heen <tfheen@debian.org> for Debian, but may be used by others.

## SEE ALSO
Mailman documentation on http://www.list.org/ and in /usr/share/doc/mailman.


rmlist

title: rmlist(8)

summary: Remove the components of a Mailman mailing list with impunity \- beware!

text:
# rmlist(8)

## NAME
rmlist - Remove the components of a Mailman mailing list with impunity - beware!

## SYNOPSIS
rmlist [-a] [-h] listname

## DESCRIPTION
This removes (almost) all traces of a mailing list. By default, the lists archives are not removed, which is very handy for retiring old lists.

## OPTIONS
-a, --archives

Remove the list's archives too, or if the list has already been deleted, remove any residual archives.

-h, --help

Print a small help text and exit

listname is the name of the mailing list to use.

## AUTHOR
Author of Mailman is the Mailman Cabal, see http://www.list.org/ for information. This manpage is written by Tollef Fog Heen <tfheen@debian.org> for Debian, but may be used by others.

## SEE ALSO
Mailman documentation on http://www.list.org/ and in /usr/share/doc/mailman.


title: sync_members(8)

text:
# sync_members(8)

## NAME
sync_members - Synchronize a Mailman mailing list's membership with a flat file.

## SYNOPSIS
sync_members [options] -f file listname

## DESCRIPTION
This script is useful if you have a Mailman mailing list and a sendmail :include: style list of addresses (also as is used in Majordomo). For every address in the file that does not appear in the mailing list, the address is added. For every address in the mailing list that does not appear in the file, the address is removed. Other options control what happens when an address is added or removed.

## OPTIONS
-n, --no-change

Don't actually make the changes. Instead, print out what would be done to the list.

-w={ yes | no }, --welcome-msg={ yes | no }

Sets whether or not to send the newly added members a welcome message, overriding whatever the list's `send_welcome_msg' setting is. With -w=yes or -w, the welcome message is sent. With -w=no, no message is sent.

-g={ yes | no }, --goodbye-msg={ yes | no }

Sets whether or not to send the goodbye message to removed members, overriding whatever the list's `send_goodbye_msg' setting is. With -g=yes or -g, the goodbye message is sent. With -g=no, no message is sent.

-d={ yes | no }, --digest={ yes | no }

Selects whether to make newly added members receive messages in digests. With -d=yes or -d, they become digest members. With -d=no (or if no -d option given) they are added as regular members.

-a={ yes | no }, --notifyadmin={ yes | no }

Specifies whether the admin should be notified for each subscription or unsubscription. If you're adding a lot of addresses, you definitely want to turn this off! With -a=yes or -a, the admin is notified. With -a=no, the admin is not notified. With no -a option, the default for the list is used.

-f=filename, --file=filename

This option is required. It specifies the flat file to synchronize against. Email addresses must appear one per line. If filename is `-' then stdin is used.

-h, --help

Print a small help text and exit.

listname specifies the list to synchronize.

## AUTHOR
Author of Mailman is the Mailman Cabal, see http://www.list.org/ for information. This manpage is written by Tollef Fog Heen <tfheen@debian.org> for Debian, but may be used by others.

## SEE ALSO
Mailman documentation on http://www.list.org/ and in /usr/share/doc/mailman.


withlist

title: withlist(8)

text:
# withlist(8)

## NAME
withlist - General framework for interacting with a Mailman mailing list object.

## SYNOPSIS
withlist [options] listname [args ...]

There are two ways to use this script: interactively or programmatically. Using it interactively allows you to play with, examine and modify a MailList object from Python's interactive interpreter. When running interactively, a MailList object called `m' will be available in the global namespace. It also loads the class MailList into the global namespace.

Programmatically, you can write a function to operate on a MailList object, and this script will take care of the housekeeping (see below for examples). In that case, the general usage syntax is:

## OPTIONS
-l, --lock

Lock the list when opening. Normally the list is opened unlocked (e.g. for read-only operations). You can always lock the file after the fact by typing `m.Lock()' Note that if you use this option, you should explicitly call m.Save() before exiting, since the interpreter's clean up procedure will not automatically save changes to the MailList object (but it will unlock the list).

-i, --interactive

Leaves you at an interactive prompt after all other processing is complete. This is the default unless the -r option is given.

-r [module.]callable, --run [module.]callable

This can be used to run a script with the opened MailList object. This works by attempting to import module (which must already be accessible on your sys.path), and then calling callable from the module. callable can be a class or function; it is called with the MailList object as the first argument. If additional args are given on the command line, they are passed as subsequent positional args to the callable. Note that module. is optional; if it is omitted then a module with the name callable will be imported.

The global variable `r' will be set to the results of this call.

-a, --all

This option only works with the -r option. Use this if you want to execute the script on all mailing lists. When you use -a you should not include a listname argument on the command line. The variable `r' will be a list of all the results.

-q, --quiet

Suppress all status messages.

-h, --help

Print a small help text and exit.

## EXAMPLES
Here's an example of how to use the -r option. Say you have a file in the Mailman installation directory called `listaddr.py', with the following two functions:

def listaddr(mlist):

print mlist.GetListEmail()

def requestaddr(mlist):

print mlist.GetRequestEmail()

Now, from the command line you can print the list's posting address by running the following from the command line:

% bin/withlist -r listaddr mylist

Loading list: mylist (unlocked)

Importing listaddr ...

Running listaddr.listaddr() ...

mylist@example.com

And you can print the list's request address by running:

% bin/withlist -r listaddr.requestaddr mylist

Loading list: mylist (unlocked)

Importing listaddr ...

Running listaddr.requestaddr() ...

mylist-request@example.com

As another example, say you wanted to change the password for a particular user on a particular list. You could put the following function in a file called `changepw.py':

from Mailman.Errors import NotAMemberError

def changepw(mlist, addr, newpasswd):

try:

mlist.setMemberPassword(addr, newpasswd)

mlist.Save()

except NotAMemberError:

print 'No address matched:', addr

and run this from the command line:

% bin/withlist -l -r changepw mylist somebody@example.org foobar

## AUTHOR
Author of Mailman is the Mailman Cabal, see http://www.list.org/ for information. This manpage is written for Debian by Bernd S. Brentrup <bsb@debian.org>, but may be used by others.

## SEE ALSO
Mailman documentation on http://www.list.org/ and in /usr/share/doc/mailman.


makedumpfile

package: makedumpfile

title: makedumpfile(8)

summary: make a small dumpfile of kdump

text:
# makedumpfile(8)

## NAME
makedumpfile - make a small dumpfile of kdump

## SYNOPSIS
makedumpfile [OPTION] [-x VMLINUX|-i VMCOREINFO] VMCORE DUMPFILE

makedumpfile -F [OPTION] [-x VMLINUX|-i VMCOREINFO] VMCORE

makedumpfile [OPTION] -x VMLINUX [--config FILTERCONFIGFILE] [--eppic EPPICMACRO] VMCORE DUMPFILE

makedumpfile -R DUMPFILE

makedumpfile --split [OPTION] [-x VMLINUX|-i VMCOREINFO] VMCORE DUMPFILE1 DUMPFILE2 [DUMPFILE3 ..]

makedumpfile [OPTION] [-x VMLINUX|-i VMCOREINFO] --num-threads THREADNUM VMCORE DUMPFILE

makedumpfile --reassemble DUMPFILE1 DUMPFILE2 [DUMPFILE3 ..] DUMPFILE

makedumpfile -g VMCOREINFO -x VMLINUX

makedumpfile [OPTION] [--xen-syms XEN-SYMS|--xen-vmcoreinfo VMCOREINFO] VMCORE DUMPFILE

makedumpfile --dump-dmesg [--partial-dmesg] [-x VMLINUX|-i VMCOREINFO] VMCORE LOGFILE

makedumpfile [OPTION] -x VMLINUX --diskset=VMCORE1 --diskset=VMCORE2 [--diskset=VMCORE3 ..] DUMPFILE

makedumpfile -h

makedumpfile -v

## DESCRIPTION
With kdump, the memory image of the first kernel (called "panicked kernel") can be taken as /proc/vmcore while the second kernel (called "kdump kernel" or "capture kernel") is running. This document represents /proc/vmcore as VMCORE. makedumpfile makes a small DUMPFILE by compressing dump data or by excluding unnecessary pages for analysis, or both. makedumpfile needs the first kernel's debug information, so that it can distinguish unnecessary pages by analyzing how the first kernel uses the memory. The information can be taken from VMLINUX or VMCOREINFO.

makedumpfile can exclude the following types of pages while copying VMCORE to DUMPFILE, and a user can choose which type of pages will be excluded.

- Pages filled with zero

- Cache pages without private flag (non-private cache)

- Cache pages with private flag (private cache)

- User process data pages

- Free pages

makedumpfile provides two DUMPFILE formats (the ELF format and the kdump-compressed format). By default, makedumpfile makes a DUMPFILE in the kdump-compressed format. The kdump-compressed format is readable only with the crash utility, and it can be smaller than the ELF format because of the compression support. The ELF format is readable with GDB and the crash utility. If a user wants to use GDB, DUMPFILE format has to be explicitly specified to be the ELF format.

Apart from the exclusion of unnecessary pages mentioned above, makedumpfile allows user to filter out targeted kernel data. The filter config file can be used to specify kernel/module symbols and its members that need to be filtered out through the erase command syntax. makedumpfile reads the filter config and builds the list of memory addresses and its sizes after processing filter commands. The memory locations that require to be filtered out are then poisoned with character 'X' (58 in Hex). Refer to makedumpfile.conf(5) for file format.

Eppic macros can also be used to specify kernel symbols and its members that need to be filtered. Eppic provides C semantics including language constructs such as conditional statements, logical and arithmetic operators, functions, nested loops to traverse and erase kernel data. --eppic requires eppic_makedumpfile.so and eppic library. eppic_makedumpfile.so can be built from makedumpfile source. Refer to http://code.google.com/p/eppic/ to build eppic library libeppic.a and for more information on writing eppic macros. NOTE: currently Rust is not supported in this function.

To analyze the first kernel's memory usage, makedumpfile can refer to VMCOREINFO instead of VMLINUX. VMCOREINFO contains the first kernel's information (structure size, field offset, etc.), and VMCOREINFO is small enough to be included into the second kernel's initrd.

If the second kernel is running on its initrd without mounting a root file system, makedumpfile cannot refer to VMLINUX because the second kernel's initrd cannot include a large file like VMLINUX. To solve the problem, makedumpfile makes VMCOREINFO beforehand, and it refers to VMCOREINFO instead of VMLINUX while the second kernel is running.

VMCORE has contained VMCOREINFO since linux-2.6.24, and a user does not need to specify neither -x nor -i option.

If the second kernel is running on its initrd without mounting any file system, a user needs to transport the dump data to a remote host. To transport the dump data by SSH, makedumpfile outputs the dump data in the intermediate format (the flattened format) to the standard output. By piping the output data to SSH, a user can transport the dump data to a remote host. Note that analysis tools (crash utility before version 5.1.2 or GDB) cannot read the flattened format directly, so on a remote host the received data in the flattened format needs to be rearranged to a readable DUMPFILE format by makedumpfile (or makedumpfile-R.pl).

makedumpfile can read a DUMPFILE in the kdump-compressed format instead of VMCORE and re-filter it. This feature is useful in situation that users need to reduce the file size of DUMPFILE for sending it somewhere by ftp/scp/etc. (If all of the page types, which are specified by a new dump_level, are excluded from an original DUMPFILE already, a new DUMPFILE is the same as an original DUMPFILE.)

For example, makedumpfile can create a DUMPFILE of dump_level 31 from the one of dump_level 3 like the following:

Example:

\# makedumpfile -c -d 3 /proc/vmcore dumpfile.1

\# makedumpfile -c -d 31 dumpfile.1 dumpfile.2

makedumpfile can read VMCORE(s) in three kinds of sadump formats: single partition format, diskset format and media backup format, and can convert each of them into kdump-compressed format with filtering and compression processing. Note that for VMCORE(s) created by sadump, you always need to pass VMLINUX with -x option. Also, to pass multiple VMCOREs created on diskset configuration, you need to use --diskset option.

## OPTIONS
-c,-l,-p,-z

Compress dump data by the page using the following compression library respectively:

-c : zlib

-l : lzo

-p : snappy

-z : zstd

(-l, -p and -z option need USELZO=on, USESNAPPY=on and USEZSTD=on respectively when building makedumpfile)

A user cannot specify this option with -E option, because the ELF format does not support compressed data.

Example:

\# makedumpfile -c -d 31 -x vmlinux /proc/vmcore dumpfile

-d dump_level

Specify the type of unnecessary page for analysis.

Pages of the specified type are not copied to DUMPFILE. The page type marked in the following table is excluded. A user can specify multiple page types by setting the sum of each page type for dump_level. The maximum of dump_level is 31. Note that a dump_level for Xen dump filtering is 0 or 1 on a machine other than x86_64. On a x86_64 machine, even 2 or bigger dump level will be effective if you specify domain-0's vmlinux with -x option. Then the pages are excluded only from domain-0.

If specifying multiple dump_levels with the delimiter ',', makedumpfile retries to create DUMPFILE using the next dump_level when the size of a dumpfile exceeds the limit specified with '-L' or when a "No space on device" error happens. For example, if dump_level is "11,31" and makedumpfile fails with dump_level 11, makedumpfile retries with dump_level 31.

Example:

\# makedumpfile -d 11 -x vmlinux /proc/vmcore dumpfile

\# makedumpfile -d 11,31 -x vmlinux /proc/vmcore dumpfile

Base level:

dump_level consists of five bits, so there are five base levels to specify the type of unnecessary page.

1 : Exclude the pages filled with zero.

2 : Exclude the non-private cache pages.

4 : Exclude all cache pages.

8 : Exclude the user process data pages.

16 : Exclude the free pages. Here is the all combinations of the bits.

| |non- | | |

dump | zero |private|private| user | free

level | page |cache |cache | data | page

-------+------+-------+-------+------+------

0 | | | | |

1 | X | | | |

2 | | X | | |

3 | X | X | | |

4 | | X | X | |

5 | X | X | X | |

6 | | X | X | |

7 | X | X | X | |

8 | | | | X |

9 | X | | | X |

10 | | X | | X |

11 | X | X | | X |

12 | | X | X | X |

13 | X | X | X | X |

14 | | X | X | X |

15 | X | X | X | X |

16 | | | | | X

17 | X | | | | X

18 | | X | | | X

19 | X | X | | | X

20 | | X | X | | X

21 | X | X | X | | X

22 | | X | X | | X

23 | X | X | X | | X

24 | | | | X | X

25 | X | | | X | X

26 | | X | | X | X

27 | X | X | | X | X

28 | | X | X | X | X

29 | X | X | X | X | X

30 | | X | X | X | X

31 | X | X | X | X | X

-L SIZE

Limit the size of the output file to SIZE bytes. An incomplete DUMPFILE or LOGFILE is written if the size would otherwise exceed SIZE.

-E

Create DUMPFILE in the ELF format.

This option cannot be specified with the -c, -l or -p options, because the ELF format does not support compressed data.

Example:

\# makedumpfile -E -d 31 -x vmlinux /proc/vmcore dumpfile

-f

Force existing DUMPFILE to be overwritten and mem-usage to work with older kernel as well.

Example:

\# makedumpfile -f -d 31 -x vmlinux /proc/vmcore dumpfile

This command overwrites DUMPFILE even if it already exists.

\# makedumpfile -f --mem-usage /proc/kcore

Kernel version lesser than v4.11 will not work with --mem-usage functionality until it has been patched with upstream commit 464920104bf7. Therefore if you have patched your older kernel then use -f.

-x VMLINUX

Specify the first kernel's VMLINUX with debug information to analyze the first kernel's memory usage.

This option is necessary if VMCORE does not contain VMCOREINFO, [-i VMCOREINFO] is not specified, and dump_level is 2 or more.

The page size of the first kernel and the second kernel should match.

Example:

\# makedumpfile -d 31 -x vmlinux /proc/vmcore dumpfile

-i VMCOREINFO

Specify VMCOREINFO instead of VMLINUX for analyzing the first kernel's memory usage.

VMCOREINFO should be made beforehand by makedumpfile with -g option, and it contains the first kernel's information.

This option is necessary if VMCORE does not contain VMCOREINFO, [-x VMLINUX] is not specified, and dump_level is 2 or more.

Example:

\# makedumpfile -d 31 -i vmcoreinfo /proc/vmcore dumpfile

-g VMCOREINFO

Generate VMCOREINFO from the first kernel's VMLINUX with debug information.

VMCOREINFO must be generated on the system that is running the first kernel. With -i option, a user can specify VMCOREINFO generated on the other system that is running the same first kernel. [-x VMLINUX] must be specified.

Example:

\# makedumpfile -g vmcoreinfo -x vmlinux

--config FILTERCONFIGFILE

Used in conjunction with -x VMLINUX option, to specify the filter config file FILTERCONFIGFILE that contains erase commands to filter out desired kernel data from vmcore while creating DUMPFILE. For filter command syntax please refer to makedumpfile.conf(5).

--eppic EPPICMACRO

Used in conjunction with -x VMLINUX option, to specify the eppic macro file that contains filter rules or directory that contains eppic macro files to filter out desired kernel data from vmcore while creating DUMPFILE. When directory is specified, all the eppic macros in the directory are processed.

-F

Output the dump data in the flattened format to the standard output for transporting the dump data by SSH.

Analysis tools (crash utility before version 5.1.2 or GDB) cannot read the flattened format directly. For analysis, the dump data in the flattened format should be rearranged to a normal DUMPFILE (readable with analysis tools) by -R option. By which option is specified with -F option, the format of the rearranged DUMPFILE is fixed. In other words, it is impossible to specify the DUMPFILE format when the dump data is rearranged with -R option. If specifying -E option with -F option, the format of the rearranged DUMPFILE is the ELF format. Otherwise, it is the kdump-compressed format. All the messages are output to standard error output by -F option because standard output is used for the dump data.

Example:

\# makedumpfile -F -c -d 31 -x vmlinux /proc/vmcore \

| ssh user@host "cat > dumpfile.tmp"

\# makedumpfile -F -c -d 31 -x vmlinux /proc/vmcore \

| ssh user@host "makedumpfile -R dumpfile"

\# makedumpfile -F -E -d 31 -i vmcoreinfo /proc/vmcore \

| ssh user@host "makedumpfile -R dumpfile"

\# makedumpfile -F -E --xen-vmcoreinfo VMCOREINFO /proc/vmcore \

| ssh user@host "makedumpfile -R dumpfile"

-R

Rearrange the dump data in the flattened format from the standard input to a normal DUMPFILE (readable with analysis tools).

Example:

\# makedumpfile -R dumpfile < dumpfile.tmp

\# makedumpfile -F -d 31 -x vmlinux /proc/vmcore \

| ssh user@host "makedumpfile -R dumpfile" Instead of using -R option, a perl script "makedumpfile-R.pl" rearranges the dump data in the flattened format to a normal DUMPFILE, too. The perl script does not depend on architecture, and most systems have perl command. Even if a remote host does not have makedumpfile, it is possible to rearrange the dump data in the flattened format to a readable DUMPFILE on a remote host by running this script.

Example:

\# makedumpfile -F -d 31 -x vmlinux /proc/vmcore \

| ssh user@host "makedumpfile-R.pl dumpfile"

--split

Split the dump data to multiple DUMPFILEs in parallel. If specifying DUMPFILEs on different storage devices, a device can share I/O load with other devices and it reduces time for saving the dump data. The file size of each DUMPFILE is smaller than the system memory size which is divided by the number of DUMPFILEs. This feature supports only the kdump-compressed format.

Example:

\# makedumpfile --split -d 31 -x vmlinux /proc/vmcore dumpfile1 dumpfile2

--num-threads THREADNUM

Using multiple threads to read and compress data of each page in parallel. And it will reduces time for saving DUMPFILE. Note that if the usable cpu number is less than the thread number, it may lead to great performance degradation. This feature only supports creating DUMPFILE in kdump-comressed format from VMCORE in kdump-compressed format or elf format.

Example:

\# makedumpfile -d 31 --num-threads 4 /proc/vmcore dumpfile

--reassemble

Reassemble multiple DUMPFILEs, which are created by --split option, into one DUMPFILE. dumpfile1 and dumpfile2 are reassembled into dumpfile on the following example.

Example:

\# makedumpfile --reassemble dumpfile1 dumpfile2 dumpfile

-b <order>

Cache 2^order pages in ram when generating DUMPFILE before writing to output. The default value is 4.

--cyclic-buffer buffer_size

Specify the buffer size in kilo bytes for bitmap data. Filtering processing will be divided into multi cycles to fix the memory consumption, the number of cycles is represented as:

num_of_cycles = system_memory / (buffer_size * 1024 * bit_per_bytes * page_size )

The lesser number of cycles, the faster working speed is expected. By default, buffer_size will be calculated automatically depending on system memory size, so ordinary users don't need to specify this option.

Example:

\# makedumpfile --cyclic-buffer 1024 -d 31 -x vmlinux /proc/vmcore dumpfile

--splitblock-size splitblock_size

Specify the splitblock size in kilo bytes for analysis with --split. If --splitblock N is specified, difference of each splitted dumpfile size is at most N kilo bytes.

Example:

\# makedumpfile --splitblock-size 1024 -d 31 -x vmlinux --split /proc/vmcore dumpfile1 dumpfile2

--work-dir

Specify the working directory for the temporary bitmap file. If this option isn't specified, the bitmap will be saved on memory. Filtering processing has to do 2 pass scanning to fix the memory consumption, but it can be avoided by using working directory on file system. So if you specify this option, the filtering speed may be bit faster. Example:

\# makedumpfile --work-dir /tmp -d 31 -x vmlinux /proc/vmcore dumpfile

--non-mmap

Never use mmap(2) to read VMCORE even if it supports mmap(2). Generally, reading VMCORE with mmap(2) is faster than without it, so ordinary users don't need to specify this option. This option is mainly for debugging.

Example:

\# makedumpfile --non-mmap -d 31 -x vmlinux /proc/vmcore dumpfile

--xen-syms XEN-SYMS

Specify the XEN-SYMS with debug information to analyze the xen's memory usage. This option extracts the part of xen and domain-0.

Example:

\# makedumpfile -E --xen-syms xen-syms /proc/vmcore dumpfile

--xen-vmcoreinfo VMCOREINFO

Specify VMCOREINFO instead of XEN-SYMS for analyzing the xen's memory usage.

VMCOREINFO should be made beforehand by makedumpfile with -g option, and it contains the xen's information.

Example:

\# makedumpfile -E --xen-vmcoreinfo VMCOREINFO /proc/vmcore dumpfile

-X

Exclude all the user domain pages from Xen kdump's VMCORE, and extracts the part of xen and domain-0. If VMCORE contains VMCOREINFO for Xen, it is not necessary to specify --xen-syms and --xen-vmcoreinfo.

Example:

\# makedumpfile -E -X /proc/vmcore dumpfile

--xen_phys_start xen_phys_start_address

This option is only for x86_64. Specify the xen_phys_start_address, if the xen code/data is relocatable and VMCORE does not contain xen_phys_start_address in the CRASHINFO. xen_phys_start_address can be taken from the line of "Hypervisor code and data" in /proc/iomem. For example, specify 0xcee00000 as xen_phys_start_address if /proc/iomem is the following:

-------------------------------------------------------

\# cat /proc/iomem

...

cee00000-cfd99999 : Hypervisor code and data

...

------------------------------------------------------- Example:

\# makedumpfile -E -X --xen_phys_start 0xcee00000 /proc/vmcore dumpfile

--message-level message_level

Specify the message types.

Users can restrict outputs printed by specifying message_level with this option. The message type marked with an X in the following table is printed. For example, according to the table, specifying 7 as message_level means progress indicator, common message, and error message are printed, and this is a default value. Note that the maximum value of message_level is 31.

message | progress | common | error | debug | report

level | indicator| message | message | message | message

---------+----------+---------+---------+---------+---------

0 | | | | |

1 | X | | | |

2 | | X | | |

3 | X | X | | |

4 | | | X | |

5 | X | | X | |

6 | | X | X | |

* 7 | X | X | X | |

8 | | | | X |

9 | X | | | X |

10 | | X | | X |

11 | X | X | | X |

12 | | | X | X |

13 | X | | X | X |

14 | | X | X | X |

15 | X | X | X | X |

16 | | | | | X

17 | X | | | | X

18 | | X | | | X

19 | X | X | | | X

20 | | | X | | X

21 | X | | X | | X

22 | | X | X | | X

23 | X | X | X | | X

24 | | | | X | X

25 | X | | | X | X

26 | | X | | X | X

27 | X | X | | X | X

28 | | | X | X | X

29 | X | | X | X | X

30 | | X | X | X | X

31 | X | X | X | X | X

--vtop virtual_address

This option is useful, when user debugs the translation problem of virtual address. If specifing virtual_address, its physical address is printed. It makes debugging easy by comparing the output of this option with the one of "vtop" subcommand of the crash utility. "--vtop" option only prints the translation output, and it does not affect the dumpfile creation.

--dump-dmesg

This option overrides the normal behavior of makedumpfile. Instead of compressing and filtering a VMCORE to make it smaller, it simply extracts the dmesg log from a VMCORE and writes it to the specified LOGFILE. If a VMCORE does not contain VMCOREINFO for dmesg, it is necessary to specfiy [-x VMLINUX] or [-i VMCOREINFO]. Example:

\# makedumpfile --dump-dmesg /proc/vmcore dmesgfile

\# makedumpfile --dump-dmesg -x vmlinux /proc/vmcore dmesgfile

--partial-dmesg

This option will make --dump-dmesg extract only dmesg logs since that buffer was last cleared on the crashed kernel, through "dmesg --clear" for example.

--mem-usage

This option is currently supported on x86_64, arm64, ppc64 and s390x. This option is used to show the page numbers of current system in different use. It should be executed in 1st kernel. By the help of this, user can know how many pages is dumpable when different dump_level is specified. It analyzes the 'System Ram' and 'kernel text' program segment of /proc/kcore excluding the crashkernel range, then calculates the page number of different kind per vmcoreinfo. So currently /proc/kcore need be specified explicitly. Example:

\# makedumpfile --mem-usage /proc/kcore

--diskset=VMCORE

Specify multiple VMCOREs created on sadump diskset configuration the same number of times as the number of VMCOREs in increasing order from left to right. VMCOREs are assembled into a single DUMPFILE. Example:

\# makedumpfile -x vmlinux --diskset=vmcore1 --diskset=vmcore2 dumpfile

-D

Print debugging message.

-h (--help)

Show help message and LZO/snappy support status (enabled/disabled).

-v

Show the version of makedumpfile.

--check-params

Only check whether the command-line parameters are valid or not, and exit. Preferable to be given as the first parameter.

--dry-run

Do not write the output dump file while still performing operations specified by other options. This option cannot be used with the --dump-dmesg, --reassemble and -g options.

--show-stats

Display report messages. This is an alternative to enabling bit 4 in the level provided to --message-level.

## ENVIRONMENT VARIABLES
TMPDIR

This environment variable is used in 1st kernel environment for a temporary memory bitmap file. If your machine has a lots of memory and you use small tmpfs on /tmp, makedumpfile can fail for a little memory because makedumpfile makes a very large temporary memory bitmap file in this case. To avoid this failure, you should specify --work-dir option to use file system on storage for the bitmap file.

## DIAGNOSTICS
makedumpfile exits with the following value.

0 : makedumpfile succeeded.

1 : makedumpfile failed without the following reasons.

2 : makedumpfile failed due to the different version between VMLINUX and VMCORE.

## AUTHORS
Written by Masaki Tachibana, and Ken'ichi Ohmichi.

## SEE ALSO
crash(8), gdb(1), kexec(8), makedumpfile.conf(5)


makemap

package: makemap

title: makemap(8)

summary: create database maps for sendmail

text:
# makemap(8)

## NAME
makemap - create database maps for sendmail

## SYNOPSIS
makemap [-C file] [-N] [-c cachesize] [-d] [-D commentchar] [-e] [-f] [-i type] [-l] [-o] [-r] [-s] [-t delim] [-u] [-v] maptype mapnam

## DESCRIPTION
Makemap creates the database maps used by the keyed map lookups in sendmail(8). It reads input from the standard input and outputs them to the indicated mapname.

Depending on how it is compiled, makemap handles different database formats, selected using the maptype parameter. They may be

btree

B-Tree format maps. This requires the new Berkeley DB library.

hash

Hash format maps. This also requires the Berkeley DB library.

cdb

CDB (Constant DataBase) format maps. This requires the tinycdb library.

implicit

The first available format in the following order: hash, dbm, and cdb.

In all cases, makemap reads lines from the standard input consisting of two words separated by white space. The first is the database key, the second is the value. The value may contain ``%n'' strings to indicate parameter substitution. Literal percents should be doubled (``%%''). Blank lines and lines beginning with ``#'' are ignored.

Notice: do not use makemap to create the aliases data base, but newaliases which puts a special token into the data base that is required by sendmail.

If the TrustedUser option is set in the sendmail configuration file and makemap is invoked as root, the generated files will be owned by the specified TrustedUser.

### Flags
-C

Use the specified sendmail configuration file for looking up the TrustedUser option.

-N

Include the null byte that terminates strings in the map. This must match the -N flag in the sendmail.cf ``K'' line.

-c

Use the specified hash and B-Tree cache size.

-D

Use to specify the character to use to indicate a comment (which is ignored) instead of the default of '#'.

-d

Allow duplicate keys in the map. This is only allowed on B-Tree format maps. If two identical keys are read, they will both be inserted into the map.

-e

Allow empty value (right hand side).

-f

Normally all upper case letters in the key are folded to lower case. This flag disables that behaviour. This is intended to mesh with the -f flag in the K line in sendmail.cf. The value is never case folded.

-i

Use the specified type as fallback if the given maptype is not available.

-l

List supported map types.

-o

Append to an old file. This allows you to augment an existing file. Note: this might not be supported by all database types, e.g., cdb.

-r

Allow replacement of existing keys. Normally makemap complains if you repeat a key, and does not do the insert.

-s

Ignore safety checks on maps being created. This includes checking for hard or symbolic links in world writable directories.

-t

Use the specified delimiter instead of white space (also for dumping a map).

-u

dump (unmap) the content of the database to standard output.

-v

Verbosely print what it is doing.

## Example
makemap hash /etc/mail/access < /etc/mail/access

## SEE ALSO
sendmail(8), newaliases(1)

## HISTORY
The makemap command appeared in 4.4BSD.


malcontent-timer-extension-agent

package: malcontent

title: malcontent-timer-extension-agent(8)

summary: timer\-extension\-agent — Parental Controls Timer Extension Agent

text:
# malcontent-timer-extension-agent(8)

## NAME
malcontent-timer-extension-agent — Parental Controls Timer Extension Agent

## SYNOPSIS
malcontent-timer-extension-agent [-a bus-address]

## DESCRIPTION
malcontent-timer-extension-agent is an agent process for deciding whether to grant extension requests from child accounts which have screen time limits set as part of parental controls.

This implementation of the agent process raises a polkit action to allow a parent to authorize (or reject) the screen time limit extension request using a polkit dialog on the local machine.

Other agent implementations may do more complex checks in future. For example, by messaging the parent’s phone to allow them to authorize/reject requests remotely.

malcontent-timer-extension-agent is designed to be run by systemd(1), being D-Bus activated. There should be no need to run malcontent-timer-extension-agent manually. Use malcontent-client(8) to request screen time limit extensions from the command line.

## OPTIONS
-a, --bus-address=

Address of a D-Bus message bus to connect to. This is intended for debugging use only. (Default: The system bus.)

-t, --inactivity-timeout=

Inactivity timeout (in milliseconds) to wait before exiting the service if no requests have been made during that period. If set to 0, the timeout is disabled and the service will run indefinitely. (Default: 30 seconds.)

## ENVIRONMENT
malcontent-timer-extension-agent supports the standard GLib environment variables for debugging. These variables are not intended to be used in production:

$G_MESSAGES_DEBUG

This variable can contain one or more debug domain names to display debug output for. The value all will enable all debug output. The default is for no debug output to be enabled.

## EXIT STATUS
malcontent-timer-extension-agent may return one of several error codes if it encounters problems.

0

No problems occurred. The agent ran, responded to zero or more requests, and then exited due to being explicitly closed, or timing out due to finishing all requests.

1

An invalid option was passed to malcontent-timer-extension-agent on startup.

2

The D-Bus name for malcontent-timer-extension-agent was not available.

3

malcontent-timer-extension-agent was run in an inappropriate environment, for example as the root user.

## FILES
/lib/systemd/system/malcontent-timer-extension-agent.service

systemd(1) service file which specifies the runtime environment for malcontent-timer-extension-agent. See systemd.service(5).

## SEE ALSO
malcontent-client(8), malcontent-timerd(8)

## BUGS
Any bugs which are found should be reported on the project website:

https://gitlab.freedesktop.org/pwithnall/malcontent/-/issues

## AUTHOR
GNOME Foundation, Inc. Philip Withnall

## COPYRIGHT
Copyright © 2025 GNOME Foundation, Inc.


malcontent-timerd

title: malcontent-timerd(8)

summary: timerd — Parental Controls Timer Daemon

text:
# malcontent-timerd(8)

## NAME
malcontent-timerd — Parental Controls Timer Daemon

## SYNOPSIS
malcontent-timerd [-a bus-address]

## DESCRIPTION
malcontent-timerd is a coordination process for storing and querying session and app usage records. Child accounts which are under parental control on the computer submit usage records of their time spent using a login session or apps, and malcontent-timerd combines and stores those records for a period of weeks to allow session and app usage limits to be imposed on the child account, and to allow parent users to query the child’s usage of the computer.

malcontent-timerd is designed to be run by systemd(1), being D-Bus activated. There should be no need to run malcontent-timerd manually. Use malcontent-client(8) to submit usage entries and query session limits and time remaining from the command line.

## OPTIONS
-a, --bus-address=

Address of a D-Bus message bus to connect to. This is intended for debugging use only. (Default: The system bus.)

-t, --inactivity-timeout=

Inactivity timeout (in milliseconds) to wait before exiting the service if no requests have been made during that period. If set to 0, the timeout is disabled and the service will run indefinitely. (Default: 30 seconds.)

## ENVIRONMENT
malcontent-timerd supports the standard GLib environment variables for debugging. These variables are not intended to be used in production:

$G_MESSAGES_DEBUG

This variable can contain one or more debug domain names to display debug output for. The value all will enable all debug output. The default is for no debug output to be enabled.

## EXIT STATUS
malcontent-timerd may return one of several error codes if it encounters problems.

0

No problems occurred. The timer daemon ran, responded to zero or more requests, and then exited due to being explicitly closed, or timing out due to finishing all requests.

1

An invalid option was passed to malcontent-timerd on startup.

2

The D-Bus name for malcontent-timerd was not available.

3

malcontent-timerd was run in an inappropriate environment, for example as the root user.

## FILES
/lib/systemd/system/malcontent-timerd.service

systemd(1) service file which specifies the runtime environment for malcontent-timerd. See systemd.service(5).

## SEE ALSO
malcontent-client(8), malcontent-timer-extension-agent(8)

## BUGS
Any bugs which are found should be reported on the project website:

https://gitlab.freedesktop.org/pwithnall/malcontent/-/issues

## AUTHOR
GNOME Foundation, Inc. Philip Withnall

## COPYRIGHT
Copyright © 2025 GNOME Foundation, Inc.


malcontent-webd

title: malcontent-webd(8)

text:
# malcontent-webd(8)

## NAME
malcontent-webd — Parental Controls Web Filtering Daemon

## SYNOPSIS
malcontent-webd [-a bus-address]

## DESCRIPTION
malcontent-webd is a coordination process for controlling web filtering blocklists and allowlists. Child accounts which are under parental control on the computer receive blocklists from malcontent-webd and use these to determine which websites to allow or block when browsing the internet.

malcontent-webd is designed to be run by systemd(1), being D-Bus activated (to update the filter list for a specific user) or activated on a systemd timer (to update the filter lists for all users). There should be no need to run malcontent-webd manually. Use malcontent-client(8) to edit web filtering blocklists.

The actual filtering of web traffic in child sessions is done by an NSS module, nss-malcontent(8).

If an error occurs while updating the filter lists for all users, on a systemd timer, error information will be written to /var/lib/malcontent-webd/update-error. On a successful update this file will be deleted.

The error file is a key file, for example:

[Web Filter Update Error]

ErrorCode=org.freedesktop.MalcontentWeb1.Filtering.Error.Downloading # this field is optional

ErrorMessage[en_GB]=There was an error downloading foo from blah. # this field is mandatory

## OPTIONS
-a, --bus-address=

Address of a D-Bus message bus to connect to. This is intended for debugging use only. (Default: The system bus.)

-t, --inactivity-timeout=

Inactivity timeout (in milliseconds) to wait before exiting the service if no requests have been made during that period. If set to 0, the timeout is disabled and the service will run indefinitely. (Default: 30 seconds.)

## ENVIRONMENT
malcontent-webd supports the standard GLib environment variables for debugging. These variables are not intended to be used in production:

$G_MESSAGES_DEBUG

This variable can contain one or more debug domain names to display debug output for. The value all will enable all debug output. The default is for no debug output to be enabled.

## EXIT STATUS
malcontent-webd may return one of several error codes if it encounters problems.

0

No problems occurred. The web filtering daemon ran, responded to zero or more requests, and then exited due to being explicitly closed, or timing out due to finishing all requests.

1

An invalid option was passed to malcontent-webd on startup.

2

The D-Bus name for malcontent-webd was not available.

3

malcontent-webd was run in an inappropriate environment, for example as the root user.

## FILES
/lib/systemd/system/malcontent-webd.service

systemd(1) service file which specifies the runtime environment for malcontent-webd. See systemd.service(5).

## SEE ALSO
malcontent-client(8)

## BUGS
Any bugs which are found should be reported on the project website:

https://gitlab.freedesktop.org/pwithnall/malcontent/-/issues

## AUTHOR
GNOME Foundation, Inc. Philip Withnall

## COPYRIGHT
Copyright © 2025 GNOME Foundation, Inc.