# Collect OpenBSD kernel log messages

The `openbsd()` source driver collects kernel log messages on OpenBSD systems. The driver reads messages from the `/dev/klog` kernel log device using the `LIOCSFD` ioctl, which is the OpenBSD-native mechanism that the system’s default `syslogd` use. Messages collected through this source are tagged with the `local+openbsd` transport.

On OpenBSD platforms the [`system()` source](../../docs/axosyslog-core/chapter-sources/source-system/index.md) automatically uses `openbsd()` to read kernel messages, so usually you don’t need to configure it directly. Use `openbsd()` explicitly only if you want to bypass `system()` and route OpenBSD kernel messages through a custom log path.

## Example: Reading OpenBSD kernel logs
```
    source s_openbsd_kernel {
        openbsd();
    };
    
    log {
        source(s_openbsd_kernel);
        destination { file("/var/log/kernel.log"); };
    };
    
```

## Options

The `openbsd()` source supports a minimal set of options. It doesn’t accept message-format or socket-tuning options because the kernel log device delivers locally framed messages with no hostname or transport metadata to negotiate.

## hook-commands()

_Description:_ This option makes it possible to execute external programs when the relevant driver is initialized or torn down. The `hook-commands()` can be used with all source and destination drivers with the exception of the `usertty()` and `internal()` drivers.

Note The AxoSyslog application must be able to start and restart the external program, and have the necessary permissions to do so. For example, if your host is running AppArmor or SELinux, you might have to modify your AppArmor or SELinux configuration to enable AxoSyslog to execute external applications. 

### Using `hook-commands()` when AxoSyslog starts or stops

To execute an external program when AxoSyslog starts or stops, use the following options:

#### `startup()`

Type: | string  
---|---  
Default: | N/A  
  
_Description:_ Defines the external program that is executed as AxoSyslog starts.

#### `shutdown()`

Type: | string  
---|---  
Default: | N/A  
  
_Description:_ Defines the external program that is executed as AxoSyslog stops.

### Using the hook-commands() when AxoSyslog reloads

To execute an external program when the AxoSyslog configuration is initiated or torn down, for example, on startup/shutdown or during a AxoSyslog reload, use the following options:

#### `setup()`

Type: | string  
---|---  
Default: | N/A  
  
_Description:_ Defines an external program that is executed when the AxoSyslog configuration is initiated, for example, on startup or during a AxoSyslog reload.

#### `teardown()`

Type: | string  
---|---  
Default: | N/A  
  
_Description:_ Defines an external program that is executed when the AxoSyslog configuration is stopped or torn down, for example, on shutdown or during a AxoSyslog reload.

### Example: Using hook-commands() with a network source

In the following example, the `hook-commands()` is used with the `network()` driver and it opens an [iptables](<https://en.wikipedia.org/wiki/Iptables> "https://en.wikipedia.org/wiki/Iptables") port automatically as AxoSyslog is started/stopped.

The assumption in this example is that the `LOGCHAIN` chain is part of a larger ruleset that routes traffic to it. Whenever the AxoSyslog created rule is there, packets can flow, otherwise the port is closed.
```
 
    source {
        network(transport(udp)
        hook-commands(
              startup("iptables -I LOGCHAIN 1 -p udp --dport 514 -j ACCEPT")
              shutdown("iptables -D LOGCHAIN 1")
            )
         );
    };
    
```

## internal()

|   
---|---  
Accepted values: | `yes`, `no`  
Default: | `no`  
  
_Description:_ Marks this pipeline element as internal. Elements marked as `internal()` are treated as an implementation detail, so for example statistics of the given pipe are available only on higher stats level. This option is mainly useful for developers or when writing SCL blocks and integrations.

## persist-name()

|   
---|---  
Type: | string  
Default: | N/A  
  
_Description:_ If you receive the following error message during AxoSyslog startup, set the `persist-name()` option of the duplicate drivers:
```
 
    Error checking the uniqueness of the persist names, please override it with persist-name option. Shutting down.
    
```

This error happens if you use identical drivers in multiple sources, for example, if you configure two file sources to read from the same file. In this case, set the `persist-name()` of the drivers to a custom string, for example, `persist-name("example-persist-name1")`.

Last modified May 14, 2026: [Update snippet filename (98071744)](<https://github.com/axoflow/axosyslog-core-docs/commit/98071744a0bd69d7983de613162b7b8f969dd55d>)