LXC /dev/urandom -> write error: Broken pipe

[tony blue]

Hallo,

auf meinem unpriviligierten LXC Container erigbt ein

LC_ALL=C </dev/urandom tr -dc A-Za-z0-9 | head -c 28

die Rückmeldung

eu1NUQt5tqKZvA8esm9EBPg3d8pztr: write error: Broken pipe
tr: write error

Auf einer KVM-Instanz ergibt sich diese Fehlermeldung nicht.

Wie kann ich das hinbekommen?


Hintergrund: Ich möchte auf einem LXC-Container mailcow installieren. Hierfür gibt es ein Script, das die config-Dateien erstellt. Dieses beinhaltet die obige Zeile. Im Mailcow-Forum habe ich schon angefragt. Hier habe ich die Rückmeldung erhalten, dass es an LXC liegen muss, da es auf einer KVM-Instanz geht: https://community.mailcow.email/d/97-generate-configsh-tr-write-error-broken-pipe/3

Vielen Dank!


Tony

P. S.

lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 18.04.4 LTS
Release: 18.04
Codename: bionic

uname -a
Linux firstmail 5.3.18-3-pve #1 SMP PVE 5.3.18-3 (Tue, 17 Mar 2020 16:33:19 +0100) x86_64 ×86_64 ×86_64 GNU/Linux

 

[fiona]

Hallo,
kann es hier nicht reproduzieren (auf einem frisch installierten ubuntu-18.04-standard_18.04.1-1_amd64.tar.gz-Template):

root@CT110:~#  LC_ALL=C </dev/urandom tr -dc A-Za-z0-9 | head -c 28
QfgcZlLwaV52w5oecZNPQ3pJ6P0Yroot@CT110:~#
root@CT110:~# uname -a
Linux CT110 5.3.18-3-pve #1 SMP PVE 5.3.18-3 (Tue, 17 Mar 2020 16:33:19 +0100) x86_64 x86_64 x86_64 GNU/Linux

Wie schaut die Konfiguration von dem Container aus (/etc/pve/nodes/<NODE>/lxc/<ID>.conf)? Was ist die Ausgabe von pveversion -v?


EDIT: Mit einem alpine-3.11-default_20200425_amd64.tar.xz-Container bekomme ich allerdings auch den "Broken pipe"-Fehler.

 

[tony blue]

Hallo Fabian_E,

vielen Dank für die Rückmeldung.

cat /etc/pve/nodes/virtualhost/lxc/3213.conf

arch: amd64
cores: 2
features: keyctl=1,nesting=1
hostname: firstmail
memory: 4096
net0: name=eth0,bridge=vmbr3,gw=192.168.2.254,hwaddr=86:EE:10:AC:0F:4D,ip=192.168.2.210/24,type=veth
ostype: ubuntu
rootfs: local-zfs:subvol-3213-disk-0,size=30G
swap: 1024
unprivileged: 1

pveversion -v
proxmox-ve: 6.1-2 (running kernel: 5.3.18-3-pve)
pve-manager: 6.1-11 (running version: 6.1-11/f2f18736)
pve-kernel-helper: 6.1-9
pve-kernel-5.3: 6.1-6
pve-kernel-5.0: 6.0-11
pve-kernel-4.15: 5.4-6
pve-kernel-5.3.18-3-pve: 5.3.18-3
pve-kernel-5.3.18-2-pve: 5.3.18-2
pve-kernel-5.0.21-5-pve: 5.0.21-10
pve-kernel-4.15.18-18-pve: 4.15.18-44
pve-kernel-4.15.17-1-pve: 4.15.17-9
ceph-fuse: 12.2.11+dfsg1-2.1+b1
corosync: 3.0.3-pve1
criu: 3.11-3
glusterfs-client: 5.5-3
ifupdown: 0.8.35+pve1
ksm-control-daemon: 1.3-1
libjs-extjs: 6.0.1-10
libknet1: 1.15-pve1
libproxmox-acme-perl: 1.0.2
libpve-access-control: 6.0-7
libpve-apiclient-perl: 3.0-3
libpve-common-perl: 6.1-1
libpve-guest-common-perl: 3.0-10
libpve-http-server-perl: 3.0-5
libpve-storage-perl: 6.1-7
libqb0: 1.0.5-1
libspice-server1: 0.14.2-4~pve6+1
lvm2: 2.03.02-pve4
lxc-pve: 4.0.2-1
lxcfs: 4.0.3-pve2
novnc-pve: 1.1.0-1
proxmox-mini-journalreader: 1.1-1
proxmox-widget-toolkit: 2.1-6
pve-cluster: 6.1-8
pve-container: 3.1-4
pve-docs: 6.1-6
pve-edk2-firmware: 2.20200229-1
pve-firewall: 4.1-2
pve-firmware: 3.0-7
pve-ha-manager: 3.0-9
pve-i18n: 2.1-1
pve-qemu-kvm: 4.1.1-4
pve-xtermjs: 4.3.0-1
qemu-server: 6.1-20
smartmontools: 7.1-pve2
spiceterm: 3.1-1
vncterm: 1.6-1
zfsutils-linux: 0.8.3-pve1

Für einen Tipp bin ich dankbar!

Tony

 

[fiona]

Könntest Du testen, ob der Fehler auch kommt, wenn der Container mit lxc-start -n 3213 gestartet wird? Bei mir kommt er dann nie. Und wenn der Container über die GUI oder mit pct start 3213 gestartet wird, bekomme ich den Fehler, wenn ich lxc-console -n 3213 benutze, aber nicht, wenn ich lxc-attach -n 3213 benutze. Ist das bei Dir auch so?

 

[wbumiller]

Ich nehme an du benutzt `pct enter`?
Denn das Verhalten hier liegt daran in welchem zustand das signal handling ist. `pct` setzt wohl `SIGPIPE` auf ignore, was dazu führt, dass `tr` den pipe fehler beim `write` bekommt, statt vom standard `SIGPIPE` handler terminiert zu werden. (Mit `lxc-attach` passiert das nicht zur zeit scheinbar nicht.)

# via pct enter:
$ grep SigIgn /proc/self/status
SigIgn: 0000000000001000

# via lxc-attach oder xtermjs console:
$ grep SigIgn /proc/self/status
SigIgn: 0000000000000000

Schneller "fix", nach `pct enter` die shell als "login" shell aufrufen, zb `exec bash -l` um ein "standard" environment zu bekommen.

 

[fiona]

Nein, ich habe direkt lxc-attach benutzt.

Mit pct enter ist's immer

SigIgn: 0000000000001000

In der Web-Konsole in der GUI hängt es davon ab, ob mit pct start oder lxc-start gestartet wurde. Scheint so, als ob das Signal handling über unser Perl vererbt wird.

 

[tony blue]

Könntest Du testen, ob der Fehler auch kommt, wenn der Container mit lxc-start -n 3213 gestartet wird? Bei mir kommt er dann nie. Und wenn der Container über die GUI oder mit pct start 3213 gestartet wird, bekomme ich den Fehler, wenn ich lxc-console -n 3213 benutze, aber nicht, wenn ich lxc-attach -n 3213 benutze. Ist das bei Dir auch so?

Das ist bei mir auch so. Der Fehler tritt auf bei einem pct start 3211; pct enter 3211 - nicht hingegen bei lxc-start -n 3211; lxc-console -n 3211.

Tony