This restores show_pid_array() output in legacy locales on the console.
Only one call to get_process_cmdline() is changed, all others retain
utf8-only mode. This affects systemd-cgls, systemctl status, etc, when
working locally.
Calls to get_process_cmdline() that cross a process boundary always use
utf8. It's the callers responsibility to convert this to some encoding that
they use. This means that we always pass utf8 over the bus.
It turns out that the kernel allows comm names higher than our expected limit
of 16.
$ wc -c /proc/*/comm|sort -g|tail -n3
35 /proc/1292317/comm
35 /proc/1293610/comm
36 /proc/1287112/comm
$ cat /proc/1287112/comm
kworker/u9:3-kcryptd/253:0
The functions to retrieve and print process cmdlines were based on the
assumption that they contain printable ASCII, and everything else
should be filtered out. That assumption doesn't hold in today's world,
where people are free to use unicode everywhere.
This replaces the custom cmdline reading code with a more generic approach
using utf8_escape_non_printable_full().
For kernel threads, truncation is done on the parenthesized name, so we'll
get "[worker]", "[worker…]", …, "[w…]", "[…", "…" as we reduce the number of
available columns.
This implementation is most likely slower for very long cmdlines, but I don't
think this is very important. The common case is to have short commandlines,
and should print those properly. Absurdly long cmdlines are the exception,
which needs to be handled correctly and safely, but speed is not too important.
Fixes#12532.
v2:
- use size_t for the number of columns. This change propagates into various
other functions that call get_process_cmdline(), increasing the size of the
patch, but the changes are rather trivial.
The length of device identification VPD page is filled with two bytes,
but scsi_id only gets the low byte. Fix it.
Signed-off-by: Zhang Xianwei <zhang.xianwei8@zte.com.cn>
Now the MTU is not displayed. with this patch it's fixed.
(networkctl)⚡ % ./networkctl status enp0s31f6 ~/tt/networkctl/build
WARNING: systemd-networkd is not running, output will be incomplete.
● 4: enp0s31f6
Link File: /usr/lib/systemd/network/99-default.link
Network File: n/a
Type: ether
State: n/a (unmanaged)
Path: pci-0000:00:1f.6
Driver: e1000e
Vendor: Intel Corporation
Model: Ethernet Connection (2) I219-LM
HW Address: 8c:16:45:6c:83:b9 (LCFC(HeFei) Electronics Technology co., ltd)
MTU: 1500
When build from release tarball and where there is parent .git dir,
this situtaion will get wrong version info. (build with buildroot)
The systemd running show wrong version in dmesg log:
systemd[1]: systemd 2019.02-1086-gf5f17c4 running in system mode.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Shoule be:
systemd[1]: systemd 241 running in system mode. (-PAM -AUDIT -SEL
^^^^^^^^^^^
To access a shell on a disk image, the man page on Fedora-29 says to
run: `systemd-nspawn -M Fedora-Cloud-Base-28-1.1.x86_64.raw`. Let's
try.
List existing images:
$> machinectl list-images | awk '{print $1,$2}';
NAME TYPE
Fedora-Cloud-Base-30… raw
1 images
Now invoke `systemd-nspawn` as noted in the man page:
$> systemd-nspawn -M Fedora-Cloud-Base-30-1.2.x86_64.raw
No image for machine 'Fedora-Cloud-Base-30-1.2.x86_64.raw'.
Removing the ".raw" extension launches the image and gives a shell.
Update the man page to reflect that.
Frantisek Sumsal on #systemd (Freenode) noted the reason: "In older
versions systemd -M accepted both image-name.raw and image-name as a
valid image names, however, on Fedora 29 (systemd-239) with all the
BTRFS stuff around it accepts only -M image-name (without the
extension)"
- - -
While at it, update the fedora_{latest_version, cloud_release}
variables.
Signed-off-by: Kashyap Chamarthy <kchamart@redhat.com>
