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

tony blue

Well-Known Member
Dec 26, 2017
79
2
48
52
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
 
Last edited:
Hallo,
kann es hier nicht reproduzieren (auf einem frisch installierten ubuntu-18.04-standard_18.04.1-1_amd64.tar.gz-Template):
Code:
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.
 
Last edited:
Hallo Fabian_E,

vielen Dank für die Rückmeldung.

Code:
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

Code:
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
 
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?
 
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.)

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

Code:
# 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.
 
Nein, ich habe direkt lxc-attach benutzt.

Mit pct enter ist's immer
Code:
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.
 
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
 

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!