liquidctl

package: liquidctl

title: liquidctl(8)

text:
# liquidctl(8)

## NAME
liquidctl - monitor and control liquid coolers and other devices

## SYNOPSIS
liquidctl

[options] list

liquidctl

[options] initialize [all]

liquidctl

[options] status

liquidctl

[options] set channel speed (temperature percentage) ...

liquidctl

[options] set channel speed percentage

liquidctl

[options] set channel color mode [color ...]

liquidctl

--version

liquidctl

--help

## DESCRIPTION
liquidctl is a utility for overseeing and controlling some hardware monitoring devices not yet supported at the kernel level. Because liquidctl directly accesses the hardware devices, root privileges are generally required, though this can be avoided with appropriate udev rules.

liquidctl list outputs all compatible devices found on the system. In case more than one device is found, the desired one can be selected for later invocations with --match=substring, where substring matches part of the desired device's description using a case insensitive comparison.

liquidctl list --verbose enables the display of additional identifiers and addresses that can also be used to select specific devices. These can be better suited for certain use cases, such as non-interactive scripts.

liquidctl initialize prepares a device for later commands, and most devices must be initialized after every boot or when resuming from a suspended state. Unless finer control is required, all devices can be initialized at once with liquidctl initialize all. Some devices may output some information at this stage.

liquidctl status displays the status of all devices that match the provided filtering options.

liquidctl set channel speed allows the user to set fan and pump speeds. These, depending on the device, can be set to fixed duty values, variable temperature\[u2013]duty curves, or both.

liquidctl set channel color allows the user to configure and set lighting modes. Supported lighting modes and additional options vary by device and are listed in later sections of this manual. Each color can be specified as:

- hexadecimal RGB with or without prefix '0x': ff7f3f;

- decimal RGB triple, R,G,B ∊ [0, 255]: rgb(255,127,63);

- hue-saturation-value HSV triple, H ∊ [0, 360], S,V ∊ [0, 100]: hsv(20,75,100);

- hue-saturation-lightness HSL triple, H ∊ [0, 360], S,L ∊ [0, 100]: hsl(20,100,62).

liquidctl set channel screen allows the user to configure the LCD screen integrated into some AIO models.

liquidctl automatically detects when a kernel driver is bound to the device and, whenever possible, uses it instead of directly accessing the device. Alternatively, direct access to the device can be forced with --direct-access.

## OPTIONS

### Device selection options
Devices can be selected using one or more values taken from list --verbose.

-m substring, --match=substring

Filter devices by case insensitive substring of device description.

-n number, --pick=number

Pick among many results for a given filter.

--vendor=id

Filter devices by hexadecimal vendor id.

--product=id

Filter devices by hexadecimal product id.

--release=number

Filter devices by hexadecimal release number.

--serial=number

Filter devices by serial number.

--bus=bus

Filter devices by bus.

--address=address

Filter devices by address in bus.

--usb-port=port

Filter devices by USB port in bus.

-d index, --device=index

(Deprecated), select device by listing index.

### Animation options
Some devices and animation modes support additional options.

--speed=value

Abstract animation speed (device/mode specific).

--time-per-color=value

Time to wait on each color (seconds).

--time-off=value

Time to wait with the LED turned off (seconds).

--alert-threshold=number

Threshold temperature for a visual alert (degrees Celsius).

--alert-color=color

Color used by the visual high temperature alert.

--direction=string

If the pattern should move forward or backward.

--start-led=number

The first led to start the effect at.

--maximum-leds=number

The number of LED's the effect should apply to.

### Other options
--fan-mode=channel:mode[,...]

Set the fan modes.

--single-12v-ocp

Enable single rail +12V OCP.

--pump-mode=mode

Set the pump mode.

--temperature-sensor=number

The temperature sensor number for the Commander Pro.

--legacy-690lc

Use Asetek 690LC in legacy mode (old Krakens).

--non-volatile

Store on non-volatile controller memory.

--direct-access

Directly access the device despite kernel drivers.

--unsafe=features

Comman-separated bleeding-edge features to enable.

-v, --verbose

Output additional information.

-g, --debug

Show debug information on stderr.

--json

Output machine-readable JSON. Only supported with list, initialize and status.

--version

Display the version number.

--help

Show the embedded help.

## EXIT STATUS
1 if there was an error, 0 otherwise.

## ENVIRONMENT
If LANG is set to C, non-ASCII characters are escaped from the output of --json.

## FILES
$XDG_RUNTIME_DIR/liquidctl/*, /var/run/liquidctl/*, /tmp/liquidctl/*

Internal data used by some drivers.

## EXAMPLE
liquidctl

list --verbose

liquidctl

initialize all

liquidctl

--match kraken set pump speed 90

liquidctl

--product 170e set led color fading 350017 ff2608

liquidctl

status

## DEVICE SPECIFICS

### Aquacomputer Quadro
Cooling channels: (D5 Next:) fan, pump; (Octo:) fan[1-8]; (Quadro:) fan[1-4]; (Farbwerk/Farbwerk 360:) not applicable.

Lighting channels: not yet supported.

### ASUS Ryujin II 360
Cooling channels: pump, fans, pump-fan, external-fans.

### ASUS Ryujin III 360, EVA, Extreme, White
Cooling channels: pump, pump-fan.

Screen: not yet supported.

### ASUS Ryuo II 240
Cooling channels: fans, fan. There is only a single fan channel.

### Corsair Commander ST
Cooling channels: fans, fan[1-6]; (only non-XT/Elite Capellix:) pump.

Lighting channels: not yet supported.

### Corsair Obsidian 1000D
Cooling channels (only Commander Pro and Obsidian 1000D): sync, fan[1-6].

Where the fan connection types can be set with --fan-mode=channel:mode[,...], where the allowed modes are: off, dc, pwm.

Lighting channels: (only Lighting Node Core:) led; (only Commander Pro and Lighting Node Pro:) sync, led[1-2].

Mode

\#colors

clear

0

off

0

fixed

1

color_shift

2

color_pulse

2

color_wave

2

visor

2

blink

2

marquee

1

sequential

1

rainbow

0

rainbow2

0

When applicable the animation speed can be set with --speed=value, where the allowed values are: fast, medium, slow.

The animation direction can be set with --direction=value, where the allowed values are: forward or backward. --start-led=number, the first LED that the lighting effect should be for. --start-led=number, the first LED that the lighting effect should be for. --maximum-led=number, the number of LEDs that the lighting effect should applied to. --temperature-sensor=number, The temperature sensor that should be used to control the fan curves, probe 1 by default.

### Corsair Hydro H110i GT
Cooling channels: fan1, fan2.

Pump mode (initialize --pump-mode mode): quiet (default), extreme.

Lighting channels: not yet supported.

### EVGA CLC 120 (CL12), 240, 280, 360
Cooling channels: pump, fan.

Lighting channels: logo.

Mode

\#colors

notes

rainbow

0

only available on EVGA coolers

fading

2

blinking

1

fixed

1

blackout

0

no high-temperature alerts

The rainbow mode speed can be configured with --speed=[1–6]. The speed of the other modes is instead customized with --time-per-color (fading and blinking) and --time-off (blinking only).

All modes except blackout support a visual high-temperature alert configured with --alert-threshold and --alert-color.

All current settings can be saved on non-volatile on-board memory by passing --non-volatile to any write command. However, since write-cycles are limited, this option should be used sparingly.

### Corsair H100i Pro, H115i Pro, H150i Pro
Cooling channels: fan, fan[1–2]; (only H150i Pro:) fan3.

Pump mode (initialize --pump-mode mode): quiet, balanced (default), performance.

Lighting channel: logo.

Mode

\#colors

alert

3

shift

2–4

pulse

1–4

blinking

1–4

fixed

1

### Corsair Hydro H100i, H115i, H150i Elite RGB
Cooling channels: fan, fan[1–2]; (only H150i Pro XT/Elite RGB:) fan3.

Pump mode (initialize --pump-mode mode): quiet, balanced (default), extreme.

Lighting channels: sync, led.

Channel

Mode

\#colors (Platinum)

\#colors (Pro XT/Elite RGB)

\#colors (Platinum SE)

led

off

0

0

0

led

fixed

1

1

1

led

super-fixed

24

16

48

### Lian Li Uni SL, SL v2, AL, AL v2, SL-Infinity
Cooling channels: fan[1–4].

Lighting channels: none.

### MSI MPG Coreliquid K360
Cooling channels: fan1, fan2, fan3, fans, waterblock-fan, pump.

Lighting channels: sync.

LCD screens: lcd.

Mode

\#colors

disable

0

steady

1

blink

0

breathing

1

clock

2

color pulse

0

color ring

0

color ring double flashing

0

color ring flashing

0

color shift

0

color wave

2

corsair ique

0

disable2

0

double flashing

1

double meteor

0

energy

0

fan control

0

fire

2

flashing

1

jazz

0

jrainbow

0

lava

0

lightning

1

marquee

1

meteor

1–2

movie

0

msi marquee

1

msi rainbow

0

planetary

0

play

0

pop

0

rainbow

0

rainbow double flashing

0

rainbow flashing

0

rainbow wave

0

random

0

rap

0

stack

1

visor

2

water drop

1

When applicable the animation speed can be set with --speed=value, where the allowed values are: 0, 1 and 2. The LCD screen settings can be controlled with the settings flag, that requires the arguments "brightness;direction" where an allowed brightness is an integer in the range 0-100, and orientations 0-3 correspond to the orientations up, right, down and left.

### NZXT Kraken X31, X41, X61
Supports the same modes and options as a Corsair Hydro H80i GT (or similar), but requires --legacy-690lc to be passed on all invocations.

### NZXT Kraken X42, X52, X62, X72
Cooling channels (only X42, X52, X62, X72): pump, fan.

Lighting channels: logo, ring, sync.

Mode

logo

ring

\#colors

off

yes

yes

0

fixed

yes

yes

1

super-fixed

yes

yes

1–9

fading

yes

yes

2–8

alternating

no

yes

2

breathing

yes

yes

1–8

super-breathing

yes

yes

1–9

pulse

yes

yes

1–8

tai-chi

no

yes

2

water-cooler

no

yes

0

loading

no

yes

1

wings

no

yes

1

When applicable the animation speed can be set with --speed=value, where the allowed values are: slowest, slower, normal, faster, fastest. The animation direction can be set with --direction=value, where the allowed values are: forward or backward.

### NZXT Kraken X53, X63, X73
Cooling channels: pump.

Lighting channels: external, ring, logo, sync.

### NZXT Kraken Z53, Z63, Z73
Cooling channels: pump, fan.

Lighting channels: external.

LCD screens: lcd.

### NZXT Kraken 2024 Plus
Cooling channels: pump, fan.

Lighting channels: none.

LCD screens: lcd.

Mode

\#colors

off

0

fixed

1

fading

2–8

super-fixed

1–40

alternating-[3-6]

1–2

pulse

1–8

breathing

1–8

super-breathing

1–40

candle

1

starry-night

1

loading

1

tai-chi

1–2

water-cooler

2

wings

1

When applicable the animation speed can be set with --speed=value, where the allowed values are: slowest, slower, normal, faster, fastest. The animation direction can be set with --direction=value, where the allowed values are: forward or backward.

### Corsair RM650i, RM750i, RM850i, RM1000i
Cooling channels: fan.

Lighting channels: none.

Setting a fixed fan speed changes the fan mode to software control. To revert back to hardware control, run initialize again.

(Experimental feature) The +12V rails normally function in multiple-rail mode. Single-rail mode can be selected by passing --single-12v-ocp to initialize. To revert back to multiple-rail mode, run initialize again without that flag.

### NZXT E500, E650, E850
Cooling channels: none (feature not supported yet).

Lighting channels: none.

### NZXT Grid+ V3
Cooling channels: fan[1–6], sync.

Lighting channels: none.

### NZXT Smart Device (V1)
Cooling channels: fan[1–3], sync.

Lighting channels: led.

Mode

\#colors

off

0

fixed

1

super-fixed

1–40

fading

2–8

alternating

2

breathing

1–8

super-breathing

1–40

pulse

1–8

candle

1

wings

1

When applicable the animation speed can be set with --speed=value, where the allowed values are: slowest, slower, normal, faster, fastest. The animation direction can be set with --direction=value, where the allowed values are: forward or backward.

### NZXT 2023 RGB Controller
Cooling channels (only Smart Device V2, H1 V2 and RGB & Fan Controllers): fan[1–3].

Lighting channels (all but H1 V2): led[1–6], sync.

Mode

\#colors

off

0

fixed

1

super-fixed

1–40

fading

2–8

alternating-[3-6]

2

pulse

1–8

breathing

1–8

super-breathing

1–40

candle

1

starry-night

1

wings

1

When applicable the animation speed can be set with --speed=value, where the allowed values are: slowest, slower, normal, faster, fastest. The animation direction can be set with --direction=value, where the allowed values are: forward or backward.

### ASUS TUF RTX 3060 Ti OC
Cooling channels: none.

Lighting channels: led.

Mode

\#colors

off

0

fixed

1

flash

1

breathing

1

rainbow

0

### Corsair Vengeance RGB
Cooling channels: none.

Lighting channels: led.

Mode

\#colors

off

0

fixed

1

breathing

1–7

fading

2–7

When applicable the animation speed can be set with --speed=value, where the allowed values are: slowest, slower, normal, faster, fastest.

### ASUS Aura LED Controller
Cooling channels: none.

Lighting channels: led[1–4], sync.

Mode

\#colors

off

0

static

1

breathing

1

flashing

1

spectrum_cycle

0

rainbow

0

spectrum_cycle_breathing

0

chase_fade

1

spectrum_cycle_chase_fade

0

chase

1

spectrum_cycle_chase

0

spectrum_cycle_wave

0

chase_rainbow_pulse

0

rainbow_flicker

0

gentle_transition

0

wave_propagation

0

wave_propagation_pause

0

red_pulse

0

### Gigabyte RGB Fusion 2.0 8297 Controller
Cooling channels: none.

Lighting channels: led[1–8], sync.

Mode

\#colors

off

0

fixed

1

pulse

1

(double-)?flash

1

color-cycle

0

When applicable the animation speed can be set with --speed=value, where the allowed values are: slowest, slower, normal, faster, fastest, ludicrous.

### EVGA GTX 1080 FTW
Cooling channels: none.

Lighting channels: led.

Mode

\#colors

off

0

fixed

1

breathing

1

rainbow

0

### Lian Li GA II LCD
Cooling channels: pump, fan.

This device does not support speed profiles for any channels, only fixed speeds are supported.

Lighting channels: pump, fan.

Mode

pump

fan

\#colors

rainbow

yes

yes

0

rainbow-morph

yes

yes

0

static

yes

yes

1

breathing

yes

yes

1

runway

yes

yes

2

meteor

yes

yes

4

ticker-tape

yes

no

4

fluctuation

yes

no

4

transmit

yes

no

2

colorful-starry-night

yes

no

0

static-starry-night

yes

no

1

big-bang

yes

no

4

burst

yes

no

1

color-morph

yes

no

0

bounce

yes

no

4

When applicable the animation speed can be set with --speed=value, where the allowed values are: slowest, slower, normal, faster, fastest. The animation direction can be set with --direction=value, where the allowed values are: forward or backward.

## SEE ALSO
The complete documentation is available in the project's sources and homepage.


lircd

package: lirc

title: lircd(8)

text:
# lircd(8)

## NAME
lircd - Decode infrared signals and provide them on a socket.

## SYNOPSIS
lircd [options] [config file]

## DESCRIPTION
The main task of lircd is to decode the infrared signals and provide an uniform interface for client applications. Clients can connect to lircd through a Unix domain socket, by default /var/run/lirc/lircd. Using this socket they will get the infrared codes received by lircd and they can send commands to lircd.

## ARGUMENTS
config file

The configuration file, by default /etc/lirc/lircd.conf. A relative path is interpreted from /etc/lirc. The default configuration file includes all files in /etc/lircd.conf.d.

Each remote which should be decoded by lircd usually requires that a specific file is used e. g., by copying it to /etc/lirc/lirc.conf.d/. The format is described in lircd.conf(5). Configuration files could be found using irdb-get(1) or lirc-setup(1). It's also possible to generate a config file using irrecord(1)

## OPTIONS
Common options:

-d, --device <device>

Select the character device which lircd should read from. The default is currently /dev/lirc0 on most systems.

Some drivers, including the default devinput driver, supports the auto device which picks the first usable device found for the actual driver.

When using the devinput driver name=STRING or phys=STRING can be used to select the device; lircd will look in /dev/input to find a device with a matching description. This is useful in case the device name isn't fixed. STRING may contain the '*' and '?' wildcards and '\' to mark them as literal. Use mode2 --driver devinput --list-devices to list the actual devices.

-H, --driver <driver>

The driver to use. Using --driver help lists all available drivers, see DRIVER LOADING below.

-h, --help

Displays short help message.

Other options:

-a, --allow-simulate

Enable the SIMULATE command which can be issued using irsend(1) or the client API. This will allow simulating arbitrary IR events from the command line. Use this option with caution because it will give all users with access to the lircd socket wide control over the system. E.g., if you have configured your system to shut down by a button press on your remote control, everybody will be able to shut down your system from the command line.

-c, --connect [host[:port]][,[host[:port]]]

Connects to other lircd servers that provide a network socket at the given host and port number (see --listen). The number of such connections is currently limited to 100. The connecting lircd instance will receive IR events from the lircd instance it connects to. To connect to multiple servers, add them as a comma separated list.

-e, --effective-user <uid>

If started as user root, lircd drops it privileges and runs as user <uid> after opening files etc.

-i, --immediate-init

Lircd normally initializes the driver when the first client connects. If this option is selected, the driver is instead initialized immediately at start.

-A, --driver-options key:value[|key:value...]

Set one or more options for the driver. The argument is a list of key:value pairs delimited by '|'. The key can not contain spaces, but such are allowed in the value part. Certain characters including '#' and ';' are used as comment markers in the config file and are not allowed anywhere.

-Y, --dynamic-codes [EXPERIMENTAL]

Allows use of codes which have been decoded for one remote but are not defined in lircd.conf. New codes are dynamically created with a default name. This feature is experimental and subject to all sorts of changes. It has not ben tested thoroughly.

-l, --listen [[address:]port]]

Let lircd listen for network connections on the given address/port. The default address is 0.0.0.0, which means that connections on all network interfaces will be accepted. The address must be given in dotted numerical form. Port defaults to 8765. The listening lircd instance will send all IR events to the connecting lircd instances without any security checks.

On non-glibc platforms the address:port argument is mandatory, but can be given as an empty string e. g. --listen= which then defaults to 0.0.0.0:8765.

-L, --logfile <logfile path>

Select the lircd daemon log file. logfile is either the string 'syslog' indicating that syslog(1) should be used or a log file path. The default is to use syslog.

-D, --loglevel [level]

Determine the amount of logging information. level can be a symbolic syslog level: 'error','warning, 'info', 'notice' or 'debug'. lircd also defines three additional levels 'trace', 'trace1' and 'trace2' which gives even more messages ('trace2' bringing the most). However, in the log these messages are marked as 'debug'.

On non-glibc platforms the level argument is mandatory, but can be given as an empty string e. g. --loglevel= which then defaults to debug.

The level can also be an integer in the range 3 (almost no messages) to 10.

-O, --options-file <path>

File containing default values for all options. A relative path is interpreted from current directory. See [FILES] below.

-o, --output <output socket>

Select Unix domain socket, which lircd will write remote key codes to. The default currently is /var/run/lirc/lircd.

-p, --permission <perm>

Gives the file permission of the output socket if it has to be created in octal representation. See chmod(1). If no --permission option is given when the socket is initially created the default is to give all users read and write permissions (0666 in octal representation). If the socket already exists this option has no effect.

-p, --pidfile <path>

Select the lircd daemon pid file, defaults to /var/run/lirc/lircd.pid.

-U --plugindir <path>

Sets the directory from which lircd loads it's userspace drivers. These are *.so files, by default found as described under DRIVER LOADING. The argument is a :-separated search path.

-R, --repeat-max <limit>

Sets an upper limit to the number of repeats when sending a signal. The current default is 600. A SEND_START request will repeat the signal this many times. Also, if the number of repeats in a SEND_ONCE request exceeds this number, it will be replaced by this number.

## SOCKET BROADCAST MESSAGES FORMAT
When decoding a button press or receiving a SIGHUP signal lircd.conf lircd broadcasts messages to all connected clients.

For each decoded button press a package is made available on the socket. This is printable data formatted as:

```
        <code> <repeat count> <button name> <remote control name>
```

e.g.,

```
        0000000000f40bf0 00 KEY_UP ANIMAX
```

The fields are:

code

A 16 hexadecimal digits number encoding of the IR signal. It's usage in applications is deprecated and it should be ignored.

repeat count

shows how long the user has been holding down a button. The counter will start at 0 and increment each time a new IR signal has been received.

button name

is the name of a key defined in the lircd.conf file.

remote control name

is the mandatory name attribute in the lircd.conf config file.

These packets are broadcasted to all clients. The only other situation when lircd broadcasts to all clients is when it receives the SIGHUP signal and successfully re-reads its config file. Then it will send a SIGHUP packet to its clients indicating that its configuration might have changed. The sighup packet is three lines

```
        BEGIN

        SIGHUP

        END
```

## SOCKET COMMAND INTERFACE
Applications can also send commands to lircd over the socket interface. The most common task is sending data, but there are also other commands. Each command is a single printable line, terminated with a newline. For each command, lircd replies with a reply package.

Supported commands:

SEND_ONCE <remote control> <button name> [repeats]

Tell lircd to send the IR signal associated with the given remote control and button name, and then repeat it repeats times. repeats is a decimal number between 0 and repeat_max. The latter can be given as a --repeat-max command line argument to lircd, and defaults to 600. If repeats is not specified or is less than the minimum number of repeats for the selected remote control, the minimum value will be used.

SEND_START <remote control name> <button name>

Tell lircd to start repeating the given button until it receives a SEND_STOP command. However, the number of repeats is limited to repeat_max. lircd won't accept any new send commands while it is repeating.

SEND_STOP <remote control name> <button name>

Tell lircd to abort a SEND_START command.

LIST [remote control]

Without arguments lircd replies with a list of all defined remote controls. Given a remote control argument, lircd replies with a list of all keys defined in the given remote.

SET_INPUTLOG [path]

Given a path, lircd will start logging all received data on that file. The log is printable lines as defined in mode2(1) describing pulse/space durations. Without a path, current logfile is closed and the logging is stopped.

DRV_OPTION key value

Make lircd invoke the drvctl_func(DRVCTL_SET_OPTION, option) with option being made up by the parsed key and value. The return package reflects the outcome of the drvctl_func call.

SIMULATE key data

Given key data, instructs lircd to send this to all clients i. e., to simulate that this key has been decoded. The key data must be formatted exactly as the packet described in [SOCKET BROADCAST MESSAGES FORMAT], notably is the number of digits in code and repeat count hardcoded. This command is only accepted if the --allow-simulate command line option is active.

SET_TRANSMITTERS transmitter mask

Make lircd invoke the drvctl_func(LIRC_SET_TRANSMITTER_MASK, &channels), where channels is the decoded value of transmitter mask. See lirc(4) for more information.

VERSION

Tell lircd to send a version packet response.

The protocol guarantees that broadcasted messages won't interfere with reply packets. But broadcasts may appear at any point between packets. The only exception are SIGHUP packages. These may appear just after you have sent a command to lircd, so you have to make sure you don't confuse them with replies.

The format of the reply packet is

```
  BEGIN

  <command>

  [SUCCESS|ERROR]

  [DATA

  n

  n lines of data]

  END
```

If the command was successful, data is only sent for the commands that return some information. Note that a packet containing 0 lines of data can be a valid reply.

## RUNNING AS REGULAR USER
Traditionally lircd has been running as root since accessing kernel devices like /dev/lirc0 by default requires root privileges. However, running a long-running service like this is a major security issue.

The lirc distribution contains example udev rules which makes /dev/lirc[0-9] , USB and serial devices accessible by the lirc user. Using these rules, it is possible to run lircd as a regular user and group such as lirc.

## FILES
/etc/lirc/lircd.conf

Main config file, see lircd.conf(5).

/etc/lirc/lirc_options.conf

The options file. lircd handles the values under the [lircd] section in this file. The location can be changed using the -O/--options-file command-line option or using the environment variable LIRC_OPTIONS_PATH. The values here are used as defaults for any option not present on command line.

## ENVIRONMENT
LIRC_OPTIONS_PATH

Options file path, see FILES.

LIRC_PLUGINDIR

Plugin load path, se DRIVER LOADING.

LIRC_DEBUG_OPTIONS

If set, enables debugging in early stages when the --debug option is yet not parsed.

## DRIVER LOADING
Drivers are loaded dynamically. This is done from a traditional *ux ´:´-separated path where each component in the path is searched (leading part first, trailing last).

The path used for this is determined by (falling priority):

- The --plugindir option.

- The 'plugindir' entry in the [lircd] section of the lirc_options.conf file.

- The environment variable LIRC_PLUGINDIR.

- A hardcoded default (/usr/lib64/lirc/plugins).

## SIGNALS
HUP

On receiving SIGHUP lircd re-reads the lircd.conf configuration file (but not lirc_options.conf) and adjusts itself if the file has changed.

USR1

On receiving SIGUSR1 lircd makes a clean exit.

## DAEMONS
lircd is a daemon. It should be started in some system-dependent init script. By default, lirc ships with systemd files enabling user to control the lircd service.

## SEE ALSO
irdb-get(1)

lirc-setup(1)

lircd.conf(5)

irrecord(1)

lirc(4)

lircd-uinput(8)

branch: sisyphus


lircd-setup

title: lircd-setup(8)

text:
# lircd-setup(8)

## NAME
lircd-setup - Run setup commands in lirc_options.conf

## SYNOPSIS
lircd-setup <config-file>

## DESCRIPTION
This program runs commands defined in the keys code and code1 .. code10 in the modinit section of the config file.

It's used as a one-shot service invoked before lircd(8) , running code which needs root privileges.

The config file defaults to /etc/lirc/lirc_options.conf if not given as command line argument.

## SEE ALSO
lircd(8)


lircd-uinput

title: lircd-uinput(8)

text:
# lircd-uinput(8)

## NAME
lircd-uinput - Forward lirc button presses as uinput events

## SYNOPSIS
lircd-uinput [options]... [lircd output socket]

lircd-uinput [options]... [file]

## DESCRIPTION
lircd-uinput reads decoded button press events from a lircd(8) output socket and injects these as key events to the kernel uinput device. The kernel makes these events available to other applications on a /dev/input/event device, just as for regular input hardware.

lircd-uinput is designed to run as a systemd service.

The lircd output socket argument is an optional path to the lircd output socket. It defaults to the output value in the [lircd] section of the lirc_options config file, falling back to /var/run/lirc/lircd.

If a plain file is given instead of a socket it is supposed to contain button press events formatted as documented in lircd(8) . lircd-uinput will in this case send the codes in this file and exit.

In order to work, release events must be sent to the uinput device. See REPEAT HANDLING.

lircd-uinput can only handle button events named using the official namespace i. e., buttons known to the kernel. See NOTES.

Unless the /dev/uinput default permissions are changed lirc-uinput needs to run as root. See NOTES.

The /dev/input/event device created by the kernel can be tricky to locate, and is not stable. See NOTES.

## OPTIONS
-u --uinput <device>

uinput kernel device, defaults to /dev/uinput.

-r --release-suffix <suffix>

lircd-uinput generates different events depending on if the button name ends with the release-suffix or not. Defaults to _EVUP . See REPEAT HANDLING

-R --repeat <delay[,period] | ,period>

Set kernel autorepeat parameters of the created /dev/input/event device. delay is the time before repeating a key event, period is the time between repeated key events. Both values are in milliseconds, separated by a comma. Any value can be omitted or set to 0 in which case the kernel/system defaults are used. See REPEAT HANDLING.

-a --add-release-events

Generate synthetic release events. This option is mandatory unless lircd is using the deprecated --release option. The timeout used can be modified using the release-timeout key in the lircd-uinput section of the lirc_options.conf file. Useless if used with a text file as input. . See REPEAT HANDLING

-d --disabled <disabled buttons file path>

The path of a file which contains name of buttons to be disabled, one per line. By default, lircd-uinput sends all buttons found in input. See NOTES.

-O --options-file <path>

Options file holding default values. Defaults to /etc/lircd/lirc_options.conf

-L, --logfile <logfile path>

Select the log file, either the string 'syslog' indicating that syslog(1) should be used or a log file path. The default is to use syslog.

-D, --loglevel [level]

Determine the amount of logging information. level can be a symbolic syslog level: 'error','warning, 'info', 'notice' or ´debug'. lircd-uinput also defines three additional levels 'trace', 'trace1' and 'trace2' which gives even more messages ('trace2' bringing the most). However, in the log these messages are marked as 'debug'.

-h --help

Display usage summary.

-v --version

Display version info.

## REPEAT HANDLING
After receiving a keypress event the kernel will start emitting repeat events to applications until lircd-uinput emits a corresponding release event. The release events could be created by lircd(8) using the deprecated --release option. Such events typically has an _EVUP suffix appended to the original keypress event.

The preferred way is that lircd-uinput creates release events using the --add-release-events option. Combining both of these options might give unexpected results.

Note that the linux kernel uses the suffix _UP (which was used py lircd prior to 0.10.0) for other purposes since 4.7.

In any case, the repeat events generated by the kernel can be tweaked using the --repeat option. This can set the time between the keypress event and the first repeat event and the time between each repeat event. The --repeat option should only be used if no other program or udev rule is automatically setting up key repeat parameters. By design the repeat parameters can't be set in an atomic way during input device registration so this option is prone to race conditions.

Note that the lircd-uinput repeat-event handling differs from lircd(8) which implements (emulates) hardware autorepeat in the events sent to uinput (event.value == 2). lircd-uinput only sends keypress and release events, trusting the kernel autorepeat support.

## NOTES
By default, the dev/uinput device is not writable for regular users. Thus lircd-uinput needs to run as root unless these permissions are changed.

One way to achieve this is an udev rule. The lirc distribution contains an example rule which makes the lircd-uinput device writable for users in the group lirc. Another way is to use lircd-setup(8) to change the permissions. As distributed, the lirc_options.conf file contains an commented example using setfacl(1) .

lircd-uinput can only forward lircd button events with names from the legal namespace defined by the kernel. A complete list of possible button names is available in /usr/include/linux/input-event-codes.h and also using irrecord -l . Other button names are silently dropped.

The event keycode depends on the name that was given a button in the lircd config file e.g., if the button is named KEY_1 the keycode 1 will be generated.

The kernel makes the events generated by lircd-uinput available on a /dev/input device like /dev/input/event12. This device name is not stable and typically varies after a reboot. The lirc distribution contains a udev rule which if installed creates a device link named /dev/lircd-uinput which always can be used.

lircd-uinput is designed to replace the currently deprecated --uinput option to lircd(8). However, lircd-uinput forwards all events unless blocked by the --disabled option. On the other hand, lircd --uinput does not forward all events - the heuristics used has been changed over versions.

## BUGS
Since the device name is fixed, only one instance of lircd-uinput can run on a system.

## SEE ALSO
lircd(8)

irrecord(1)

http://www.kernel.org/doc/Documentation/input/event-codes.txt


lircmd

title: lircmd(8)

text:
# lircmd(8)

## NAME
lircmd - Translate infrared signals into mouse events.

## SYNOPSIS
lircmd [options] [config-file]

## DESCRIPTION
lircmd reads decoded buttonpress events from a lircd(8) output socket and converts them to mouse events. These events are made available either on the lircmd output socket (by default /var/run/lirc/lircmd ) or, using the --uinput option, on a /dev/input device like /dev/input/event12 .

This daemon can simulate a MouseSystems, IntelliMouse or IMPS/2 type mouse. The function depends on a configuration file, by default /etc/lirc/lircmd.conf . This file determines which button from which remote causes a mouse move or a mouse button click. Special button which activates or deactivates the mouse mode can also be defined.

The normal usage is to configure X11 to use the events produced by lircmd as an input source. See SEE ALSO.

Using the --uinput option the user device created by the kernel has a dynamic name which typically changes after a reboot. The lirc distribution contains a udev rule which, if installed, creates a fixed link named /dev/lircmd which always can be used.

By default, using the --uinput option requires lircmd to run as root since the /dev/uinput device can be accessed only by root. The lirc distribution contains example udev rules and lircd-setup(8) configurations which can be used to make the device accessible by other users. In this way, lircmd can be run as a regular user.

## OPTIONS
-h --help

Display help message.

-v --version

Display version.

-n --nodaemon

Don't fork to background.

-s --socket <socket path>

Use alternate lircd socket path (the lircmd input source). Defaults to the output key in the [lircd] section of the lirc_options.conf config file, falling back to /var/run/lirc/lircd.

-O --options-file=file

Alternative default options file, usually defaults to /etc/lirc/lirc_options.conf.

-u --uinput

On Linux systems the --uinput option will enable automatic generation of Linux input events. lircmd will open /dev/input/uinput and inject the simulated mouse events into the Linux kernel rather than creating the /dev/lircm device. The kernel makes these events available to other applications on a /dev/input device, just like any other kernel input device.

-D --loglevel=[level]

Determine the amount of logging information. [level] can be a symbolic syslog level: 'error','warning, 'info', 'notice' or 'debug'. lircd also defines three additional levels 'trace', 'trace1' and 'trace2' which gives even more messages ('trace2' bringing the most). However, in the log these messages are marked as 'debug'.

## SOCKET PROTOCOL
The socket protocol contains undocumented parts. The data on the output socket is

MouseSystems

5 byte packets:

- Byte 1: Button information.

- Byte 2: X-axis change.

- Byte 3: Y-axis change.

- Byte 4 and 5: 0.

IMPS/2

4 byte packets. Please refer to the lircmd source code for details.

IntelliMouse

4 byte packets. Please refer to the lircmd source code for details.

## FILES
lircmd will use syslogd to output error messages. It depends on your system configuration where they will show up.

The options file is by default /etc/lirc/lirc_options.conf; lircmd handles the values under the [lircmd] section in this file. The location can be changed using the -O/--options-file command-line option or using the environment variable LIRC_OPTIONS_PATH. The values here are used as defaults for any option not present on command line.

## DAEMONS
lircmd is a daemon. It should be started in some system-dependent init script. Besides the systemd setup which is installed by default there are also example scripts for other distros and init systems in the contrib directory. lircmd has to be started after lircd as it connects to the socket lircd provides.

## BUGS
Since the device name used when registrating the --uinput device is fixed, only one instance of lircmd using this option can run on a given system.

The socket protocol is a documentation-wise mess.

## SEE ALSO
http://lirc.org/html/configure.html#lircmd.conf

lircd(8)

lircd-setup(8)


lircrcd

title: lircrcd(8)

text:
# lircrcd(8)

## NAME
lircrcd - Synchronize lircrc state among client applications.

## SYNOPSIS
lircrcd [options] config-file

## DESCRIPTION
lircrcd reads the given .lircrc config file and synchronises the mode that the LIRC clients such as irexec(1), irxevent(1), etc., are in. Using lircrcd has to be explicitly enabled in the lircrc config file by adding the following line at the beginning of the file:

lircrc_class default

This must be done at the top-level file, not an included one. The lircrc_class string (here "default") could actually be anything; clients using the same string in their lircrc will be synchronized.

## OPTIONS
-h --help

Display help message.

-v --version

Display version.

-p, --permission=mode

The --permission option gives the file permission of the Unix domain socket lircrcd creates on startup in octal representation. Read the documentation for chmod for further details. If no --permission option is given when the socket is created the default is to give only the user owning the file read and write permissions (0600 in octal representation).

-o, --output=socket

With the --output option you can select the Unix domain socket, which lircrcd will create. The default is to create a socket in VARRUNDIR (/var/run/lirc), see FILES.

## SOCKET PROTOCOL
lircrcd syntactically uses the same protocol as lircd described in the lircd(8) manpage. It supports the following commands:

IDENT ident

Each program connecting to lircrcd identifies itself using this program. ident is the string that is used in the Prog = token inside the .lircrc file.

CODE code

When the client receives the code string from lircd it will send it to lircrcd and will receive back the applicable config string from the .lircrc config file. It should resend the CODE command until nothing is returned back which means that nothing (more) should happen in response to code. This command is used each time the lirc_code2char() function is called by a client.

GETMODE

lircrcd will return the current mode string.

SETMODE mode

lircrcd will set the actual mode, reflecting a mode in the .lircrc file.

## FILES
lircrcd creates its socket(s) in the VARRUNDIR directory (/var/run/lirc). The socket basename includes the user UID and the string from the lircrc_class option.

## SEE ALSO
The documentation for lirc is maintained as html pages. They are located under html/ in the documentation directory.


lizardfs-admin

package: lizardfs-adm

title: lizardfs-admin(8)

text:
# lizardfs-admin(8)

## NAME
lizardfs-admin, lizardfs-probe - LizardFS monitoring and administration tool

## SYNOPSIS
lizardfs-admin COMMAND [OPTIONS...] [ARGUMENTS...]

## AVAILABLE COMMANDS
chunks-health <master ip> <master port>

Returns chunks health reports in the installation. By default (if no report is specified) all reports will be shown. In replication and deletion states, the column means the number of chunks with number of copies specified in the label to replicate/delete. Possible command-line options:

--availability

Print report about availability of chunks.

--replication

Print report about about number of chunks that need replication.

--deletion

Print report about about number of chunks that need deletion.

info <master ip> <master port>

Prints statistics concerning the LizardFS installation.

iolimits-status <master ip> <master port>

Prints current configuration of global I/O limiting

list-chunkservers <master ip> <master port>

Prints information about all connected chunkservers.

list-disks <master ip> <master port>

Prints information about all connected chunkservers. Possible command-line options:

--verbose

Be a little more verbose and show operations statistics.

list-goals <master ip> <master port>

List goal definitions. Possible command-line options:

--pretty

Print nice table

list-mounts <master ip> <master port>

Prints information about all connected mounts. Possible command-line options

--verbose

Be a little more verbose and show goal and trash time limits.

metadataserver-status <master ip> <master port>

Prints status of a master or shadow master server

list-metadataservers <master ip> <master port>

Prints status of active metadata servers.

ready-chunkservers-count <master ip> <master port>

Prints number of chunkservers ready to be written to.

promote-shadow <shadow ip> <shadow port>

Promotes metadata server. Works only if personality ha-cluster-managed is used. Authentication with the admin password is required.

stop-master-without-saving-metadata <master ip> <master port>

Stop the master server without saving metadata in the metadata.mfs file. Used to quickly migrate a metadata server (works for all personalities). Authentication with the admin password is required.

reload-config <master ip> <master port>

Requests reloading configuration from the config file. This is synchronous (waits for reload to finish). Authentication with the admin password is required.

save-metadata <metadataserver ip> <metadataserver port>

Requests saving the current state of metadata into the metadata.mfs file. With --async fail if the process cannot be started, e.g. because the process is already in progress. Without --async, fails if either the process cannot be started or if it finishes with an error (i.e., no metadata file is created). Authentication with the admin password is required. Possible command-line options:

--async

Don’t wait for the task to finish.

## COMMON COMMAND OPTIONS
--porcelain

Make the output parsing-friendly.

## COPYRIGHT
Copyright 2013-2019 Skytechnology sp. z o.o.

LizardFS is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, version 3.

LizardFS is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

You should have received a copy of the GNU General Public License along with LizardFS. If not, see http://www.gnu.org/licenses/.


lizardfs-cgiserver

package: lizardfs-cgiserv

title: lizardfs-cgiserver(8)

text:
# lizardfs-cgiserver(8)

## NAME
lizardfs-cgiserver - simple HTTP/CGI server for Lizard File System monitoring

## SYNOPSIS

```
lizardfs-cgiserver [-H BIND-HOST] [-P BIND-PORT] [-R ROOT-PATH] [-v]
```

```
lizardfs-cgiserver -h
```

## DESCRIPTION
lizardfs-cgiserver is a very simple HTTP server capable of running CGI scripts for Lizard File System monitoring. It just runs in foreground and works until killed with e.g. SIGINT or SIGTERM.

## OPTIONS
-h

print usage information and exit

-H BIND_HOST

local address to listen on (default: any)

-P BIND_PORT

port to listen on (default: 9425)

-R ROOT_PATH

local path to use as HTTP document root (default is CGIDIR set up at configure time)

-v

log requests on stderr

## COPYRIGHT
Copyright 2008-2009 Gemius SA, 2013-2019 Skytechnology sp. z o.o.

LizardFS is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, version 3.

LizardFS is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

You should have received a copy of the GNU General Public License along with LizardFS. If not, see http://www.gnu.org/licenses/.

## SEE ALSO
moosefs(7)


mfscgiserv

title: mfscgiserv(8)

text:
# mfscgiserv(8)

## NAME
mfscgiserv - start HTTP/CGI server for Lizard File System monitoring

## SYNOPSIS

```
mfscgiserv [-H BIND-HOST] [-P BIND-PORT] [-R ROOT-PATH]

             [-D DATA-PATH] [-t LOCKTIMEOUT] [-f [-v]] [ACTION]
```

```
mfscgiserv -h
```

## DESCRIPTION

```
######################## ! DEPRECATION WARNING ! #########################
#                                                                        #
# mfscgiserv service is deprecated, please use lizardfs-cgiserv instead. #
# See manual entry lizardfs-cgiserver(8) for details.                    #
#                                                                        #
######################## ! DEPRECATION WARNING ! #########################
```

mfscgiserv is a very simple HTTP server capable of running CGI scripts for Lizard File System monitoring.

## OPTIONS
-h

print usage information and exit

-H BIND_HOST

local address to listen on (default: any)

-P BIND_PORT

port to listen on (default: 9425)

-R ROOT_PATH

local path to use as HTTP document root (default is CGIDIR set up at configure time)

-D DATA_PATH

local path to store data, e.g. a lockfile (default is DATA_PATH set up at configure time)

-f

run in foreground, don’t daemonize

-v

log requests on stderr

-t LOCKTIMEOUT

how long to wait for lockfile (default is 60 seconds)

ACTION is the one of start, stop, restart or test. Default action is restart.

## COPYRIGHT
Copyright 2008-2009 Gemius SA, 2013-2019 Skytechnology sp. z o.o.

LizardFS is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, version 3.

LizardFS is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

You should have received a copy of the GNU General Public License along with LizardFS. If not, see http://www.gnu.org/licenses/.

## SEE ALSO
moosefs(7)


mfschunkserver

package: lizardfs-chunkserver

title: mfschunkserver(8)

text:
# mfschunkserver(8)

## NAME
mfschunkserver - start, restart or stop Lizard File System chunkserver process

## SYNOPSIS

```
mfschunkserver [-f] [-c CFGFILE] [-u] [-d] [-t LOCKTIMEOUT] [ACTION]
```

```
mfschunkserver -s [-c CFGFILE]
```

```
mfschunkserver -v
```

```
mfschunkserver -h
```

## DESCRIPTION
mfschunkserver is the data server of Lizard File System. Depending on parameters it can start, restart or stop LizardFS chunkserver process. Without any options it starts LizardFS chunkserver, killing previously run process if lock file exists.

SIGHUP (or reload ACTION) forces mfschunkserver to reload all configuration files.

Chunkserver periodically tests stored chunks (see HDD_TEST_FREQ option in mfschunkserver.cfg manual).

LizardFS master doesn’t send metadata change logs to chunkserver and expect at least one mfsmetalogger daemon to connect.

Chunkserver scans attached disks in background.

## OPTIONS
-v

print version information and exit

-h

print usage information and exit

-f

(deprecated, use start action instead) forcily run LizardFS chunkserver process, without trying to kill previous instance (this option allows to run LizardFS chunkserver if stale PID file exists)

-s

(deprecated, use stop action instead) stop LizardFS chunkserver process

-c CFGFILE

specify alternative path of configuration file (default is mfschunkserver.cfg in system configuration directory)

-u

log undefined configuration values (when default is assumed)

-d

run in foreground, don’t daemonize

-t LOCKTIMEOUT

how long to wait for lockfile (default is 60 seconds)

ACTION is the one of start, stop, restart, reload, test, isalive or kill. Default action is restart.

## FILES
mfschunkserver.cfg

configuration file for LizardFS chunkserver process; refer to mfschunkserver.cfg(5) manual for defails

mfshdd.cfg

list of directories (mountpoints) used for LizardFS storage (one per line; directory prefixed by * character causes given directory to be freed by replicating all data already stored there to another locations)

mfschunkserver.lock

PID file of running LizardFS chunkserver process

.mfschunkserver.lock

lock file of running LizardFS chunkserver process (created in data directory)

data.csstats

Chunkserver charts state

## REPORTING BUGS
Report bugs to <contact@lizardfs.org>.

## COPYRIGHT
Copyright 2008-2009 Gemius SA, 2013-2019 Skytechnology sp. z o.o.

LizardFS is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, version 3.

LizardFS is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

You should have received a copy of the GNU General Public License along with LizardFS. If not, see http://www.gnu.org/licenses/.

## SEE ALSO
mfsmaster(8), mfsmount(1), mfschunkserver.cfg(5), mfshdd.cfg(5), moosefs(7)


mfsmaster

package: lizardfs-master

title: mfsmaster(8)

text:
# mfsmaster(8)

## NAME
mfsmaster - start, restart or stop Lizard File System metadata server process

## SYNOPSIS

```
mfsmaster [-f] [-c CFGFILE] [-u] [-d] [-t LOCKTIMEOUT] [ACTION]
```

```
mfsmaster -s [-c CFGFILE]
```

```
mfsmaster -v
```

```
mfsmaster -h
```

## DESCRIPTION
mfsmaster is the metadata server program of Lizard File System. Depending on parameters it can start, restart or stop LizardFS metadata server process. Without any options it starts LizardFS metadata server, killing previously run process if lock file exists.

Metadata server can work in one of two modes (personalities):

1.master

2.shadow

If metadata server works with master personality it acts as main metadata server govering all file system metadata modifications. If metadata server works with shadow personality it acts as backup metadata server ready for immediate deployment as new master in case of current master failure. Shadow only accepts connections from lizardfs-admin, i.e. mfschunkserver, mfsmetalogger and mfsmount (the client) are not allowed to connect to shadow instance.

Current metadata server personality is defined in metadata server configuration file and can be changed on the fly from shadow to master by proper modification and reloading of its configuration file.

Master and shadow are designed to run simultaneously in sync forever. It is very unlikely but still (due to a memory corruption or a bug) possible that after some time their metadata will somehow differ. Since version 2.5.2 metadata checksum is maintained both by master and shadow, in order to detect and fix possible metadata corruptions. In case mismatch is detected shadow asks master to double check its metadata and dump its current snapshot. After the metadata is dumped and the checksum in master is recalculated shadow downloads the new metadata snapshot, which should ensure that master and all shadows have exactly the same metadata.

SIGHUP (or reload ACTION) forces mfsmaster to reload all configuration files.

-v

print version information and exit

-h

print usage information and exit

-f

(deprecated, use start action instead) forcily run LizardFS master process, without trying to kill previous instance (this option allows to run LizardFS master if stale PID file exists)

-s

(deprecated, use stop action instead) stop LizardFS master process

-c CFGFILE

specify alternative path of configuration file (default is mfsmaster.cfg in system configuration directory)

-u

log undefined configuration values (when default is assumed)

-d

run in foreground, don’t daemonize

-t LOCKTIMEOUT

how long to wait for lockfile (default is 60 seconds)

ACTION

is the one of start, stop, restart, reload, test, isalive or kill. Default action is restart.

## FILES
mfsmaster.cfg

configuration file for LizardFS master process (see mfsmaster.cfg(5) manual)

mfsexports.cfg

LizardFS access control file (used with mfsmounts 1.6.0 or later, see mfsexports.cfg(5) manual)

mfstopology.cfg

Network topology definitions (see mfstopology.cfg(5) manual)

mfsmaster.lock

PID file of running LizardFS master process

.mfsmaster.lock

lock file of running LizardFS master process (created in data directory)

metadata.mfs, metadata.mfs.back

LizardFS filesystem metadata image

changelog.*.mfs

LizardFS filesystem metadata change logs (merged into metadata.mfs once per hour)

data.stats

LizardFS master charts state

## REPORTING BUGS
Report bugs to <contact@lizardfs.org>.

## COPYRIGHT
Copyright 2008-2009 Gemius SA, 2013-2019 Skytechnology sp. z o.o.

LizardFS is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, version 3.

LizardFS is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

You should have received a copy of the GNU General Public License along with LizardFS. If not, see http://www.gnu.org/licenses/.

## SEE ALSO
mfsmetarestore(8), mfschunkserver(8), mfsmount(1), mfsmaster.cfg(5), mfsexports.cfg(5), mfstopology.cfg(5), moosefs(7)


mfsmetadump

title: mfsmetadump(8)

text:
# mfsmetadump(8)

## NAME
mfsmetadump - a networking, distributed, highly available file system

## SYNOPSIS

```
mfsmetadump metadata_file...
```

## DESCRIPTION
mfsmetadump dumps file system metadata into specified file.

## COPYRIGHT
Copyright 2019 Skytechnology sp. z o.o.

LizardFS is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, version 3.

LizardFS is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

You should have received a copy of the GNU General Public License along with LizardFS. If not, see http://www.gnu.org/licenses/.

## SEE ALSO
mfstools(1)


mfsmetarestore

title: mfsmetarestore(8)

text:
# mfsmetarestore(8)

## NAME
mfsmetarestore - replay LizardFS metadata change logs or dump LizardFS metadata image

## SYNOPSIS

```
mfsmetarestore [-z] -m OLDMETADATAFILE -o NEWMETADATAFILE [CHANGELOGFILE...]
```

```
mfsmetarestore -m METADATAFILE
```

```
mfsmetarestore [-z] -a [-d DIRECTORY]
```

```
mfsmetarestore -g -d DIRECTORY
```

```
mfsmetarestore -v
```

```
mfsmetarestore -?
```

## DESCRIPTION
When mfsmetarestore is called with both -m and -o options, it replays given CHANGELOGFILEs on OLDMETADATAFILE and writes result to NEWMETADATAFILE. Multiple change log files can be given.

mfsmetarestore with just -m METADATAFILE option dumps LizardFS metadata image file in human readable form.

mfsmetarestore called with -a option automatically performs all operations needed to merge change log files. Master data directory can be specified using -d DIRECTORY option.

mfsmetarestore -g with path to metadata files, prints latest metadata version that can be restored from disk. Prints 0 if metadata files are corrupted.

-v

print version information and exit

-?

print version information and exit

-a

autorestore mode (see above)

-d DATAPATH

master data directory (for autorestore mode)

-m METADATAFILE

specify input metadata image file

-o NEWMETADATAFILE

specify output metadata image file

-z

ignore metadata checksum inconsistency while applying changelogs

## FILES
metadata.mfs

Lizard File System metadata image as read by mfsmaster process

metadata.mfs.back

Lizard File System metadata image as left by killed or crashed mfsmaster process

changelog.*.mfs

Lizard File System metadata change logs

## REPORTING BUGS
Report bugs to <contact@lizardfs.org>.

## COPYRIGHT
Copyright 2008-2009 Gemius SA, 2013-2019 Skytechnology sp. z o.o.

LizardFS is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, version 3.

LizardFS is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

You should have received a copy of the GNU General Public License along with LizardFS. If not, see http://www.gnu.org/licenses/.

## SEE ALSO
mfsrestoremaster(8), mfsmaster(8), moosefs(7)


mfsrestoremaster

title: mfsrestoremaster(8)

text:
# mfsrestoremaster(8)

## NAME
mfsrestoremaster - scripts automating starting master server on a metalogger machine.

## SYNOPSIS

```
mfsrestoremaster <net-interface> [<etc-lfs-dir>]
```

<net-interface>

Network interface to reconfigure.

<etc-lfs-dir>

LizardFS configuration directory to use (default: /etc/lizardfs).

## DESCRIPTION
This scripts performs the following steps:

•verify basic sanity of configuration files,

•update metadata image with data from metalogger changelogs,

•set master’s IP address on given network interface,

•start the master server.

## NOTES
mfsrestoremaster makes use of mfsmetarestore.

## COPYRIGHT
Copyright 2008-2009 Gemius SA, 2013-2019 Skytechnology sp. z o.o.

LizardFS is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, version 3.

LizardFS is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

You should have received a copy of the GNU General Public License along with LizardFS. If not, see http://www.gnu.org/licenses/.

## SEE ALSO
mfsmetarestore(8), mfstools(1)


mfsmetalogger

package: lizardfs-metalogger

title: mfsmetalogger(8)

text:
# mfsmetalogger(8)

## NAME
mfsmetalogger - start, restart or stop Lizard File System metalogger process

## SYNOPSIS

```
mfsmetalogger [-f] [-c CFGFILE] [-u] [-d] [-t LOCKTIMEOUT] [ACTION]
```

```
mfsmetalogger -s [-c CFGFILE]
```

```
mfsmetalogger -v
```

```
mfsmetalogger -h
```

## DESCRIPTION
mfsmetalogger is the metadata replication server of Lizard File System. Depending on parameters it can start, restart or stop LizardFS metalogger process. Without any options it starts LizardFS metalogger, killing previously run process if lock file exists.

SIGHUP (or reload ACTION) forces mfsmetalogger to reload all configuration files.

-v

print version information and exit

-h

print usage information and exit

-c CFGFILE

specify alternative path of configuration file (default is mfsmetalogger.cfg in system configuration directory)

-u

log undefined configuration values (when default is assumed)

-d

run in foreground, don’t daemonize

-t LOCKTIMEOUT

how long to wait for lockfile (default is 60 seconds)

ACTION is the one of start, stop, restart, reload, test, isalive or kill. Default action is restart.

## FILES
mfsmetalogger.cfg

configuration file for LizardFS metalogger process; refer to mfsmetalogger.cfg(5) manual for defails

mfsmetalogger.lock

PID file of running LizardFS metalogger process

.mfsmetalogger.lock

lock file of running LizardFS metalogger process (created in data directory)

changelog_ml.*.mfs

LizardFS filesystem metadata change logs (backup of master change log files)

metadata.ml.mfs.back

Latest copy of complete metadata.mfs.back file from LizardFS master.

sessions.ml.mfs

Latest copy of sessions.mfs file from LizardFS master.

## REPORTING BUGS
Report bugs to <contact@lizardfs.org>.

## COPYRIGHT
Copyright 2008-2009 Gemius SA, 2013-2019 Skytechnology sp. z o.o.

LizardFS is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, version 3.

LizardFS is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

You should have received a copy of the GNU General Public License along with LizardFS. If not, see http://www.gnu.org/licenses/.

## SEE ALSO
mfsmaster(8), mfsmetalogger.cfg(5), moosefs(7)


lizardfs-uraft

package: lizardfs-uraft

title: lizardfs-uraft(8)

text:
# lizardfs-uraft(8)

## NAME
lizardfs-uraft - LizardFS high availability cluster management tool

## SYNOPSIS

```
lizardfs-uraft [--help]
```

```
lizardfs-uraft [-c CFGFILE]
```

## DESCRIPTION
lizardfs-uraft is a high availability management daemon. It can provide master server failover mechanisms based on floating ip.

lizardfs-uraft internal algorithms are based on Raft (raft.github.io). Functions used to manage (promote/demote/check/kill/etc) nodes are called through lizardfs-uraft-helper, a script that implements uraft API for a specific backend (in this case, LizardFS). See lizardfs-uraft-helper(8) man entry for details.

For more configuration info and examples, refer to lizardfs-uraft.cfg file and lizardfs-uraft.cfg(5) man entry.

## OPTIONS
--help

print usage information and exit

--config CFGFILE

provide an alternative configuration file path.

## COPYRIGHT
Copyright 2018-2019 Skytechnology sp. z o.o.

LizardFS is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, version 3.

LizardFS is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

You should have received a copy of the GNU General Public License along with LizardFS. If not, see http://www.gnu.org/licenses/.

## SEE ALSO
lizardfs-uraft-helper(8), lizardfs-uraft.cfg(5)


lizardfs-uraft-helper

title: lizardfs-uraft-helper(8)

summary: LizardFS HA suite helper

text:
# lizardfs-uraft-helper(8)

## NAME
lizardfs-uraft-helper - LizardFS HA suite helper

## SYNOPSIS

```
lizardfs-uraft-helper
```

## DESCRIPTION
lizardfs-uraft-helper is a helper script, used internally by lizardfs-uraft to manage nodes. The script should implement the following operations: isalive metadata-version quick-stop promote demote assign-ip drop-ip

Except from isalive, this script should not be used on its own. If anyone needs special actions to be taken during lizardfs-uraft management stages (such as promotion, demotion), editing this script is sufficient to do so.

## COPYRIGHT
Copyright 2018-2019 Skytechnology sp. z o.o.

LizardFS is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, version 3.

LizardFS is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

You should have received a copy of the GNU General Public License along with LizardFS. If not, see http://www.gnu.org/licenses/.

## SEE ALSO
lizardfs-uraft(8), lizardfs-uraft.cfg(5)


dcbtool

package: lldpad

title: dcbtool(8)

text:
# dcbtool(8)

## NAME
dcbtool - manage the Data Center Bridging (DCB) settings of a CEE DCB interface

## SYNOPSIS
dcbtool -h

dcbtool -v

dcbtool [-rR]

dcbtool [-rR] [command] [command arguments]

## DESCRIPTION
dcbtool is used to query and set the DCB settings of a Converged Enhanced Ethernet (CEE) DCB capable Ethernet interface. It connects to the client interface of lldpad to perform these operations. dcbtool will operate in interactive mode if it is executed without a command. In interactive mode, dcbtool also functions as an event listener and will print out events received from lldpad as they arrive. It will use libreadline for interactive input when available. 802.1Qaz DCBX is not controllable from dcbtool instead lldptool can be used in this case.

## OPTIONS
-h

show the dcbtool usage message

-v

shows dcbtool version information

-r

display the raw lldpad client interface messages as well as the readable output.

-R

display only the raw lldpad client interface messages

## COMMANDS
help

shows the dcbtool usage message

ping

test command. lldpad responds with "PPONG" if the client interface is operational.

license

displays dcbtool license information

quit

exit from interactive mode

The following commands interact with lldpad to manage the daemon and DCB features on DCB capable interfaces.

dcbtool general configuration commands:

<gc|go> dcbx

Get the configured or operational legacy version of the DCBX protocol which will be supported by lldpad. The configured version, if different from the operational version, will take effect after lldpad is restarted.

sc dcbx v:[cin|cee|force-cin|force-cee]

Set the legacy version of DCBX which will be supported by lldpad the next time it is started.

Information about the CIN version can be found at:

<http://download.intel.com/technology/eedc/dcb_cep_spec.pdf>

Information about the CEE version can be found at:

<http://www.ieee802.org/1/files/public/docs2008/az-wadekar-dcbx-capability-exchange-discovery-protocol-1108-v1.01.pdf>

The dcbx setting is a global setting and changes only take effect when lldpad is restarted. The default DCBX version used is the IEEE standard version. If a pre-IEEE DCBX version is received (per port) which matches the dcbx setting, then lldpad will fall back to the configured global dcbx setting. If the dcbx setting is set to either 'force-cin' or 'force-cee' then any port doing DCBX will start out in the corresponding legacy DCBX mode.

DCB per-interface commands:

gc <ifname> <feature>

get configuration of feature on interface ifname.

go <ifname> <feature>

get operational status of feature on interface ifname.

gp <ifname> <feature>

get peer configuration of feature on interface ifname.

sc <ifname> <feature> <args>

set the configuration of feature on interface ifname.

feature may be one of the following:

dcb

DCB state of the port

pg

priority groups

pfc

priority flow control

app:<subtype>

application specific data

ll:<subtype>

logical link status

subtype can be:

0|fcoe

Fiber Channel over Ethernet (FCoE)

1|iscsi

Internet Small Computer System Interface (iSCSI)

2|fip

FCoE Initialization Protocol (FIP)

args can include:

e:<0|1>

controls feature enable

a:<0|1>

controls whether the feature is advertised via DCBX to the peer

w:<0|1>

controls whether the feature is willing to change its operational configuration based on what is received from the peer

[feature specific args]

arguments specific to a DCB feature

Feature specific arguments for dcb:

on|off

enable or disable DCB for the interface. The go and gp commands are not needed for the dcb feature. Also, the enable(e), advertise(a) and willing(w) arguments are not required.

Feature specific arguments for pg:

pgid:xxxxxxxx

Priority group ID for the 8 priorities. From left to right (priorities 0-7), x is the corresponding priority group ID value, which can be 0-7 for priority groups with bandwidth allocations or f (priority group ID 15) for the unrestricted priority group.

pgpct:x,x,x,x,x,x,x,x

Priority group percentage of link bandwidth. From left to right (priority groups 0-7), x is the percentage of link bandwidth allocated to the corresponding priority group. The total bandwidth must equal 100%.

uppct:x,x,x,x,x,x,x,x

Priority percentage of priority group bandwidth. From left to right (priorities 0-7), x is the percentage of priority group bandwidth allocated to the corresponding priority. The sum of percentages for priorities which belong to the same priority group must total 100% (except for priority group 15).

strict:xxxxxxxx

Strict priority setting. From left to right (priorities 0-7), x is 0 or 1. 1 indicates that the priority may utilize all of the bandwidth allocated to its priority group.

up2tc:xxxxxxxx

Priority to traffic class mapping. From left to right (priorities 0-7), x is the traffic class (0-7) to which the priority is mapped.

Feature specific arguments for pfc:

pfcup:xxxxxxxx

Enable/disable priority flow control. From left to right (priorities 0-7), x is 0 or 1. 1 indicates that the corresponding priority is configured to transmit priority pause.

Feature specific arguments for app:<subtype>:

The app features uses global enable and willing bits for all subtypes. To remove or add subtypes to the TLV set the advertise bit.

appcfg:xx

xx is a hexadecimal value representing an 8 bit bitmap where 1 bits indicate the priorities which frames for the applications specified by subtype should use. The lowest order bit maps to priority 0.

Feature specific arguments for ll:<subtype>:

status:[0|1]

For testing purposes, the logical link status may be set to 0 or 1. Changes to the logical link status are not saved in the configuration file.

## EXAMPLES
Enable DCB on interface eth2

dcbtool sc eth2 dcb on

Assign priorities 0-3 to priority group 0, priorities 4-6 to priority group 1 and priority 7 to the unrestricted priority. Also, allocate 25% of link bandwidth to priority group 0 and 75% to group 1.

dcbtool sc eth2 pg pgid:0000111f pgpct:25,75,0,0,0,0,0,0

Enable transmit of Priority Flow Control for priority 3 and assign FCoE to priority 3.

dcbtool sc eth2 pfc pfcup:00010000

dcbtool sc eth2 app:0 appcfg:08

## SEE ALSO
lldpad(8), lldptool(8), lldptool-dcbx(8), lldptool-ets(8), lldptool-pfc(8), lldptool-app(8)

## COPYRIGHT
dcbtool - DCB configuration utility

Copyright(c) 2007-2012 Intel Corporation. Portions of dcbtool are based on:

hostapd-0.5.7

Copyright

(c) 2004-2008, Jouni Malinen <j@w1.fi>

## LICENSE
This program is free software; you can redistribute it and/or modify it under the terms and conditions of the GNU General Public License, version 2, as published by the Free Software Foundation.

This program is distributed in the hope it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 51 Franklin St - Fifth Floor, Boston, MA 02110-1301 USA.

The full GNU General Public License is included in this distribution in the file called "COPYING".

## SUPPORT
Contact Information: open-lldp Mailing List <lldp-devel@open-lldp.org>


lldpad

title: lldpad(8)

text:
# lldpad(8)

## NAME
lldpad - Link Layer Discovery Protocol (LLDP) agent daemon

## SYNOPSIS
lldpad [-h] [-v] [-V level] [-d] [-k] [-p] [-s] [-t] [-f filename]

## DESCRIPTION
Executes the LLDP protocol for supported network interfaces. The list of TLVs currently supported are:

-

IEEE 802.1AB Mandatory TLVs

-

IEEE 802.1AB Basic Management TLVs

-

IEEE 802.3 Organizationally Specific TLVs

-

LLDP-MED Organizationally Specific TLVs

-

Data Center Bridging capabilities exchange protocol (DCBX) TLVs

-

Edge Virtual Bridging (EVB) TLVs

Capabilities of lldpad include:

-

Transmission of LLDP PDUs containing enabled TLVs from enabled ports.

-

Reception of LLDP PDUs from enabled ports.

-

Operation of the DCBX protocol for interfaces which support the DCB rtnetlink interface. This includes operation of the DCBX state machines above LLDP and corresponding configuration of the DCB parameters of the network interface. Supported DCB features are: Extended Transmission Selection, Priority Flow Control and the FCoE application.

-

Configuring the DCB settings of the network driver based on the operation of DCBX.

-

Provides a multi-channel interface for client applications to query and configure features. Events are also generated on the client interface to inform clients of changes. The lldpad package includes two clients: lldptool for general LLDP agent management and dcbtool for DCB management.

lldpad supports the versions of the DCB capabilities exchange (DCBX) protocol listed as follows:

version 1 - also known as CIN DCBX

<http://download.intel.com/technology/eedc/dcb_cep_spec.pdf>

version 2 - also known as CEE DCBX

<http://www.ieee802.org/1/files/public/docs2008/az-wadekar-dcbx-capability-exchange-discovery-protocol-1108-v1.01.pdf>

IEEE DCBX

See the IEEE 802.1Qaz-2011 specification for details.

IEEE DCBX is the default DCBX mode for a DCB capable interface so the default and configured IEEE DCBX TLVs will be transmitted when the interface comes up. lldpad can be globally configured to support one of the legacy DCBX versions (CIN or CEE). If the remote LLDP agent does not transmit any IEEE DCBX TLVs and does transmit a legacy DCBX TLV which matches the configured legacy DCBX version, then the DCBX mode will drop back to legacy DCBX mode. It will not transition back to IEEE DCBX mode until the next link reset. If lldpad has dropped back to legacy DCBX mode for a given interface and the daemon is stopped and restarted, the legacy DCBX mode for that interface will be used instead of starting out in IEEE DCBX mode. This behavior only applies to the case where lldpad is restarted and is not persistent across a system reboot.

See dcbtool for information on how to globally configure which legacy version of DCBX lldpad executes.

See lldptool for information on how to reset the DCBX mode of an interface back to default (starts out in IEEE DCBX mode).

lldpad also supports edge virtual bridging as currently under specification in the IEEE 802.1Qb working group. <http://www.ieee802.org/1/pages/802.1bg.html>

## OPTIONS
lldpad has the following command line options:

-h

show usage information

-f filename

use the specified file as the configuration file instead of the default file: /var/lib/lldpad/lldpad.conf lldpad expects the directory of the configuration file to exist, but if the configuration file does not exist, then a default configuration file will be created. lldpad creates and maintains the contents of the configuration file. Configuration should be performed by using lldptool or dcbtool.

-d

run lldpad as a daemon

-v

show lldpad version

-V level

set lldpad debugging level. Uses syslog debug levels see syslog.2 for details.

-k

used to terminate the first instance of lldpad that was started (e.g. from initrd). Once lldpad -k has been invoked and lldpad has been restarted, subsequent invocations of lldpad -k will not terminate lldpad.

-s

remove lldpad state records from shared memory

-p

do not create PID file /var/run/lldpad.pid on startup

-t

omit timestamps from logging messages

## NOTE
On termination, lldpad does not undo any of the configurations that it has set. This approach minimizes the risk of restarting the daemon to perform a software update, or of having storage issues during shutdown. Ongoing operation of network interfaces that had been controlled by lldpad may result in unexpected behavior.

## SEE ALSO
dcbtool(8), lldptool(8), lldptool-dcbx(8), lldptool-ets(8), lldptool-pfc(8), lldptool-app(8), lldptool-med(8), lldptool-vdp(8), lldptool-evb(8)

## COPYRIGHT
lldpad - LLDP agent daemon with DCBX support

Copyright(c) 2007-2012 Intel Corporation. Portions of lldpad are based on:

hostapd-0.5.7

Copyright

(c) 2004-2008, Jouni Malinen <j@w1.fi>

## LICENSE
This program is free software; you can redistribute it and/or modify it under the terms and conditions of the GNU General Public License, version 2, as published by the Free Software Foundation.

This program is distributed in the hope it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 51 Franklin St - Fifth Floor, Boston, MA 02110-1301 USA.

The full GNU General Public License is included in this distribution in the file called "COPYING".

## SUPPORT
Contact Information: open-lldp Mailing List <lldp-devel@open-lldp.org>


lldptool

title: lldptool(8)

text:
# lldptool(8)

## NAME
lldptool - manage the LLDP settings and status of lldpad

## SYNOPSIS
lldptool <command> [options] [argument]

## DESCRIPTION
lldptool is used to query and configure lldpad. It connects to the client interface of lldpad to perform these operations. lldptool will operate in interactive mode if it is executed without a command. In interactive mode, lldptool will also function as an event listener to print out events as they are received asynchronously from lldpad. It will use libreadline for interactive input when available.

## OPTIONS
-i [ifname]

specifies the network interface to which the command applies. Most lldptool commands require specifying a network interface.

-V [tlvid]

specifies the TLV identifier

The tlvid is an integer value used to identify specific LLDP TLVs. The tlvid value is the Type value for types not equal to 127 (the organizationally specific type). For organizationally specific TLVs, the tlvid is the value represented by the 3 byte OUI and 1 byte subtype - where the subtype is the lowest order byte of the tlvid.

The tlvid can be entered as a numerical value (e.g. 10 or 0xa), or for supported TLVs, as a keyword. Review the lldptool help output to see the list of supported TLV keywords.

-n

"neighbor" option for commands which can use it (e.g. get-tlv)

-g [bridge scope]

specify the bridge scope this command operates on. Allows to set and query all LLDP TLV modules for "nearest_bridge" (short: "nb"), "nearest_customer_bridge" ("ncb") and "nearest_nontpmr_bridge" ("nntpmrb") group mac addresses. Configurations are saved into independent sections in lldpad.conf. If no bridge scope is supplied this defaults to "nearest bridge" to preserve the previous behaviour.

-c <argument list>

"config" option for TLV queries. Indicates that the query is for the configuration elements for the specified TLV. The argument list specifies the specific elements to query. If no arguments are listed, then all configuration elements for the TLV are returned.

-r

show raw client interface messages

-R

show only raw Client interface messages

## COMMANDS
license

show license information

-h, help

show usage information

-v, version

show version information

-S, stats

get LLDP statistics for the specified interface

-t, get-tlv

get TLV information for the specified interface

-T, set-tlv

set TLV information for the specified interface

-l, get-lldp

get LLDP parameters for the specified interface

-L, set-lldp

set LLDP parameters for the specified interface

-p, ping

display the process identifier of the running lldpad process

-q, quit

exit from interactive mode

## ARGUMENTS
This section lists arguments which are available for administration of LLDP parameters. Arguments for basic TLV's (non-organizationally specific TLVs) are also described. See the SEE ALSO section for references to other lldptool man pages which contain usage details and arguments for various organizationally specific TLVs.

adminStatus

Argument for the get-lldp/set-lldp commands. Configures the LLDP adminStatus parameter for the specified interface. Valid values are: disabled, rx, tx, rxtx

enableTx

Argument for the get-tlv/set-tlv commands. May be applied per interface for a specified TLV. Valid values are: yes, no. If the DCBX TLV enableTx is set to no, then all of the DCB feature TLVs DCBX advertise settings will be turned off as well. Setting enableTx to yes will enable the DCBX advertise settings.

ipv4

Argument for the get-tlv/set-tlv commands with respect to the Management Address TLV. The get command will retrieve the configured value. Set values take the form of an IPv4 address: A.B.C.D

ipv6

Argument for the get-tlv/set-tlv commands with respect to the Management Address TLV. The get command will retrieve the configured value. Set values take the form of an IPv6 address: 1111:2222:3333:4444:5555:6666:7777:8888 and various shorthand variations.

## EXAMPLES
Configure LLDP adminStatus to Receive and Transmit for interface eth2

lldptool -L -i eth2 adminStatus=rxtx

lldptool set-lldp -i eth2 adminStatus=rxtx

Query the LLDP adminStatus for interface eth3

lldptool -l -i eth3 adminStatus

lldptool get-lldp -i eth3 adminStatus

Query the LLDP statistics for interface eth3

lldptool -S -i eth3

lldptool stats -i eth3

Query the local TLVs which are being transmitted for a given interface:

lldptool -t -i eth3

lldptool get-tlv -i eth3

Query the received neighbor TLVs received on a given interface:

lldptool -t -n -i eth3

lldptool get-tlv -n -i eth3

Query the value of the System Description TLV as received from the neighbor on a given interface:

lldptool -t -n -i eth3 -V sysDesc

lldptool get-tlv -n -i eth3 -V 6

Disable transmit of the IEEE 802.3 MAC/PHY Configuration Status TLV for a given interface:

lldptool -T -i eth3 -V macPhyCfg enableTx=no

lldptool set-tlv -i eth3 -V 0x120f01 enableTx=no

Query value of the transmit setting for the Port Description TLV for a given interface:

lldptool -t -i eth3 -V portDesc -c enableTx

lldptool get-tlv -i eth3 -V 4 -c enableTx

Set a Management Address TLV on eth3 to carry IPv4 address 192.168.10.10

lldptool -T -i eth3 -V mngAddr ipv4=192.168.10.10

Set a Management Address TLV on eth3 to carry IPv6 address ::192.168.10.10

lldptool -T -i eth3 -V mngAddr ipv6=::192.168.10.10

Get the configured IPv4 address for the Management Address TLV on eth3

lldptool -t -i eth3 -V mngAddr -c ipv4

Get all configured attributes for the Management Address TLV on eth3

lldptool -t -i eth3 -V mngAddr -c

Enable transmit of the Edge Virtual Bridging TLV for interface eth4

lldptool -i eth4 -T -g ncb -V evbCfg enableTx=yes

Enable transmit of VDP for interface eth4

lldptool -i eth4 -T -V vdp enableTx=yes

Display process identifier of lldpad

lldptool -p

## SEE ALSO
lldptool-dcbx(8), lldptool-ets(8), lldptool-pfc(8), lldptool-app(8), lldptool-med(8), lldptool-vdp(8), lldptool-evb(8), lldptool-evb22(8), dcbtool(8), lldpad(8)

## COPYRIGHT
lldptool - LLDP agent configuration utility

Copyright(c) 2007-2012 Intel Corporation. Portions of lldptool are based on:

hostapd-0.5.7

Copyright

(c) 2004-2008, Jouni Malinen <j@w1.fi>

## LICENSE
This program is free software; you can redistribute it and/or modify it under the terms and conditions of the GNU General Public License, version 2, as published by the Free Software Foundation.

This program is distributed in the hope it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 51 Franklin St - Fifth Floor, Boston, MA 02110-1301 USA.

The full GNU General Public License is included in this distribution in the file called "COPYING".

## SUPPORT
Contact Information: open-lldp Mailing List <lldp-devel@open-lldp.org>


lldptool-app

title: lldptool-app(8)

summary: Show / manipulate APP TLV configuration

text:
# lldptool-app(8)

## NAME
APP - Show / manipulate APP TLV configuration

## SYNOPSIS
lldptool -t -i ethx -V APP [-c app]

lldptool -T -i ethx -V APP [-d] app=prio,sel,pid

## DESCRIPTION
The APP TLV is an informational TLV and will advertise the current configured application table. If the peer APP TLV and a local APP TLV match the same selector and protocol field the local parameter is used.

## ARGUMENTS
app

Configures a local application data field using the three parameters: priority (prio), selector (sel), and protocol (pid). The -d option can be provided to remove an entry which matches the three parameters.

## Theory of Operations
The APP TLV is an informational TLV for most end stations. It is not expected that setting APP data should be required. Peer data will be processed and added to the application data table by default assuming there does not already exist a local entry with matching selector and priority fields.

By adding APP data to the application table it is available for applications, eg iscsid, to query. Applications query for a specific protocol and selector and may use this data to map traffic to the corresponding traffic class.

## EXAMPLE & USAGE
Configure ISCSI application for priority 4 on eth2

lldptool -T -i eth2 -V APP app=4,2,3260

Configure FCoE application for priority 3 on eth2

lldptool -T -i eth2 -V APP app=3,1,35078

Remove FCoE application for priority 3 on eth2

lldptool -T -i eth2 -V APP -d app=3,1,35078

Display locally configured application table on eth2

lldptool -t -i eth2 -V APP -c app

Display last transmitted APP TLV on eth2

lldptool -t -i eth2 -V APP

## SOURCE
o

IEEE 802.1Qaz (http://www.ieee802.org/1/pages/dcbridges.html)

## SEE ALSO
lldptool(8), lldpad(8)

## AUTHOR
John Fastabend


lldptool-dcbx

title: lldptool-dcbx(8)

summary: Show / manipulate DCBX configuration

text:
# lldptool-dcbx(8)

## NAME
DCBX - Show / manipulate DCBX configuration

## SYNOPSIS
lldptool -t -i ethx -V IEEE-DCBX -c [mode]

lldptool -T -i ethx -V IEEE-DCBX mode=reset

lldptool -t -i ethx -V <CIN-DCBX|CEE-DCBX> -c [enableTx]

lldptool -T -i ethx -V <CIN-DCBX|CEE-DCBX> enableTx=<yes|no>

## DESCRIPTION - DCBX MODE
lldpad supports the following versions of the DCB capabilities exchange (DCBX) protocol:

CIN DCBX

<http://download.intel.com/technology/eedc/dcb_cep_spec.pdf>

CEE DCBX

<http://www.ieee802.org/1/files/public/docs2008/az-wadekar-dcbx-capability-exchange-discovery-protocol-1108-v1.01.pdf>

IEEE DCBX

See the IEEE 802.1Qaz-2011 specification for details."

IEEE DCBX is the default DCBX mode for a DCB capable interface. Therefore the default and configured IEEE DCBX TLVs will be transmitted when the interface comes up. lldpad can be globally configured to support one of the legacy DCBX versions (CIN or CEE). If the remote LLDP agent does not transmit any IEEE DCBX TLVs and does transmit a legacy DCBX TLV which matches the configured legacy DCBX version, then the DCBX mode will drop back to legacy DCBX mode. It will not transition back to IEEE DCBX mode until the next link reset. If lldpad has dropped back to legacy DCBX mode for a given interface and the daemon is stopped and restarted, the legacy DCBX mode for that interface will be used instead of starting out in IEEE DCBX mode. This behavior only applies to the case where lldpad is restarted and is not persistent across a system reboot.

The DCBX mode can be queried and configured by using the special tlvid IEEE-DCBX. There is not an actual TLV which corresponds to this tlvid. Its use is to query and reset the IEEE DCBX mode. When queried, IEEE DCBX mode can take the following values:

auto - IEEE DCBX will be used (initially) if lldpad is restarted. An exception is if the DCBX mode has been forced to a legacy DCBX mode, then the specified legacy mode will be used. See information about the 'dcbx' parameter in dcbtool(8) for more information about this exception."

CEE - CEE DCBX will be used if lldpad is restarted

CIN - CIN DCBX will be used if lldpad is restarted

The IEEE DCBX mode can be reset to auto by setting the mode argument to the value reset

## DESCRIPTION - DCBX CONFIGURATION
The detailed configuration of the IEEE DCBX TLVs can be found in related lldptool man pages for each IEEE DCBX TLV (see lldptool-pfc(8), lldptool-ets(8) and lldptool-app(8)).

The detailed configuration of the CIN and CEE DCBX TLVs is performed using dcbtool (see dcbtool(8)). However, lldptool can configure the enableTx parameter of the CIN and CEE DCBX TLVs (as it can with most other TLVs). Since lldpad only transmits TLVs for one version of DCBX on any given interface, the enableTx parameter for the CIN and CEE DCBX TLVs (and for the IEEE DCBX feature TLVs) takes effect only when the corresponding DCBX version is active.

## ARGUMENTS
mode=reset

Reset the DCBX mode that will be used if lldpad is restarted by setting the mode argument to reset using the special tlvid IEEE-DCBX.

enableTx

Enable the specified DCBX TLV (CIN-DCBX or CEE-DCBX) to be transmitted in the LLDPDU if that DCBX mode for the specified interface has been selected.

## EXAMPLE & USAGE
Query the current DCBX mode that will be used if lldpad is restarted. (this is not a persistent setting)

lldptool -t -i eth3 -V IEEE-DCBX -c mode

Reset the DCBX mode to be 'auto' (start in IEEE DCBX mode) after the next lldpad restart

lldptool -T -i eth3 -V IEEE-DCBX mode=reset

Enable transmission of the CEE DCBX TLV

lldptool -T -i eth3 -V CEE-DCBX enableTx=yes

Disable transmission of the CIN DCBX TLV

lldptool -T -i eth3 -V CIN-DCBX enableTx=no

Query the configuration of enableTx for the CEE DCBX TLV

lldptool -t -i eth3 -V CEE-DCBX -c enableTx

## SEE ALSO
dcbtool(8), lldptool(8), lldptool-ets(8), lldptool-pfc(8), lldptool-app(8), lldpad(8)

## AUTHOR
Eric Multanen


lldptool-ets

title: lldptool-ets(8)

summary: Show / manipulate ETS TLV configuration

text:
# lldptool-ets(8)

## NAME
ETS-{CFG|REC} - Show / manipulate ETS TLV configuration

## SYNOPSIS
lldptool -t -i ethx -V ETS-CFG <-c CONFIG_ARG ...>

CONFIG_ARG := { enableTx | willing | tsa | up2tc | numtcs | tcbw }

lldptool -T -i ethx -V ETS-CFG CONFIG_ARG=value ...

CONFIG_ARG :=

enableTx = {yes|no} |

willing = {yes|no} |

tsa = tc:{ets|strict|vendor},... |

up2tc = priority:tc,... |

tcbw = bw1,bw2,...

lldptool -t -i ethx -V ETS-REC <-c CONFIG_ARG ...>

lldptool -T -i ethx -V ETS-REC CONFIG_ARG=value ...

CONFIG_ARG :=

enableTx = {yes|no} |

tsa = tc:{ets|strict|vendor},... |

up2tc = priority:tc,... |

tcbw = bw1,bw2,...

## DESCRIPTION
The Enhanced Transmission Selection (ETS) feature has a recommendation TLV and a configuration TLV configured with ETS-REC and ETS-CFG respectively.

## ARGUMENTS
enableTx

Enables the ETS TLV to be transmitted

willing

Sets the ETS-CFG willing bit

tsa

Transmission selection algorithm, sets a comma separated list of traffic classes to the corresponding selection algorithm. Valid algorithms include "ets", "strict" and "vendor".

up2tc

Comma separated list mapping user priorities to traffic classes.

tcbw

Comma separated list of bandwidths for each traffic class the first value being assigned to traffic class 0 and the second to traffic class 1 and so on. Undefined bandwidths are presumed to be 0.

numtcs

Displays the number of ETS supported traffic classes.

## Theory of Operations
IEEE 802.1Qaz is enabled by default on hardware that supports this mode indicated by support for the DCBNL interface. Kernel config option CONFIG_DCB. The ETS-CFG TLV is advertised by default with the attributes indicated by querying the hardware for its current configuration. A valid configuration is to map all priorities to a single traffic class and use the link strict selection algorithm. This is equivalent to being in a non-DCB enabled mode.

To support legacy DCBX (CIN or CEE) the ETS-CFG and ETS-REC TLVs are disabled if a legacy DCBX TLV is received and no valid IEEE DCBX TLVs are received. The hardware DCBX mode will also be set to the legacy mode and IEEE mode is disabled. This allows switches to be configured and end nodes will then be configured accordingly without any configuration required on the end node. See lldpad(8) for more information about the operation of the DCBX selection mechanism.

Mapping applications and protocols to traffic classes is required for ETS to be useful. User space programs can encode the priority of an application with the SO_PRIORITY option. The net_prio cgroup can be used to assign application traffic to specific priorities. See the kernel documentation and cgdcbxd(8) for net_prio cgroup information.

## EXAMPLE & USAGE
Configure willing bit for interface eth2

lldptool -T -i eth2 -V ETS-CFG willing=yes

Configure traffic classes for ETS and strict priority on eth2

lldptool -T -i eth2 -V ETS-CFG tsa=0:ets,1:ets,2:ets,3:ets,4:strict,5:strict

Configure 1:1 mapping from priority to traffic classes on eth2

lldptool -T -i eth2 -V ETS-CFG up2tc=0:0,1:1,2:2,3:3,4:4,5:5,6:6,7:7

Display local configured ETS-CFG parameters for tcbw

lldptool -t -i eth2 -V ETS-CFG -c tcbw

Display last transmitted ETS-CFG TLV

lldptool -t -i eth2 -V ETS-CFG

Configure ETS-CFG and ETS-REC for default DCB on eth2

lldptool -T -i eth2 -V ETS-CFG tsa=0:ets,1:ets,2:ets,3:ets,4:ets,5:ets,6:ets,7:ets up2tc=0:0,1:1,2:2,3:3,4:4,5:5,6:6,7:7 tcbw=12,12,12,12,13,13,13,13 lldptool -T -i eth2 -V ETS-REC tsa=0:ets,1:ets,2:ets,3:ets,4:ets,5:ets,6:ets,7:ets up2tc=0:0,1:1,2:2,3:3,4:4,5:5,6:6,7:7 tcbw=12,12,12,12,13,13,13,13

## SOURCE
o

IEEE 802.1Qaz (http://www.ieee802.org/1/pages/dcbridges.html)

## NOTES
Support for tc-mqprio was added in 2.6.38 on older kernels other mechanisms may need to be used to map applications to traffic classes.

## SEE ALSO
lldptool(8), lldptool-app(8), lldpad(8), tc-mqprio(8),

## AUTHOR
John Fastabend


lldptool-evb

title: lldptool-evb(8)

summary: Show / manipulate EVB TLV configuration

text:
# lldptool-evb(8)

## NAME
evb - Show / manipulate EVB TLV configuration

## SYNOPSIS
lldptool -t -g ncb -i ethx -V evbCfg -c enableTx

lldptool -T -g ncb -i ethx -V evbCfg -c enableTx=[yes|no]

lldptool -t -g ncb -i ethx -V evbCfg -c fmode

lldptool -T -g ncb -i ethx -V evbCfg -c fmode=[bridge|reflectiverelay]

lldptool -t -g ncb -i ethx -V evbCfg -c capabilities

lldptool -T -g ncb -i ethx -V evbCfg -c capabilities=[rte|ecp|vdp|none]

lldptool -t -g ncb -i ethx -V evbCfg -c rte

lldptool -T -g ncb -i ethx -V evbCfg -c rte=[<rte>]

lldptool -t -g ncb -i ethx -V evbCfg -c vsis

lldptool -T -g ncb -i ethx -V evbCfg -c vsis=[<number of vsis>]

## DESCRIPTION
The EVB TLV is a TLV to announce the station and bridge's edge virtual bridging (evb) capabilities and request the bridge forwarding mode. If both sides have agree on edge control protocol (ECP), VSI discovery protocol (VDP) capabilities, both sides can exchange VDP TLV using ECP frames. The vsis parameter will set the maximum number of VSIs and show the number of currently configured VSIs.

## ARGUMENTS
enableTx

Enables the EVB TLV to be transmitted

fmode

shows or sets the forwarding mode between bridge (default) or reflectiverelay (RR).

capabilities

shows or sets the local capabilities that are announced to the adjacent switch in the TLV. This parameter will accept any combination of rte, vdp or ecp, separated by ",". Use the keyword "none" if you do not want to set any capabilities.

rte

shows or set the local run time exponent (RTE). The RTE will be used as the base for the timing of the ECP and VDP protocols.

vsis

shows or sets the number of virtual station interfaces (VSIs) that are announced to the adjacent switch in the TLV. This parameter expects a number between 0 and 65535.

## Theory of Operation
The EVB TLV is used to announce and exchange supported parameters between the station and an adjacent switch. The TLV uses the nearest customer bridge agent.

If "reflectiverelay" is set as forwarding mode, the switch will allow "reflection" of frames coming from different sources at the same port back to the port. This will allow communication between virtual machines on the same host via the switch.

The capabilities parameter is used to set RTE, ECP and VDP support. VDP TLVs in ECP frames can only be exchanged if both sides agree on ECP and VDP as capabilities. RTE will be used as the base timing parameter for ECP and VDP.

## EXAMPLE & USAGE
Display locally configured values for eth8

lldptool -t -g ncb -i eth8 -V evbCfg

Display remotely configured values for eth8

lldptool -n -g ncb -t -i eth8 -V evbCfg

Display wether evb tlv is configured for tx on eth8

lldptool -t -g ncb -i eth8 -V evbCfg -c enableTx

Display the currently requested forwarding mode for eth8

lldptool -t -g ncb -i eth8 -V evbCfg -c fmode

Set the forwarding mode to reflective relay

lldptool -T -g ncb -i eth8 -V evbCfg -c fmode=reflectiverelay

Display the currently configured capabilities

lldptool -t -g ncb -i ethx -V evbCfg -c capabilities

Set the locally possible capabilities to RTE, ECP and VDP

lldptool -T -g ncb -i ethx -V evbCfg -c capabilities=rte,ecp,vdp

Resets the locally possible capabilities to "none"

lldptool -T -g ncb -i ethx -V evbCfg -c capabilities=none

Display the locally configured value for RTE

lldptool -t -g ncb -i ethx -V evbCfg -c rte

Set the value for RTE

lldptool -T -g ncb -i ethx -V evbCfg -c rte=[<rte>]

Display the configured maximum number of VSIs

lldptool -t -g ncb -i ethx -V evbCfg -c vsis

Set the maximum number of VSIs

lldptool -T -g ncb -i ethx -V evbCfg -c vsis=[<number of vsis>]

## SOURCE
o

IEEE 802.1Qbg (http://www.ieee802.org/1/pages/802.1bg.html)

## NOTES
Currently the code in lldpad reflects draft 0 of the upcoming standard. EVB TLVs on the wire can be decoded with wireshark > v1.6.

## SEE ALSO
lldptool-vdp(8), lldptool(8), lldpad(8)

## AUTHOR
Jens Osterkamp