211 lines
7.7 KiB
Plaintext
211 lines
7.7 KiB
Plaintext
|
|
started by Ingo Molnar <mingo@redhat.com>, 2001.09.17
|
|
2.6 port and netpoll api by Matt Mackall <mpm@selenic.com>, Sep 9 2003
|
|
IPv6 support by Cong Wang <xiyou.wangcong@gmail.com>, Jan 1 2013
|
|
Extended console support by Tejun Heo <tj@kernel.org>, May 1 2015
|
|
|
|
Please send bug reports to Matt Mackall <mpm@selenic.com>
|
|
Satyam Sharma <satyam.sharma@gmail.com>, and Cong Wang <xiyou.wangcong@gmail.com>
|
|
|
|
Introduction:
|
|
=============
|
|
|
|
This module logs kernel printk messages over UDP allowing debugging of
|
|
problem where disk logging fails and serial consoles are impractical.
|
|
|
|
It can be used either built-in or as a module. As a built-in,
|
|
netconsole initializes immediately after NIC cards and will bring up
|
|
the specified interface as soon as possible. While this doesn't allow
|
|
capture of early kernel panics, it does capture most of the boot
|
|
process.
|
|
|
|
Sender and receiver configuration:
|
|
==================================
|
|
|
|
It takes a string configuration parameter "netconsole" in the
|
|
following format:
|
|
|
|
netconsole=[+][src-port]@[src-ip]/[<dev>],[tgt-port]@<tgt-ip>/[tgt-macaddr]
|
|
|
|
where
|
|
+ if present, enable extended console support
|
|
src-port source for UDP packets (defaults to 6665)
|
|
src-ip source IP to use (interface address)
|
|
dev network interface (eth0)
|
|
tgt-port port for logging agent (6666)
|
|
tgt-ip IP address for logging agent
|
|
tgt-macaddr ethernet MAC address for logging agent (broadcast)
|
|
|
|
Examples:
|
|
|
|
linux netconsole=4444@10.0.0.1/eth1,9353@10.0.0.2/12:34:56:78:9a:bc
|
|
|
|
or
|
|
|
|
insmod netconsole netconsole=@/,@10.0.0.2/
|
|
|
|
or using IPv6
|
|
|
|
insmod netconsole netconsole=@/,@fd00:1:2:3::1/
|
|
|
|
It also supports logging to multiple remote agents by specifying
|
|
parameters for the multiple agents separated by semicolons and the
|
|
complete string enclosed in "quotes", thusly:
|
|
|
|
modprobe netconsole netconsole="@/,@10.0.0.2/;@/eth1,6892@10.0.0.3/"
|
|
|
|
Built-in netconsole starts immediately after the TCP stack is
|
|
initialized and attempts to bring up the supplied dev at the supplied
|
|
address.
|
|
|
|
The remote host has several options to receive the kernel messages,
|
|
for example:
|
|
|
|
1) syslogd
|
|
|
|
2) netcat
|
|
|
|
On distributions using a BSD-based netcat version (e.g. Fedora,
|
|
openSUSE and Ubuntu) the listening port must be specified without
|
|
the -p switch:
|
|
|
|
'nc -u -l -p <port>' / 'nc -u -l <port>' or
|
|
'netcat -u -l -p <port>' / 'netcat -u -l <port>'
|
|
|
|
3) socat
|
|
|
|
'socat udp-recv:<port> -'
|
|
|
|
Dynamic reconfiguration:
|
|
========================
|
|
|
|
Dynamic reconfigurability is a useful addition to netconsole that enables
|
|
remote logging targets to be dynamically added, removed, or have their
|
|
parameters reconfigured at runtime from a configfs-based userspace interface.
|
|
[ Note that the parameters of netconsole targets that were specified/created
|
|
from the boot/module option are not exposed via this interface, and hence
|
|
cannot be modified dynamically. ]
|
|
|
|
To include this feature, select CONFIG_NETCONSOLE_DYNAMIC when building the
|
|
netconsole module (or kernel, if netconsole is built-in).
|
|
|
|
Some examples follow (where configfs is mounted at the /sys/kernel/config
|
|
mountpoint).
|
|
|
|
To add a remote logging target (target names can be arbitrary):
|
|
|
|
cd /sys/kernel/config/netconsole/
|
|
mkdir target1
|
|
|
|
Note that newly created targets have default parameter values (as mentioned
|
|
above) and are disabled by default -- they must first be enabled by writing
|
|
"1" to the "enabled" attribute (usually after setting parameters accordingly)
|
|
as described below.
|
|
|
|
To remove a target:
|
|
|
|
rmdir /sys/kernel/config/netconsole/othertarget/
|
|
|
|
The interface exposes these parameters of a netconsole target to userspace:
|
|
|
|
enabled Is this target currently enabled? (read-write)
|
|
extended Extended mode enabled (read-write)
|
|
dev_name Local network interface name (read-write)
|
|
local_port Source UDP port to use (read-write)
|
|
remote_port Remote agent's UDP port (read-write)
|
|
local_ip Source IP address to use (read-write)
|
|
remote_ip Remote agent's IP address (read-write)
|
|
local_mac Local interface's MAC address (read-only)
|
|
remote_mac Remote agent's MAC address (read-write)
|
|
|
|
The "enabled" attribute is also used to control whether the parameters of
|
|
a target can be updated or not -- you can modify the parameters of only
|
|
disabled targets (i.e. if "enabled" is 0).
|
|
|
|
To update a target's parameters:
|
|
|
|
cat enabled # check if enabled is 1
|
|
echo 0 > enabled # disable the target (if required)
|
|
echo eth2 > dev_name # set local interface
|
|
echo 10.0.0.4 > remote_ip # update some parameter
|
|
echo cb:a9:87:65:43:21 > remote_mac # update more parameters
|
|
echo 1 > enabled # enable target again
|
|
|
|
You can also update the local interface dynamically. This is especially
|
|
useful if you want to use interfaces that have newly come up (and may not
|
|
have existed when netconsole was loaded / initialized).
|
|
|
|
Extended console:
|
|
=================
|
|
|
|
If '+' is prefixed to the configuration line or "extended" config file
|
|
is set to 1, extended console support is enabled. An example boot
|
|
param follows.
|
|
|
|
linux netconsole=+4444@10.0.0.1/eth1,9353@10.0.0.2/12:34:56:78:9a:bc
|
|
|
|
Log messages are transmitted with extended metadata header in the
|
|
following format which is the same as /dev/kmsg.
|
|
|
|
<level>,<sequnum>,<timestamp>,<contflag>;<message text>
|
|
|
|
Non printable characters in <message text> are escaped using "\xff"
|
|
notation. If the message contains optional dictionary, verbatim
|
|
newline is used as the delimeter.
|
|
|
|
If a message doesn't fit in certain number of bytes (currently 1000),
|
|
the message is split into multiple fragments by netconsole. These
|
|
fragments are transmitted with "ncfrag" header field added.
|
|
|
|
ncfrag=<byte-offset>/<total-bytes>
|
|
|
|
For example, assuming a lot smaller chunk size, a message "the first
|
|
chunk, the 2nd chunk." may be split as follows.
|
|
|
|
6,416,1758426,-,ncfrag=0/31;the first chunk,
|
|
6,416,1758426,-,ncfrag=16/31; the 2nd chunk.
|
|
|
|
Miscellaneous notes:
|
|
====================
|
|
|
|
WARNING: the default target ethernet setting uses the broadcast
|
|
ethernet address to send packets, which can cause increased load on
|
|
other systems on the same ethernet segment.
|
|
|
|
TIP: some LAN switches may be configured to suppress ethernet broadcasts
|
|
so it is advised to explicitly specify the remote agents' MAC addresses
|
|
from the config parameters passed to netconsole.
|
|
|
|
TIP: to find out the MAC address of, say, 10.0.0.2, you may try using:
|
|
|
|
ping -c 1 10.0.0.2 ; /sbin/arp -n | grep 10.0.0.2
|
|
|
|
TIP: in case the remote logging agent is on a separate LAN subnet than
|
|
the sender, it is suggested to try specifying the MAC address of the
|
|
default gateway (you may use /sbin/route -n to find it out) as the
|
|
remote MAC address instead.
|
|
|
|
NOTE: the network device (eth1 in the above case) can run any kind
|
|
of other network traffic, netconsole is not intrusive. Netconsole
|
|
might cause slight delays in other traffic if the volume of kernel
|
|
messages is high, but should have no other impact.
|
|
|
|
NOTE: if you find that the remote logging agent is not receiving or
|
|
printing all messages from the sender, it is likely that you have set
|
|
the "console_loglevel" parameter (on the sender) to only send high
|
|
priority messages to the console. You can change this at runtime using:
|
|
|
|
dmesg -n 8
|
|
|
|
or by specifying "debug" on the kernel command line at boot, to send
|
|
all kernel messages to the console. A specific value for this parameter
|
|
can also be set using the "loglevel" kernel boot option. See the
|
|
dmesg(8) man page and Documentation/admin-guide/kernel-parameters.rst for details.
|
|
|
|
Netconsole was designed to be as instantaneous as possible, to
|
|
enable the logging of even the most critical kernel bugs. It works
|
|
from IRQ contexts as well, and does not enable interrupts while
|
|
sending packets. Due to these unique needs, configuration cannot
|
|
be more automatic, and some fundamental limitations will remain:
|
|
only IP networks, UDP packets and ethernet devices are supported.
|