Re: Konflikt zwischen lxc und cgroup-bin
Am Sonntag, 3. Juli 2011 schrieb Michael Hierweck:
> Hallo Martin,
Hi Michael,
> vielen Dank für Deine Antwort.
[...]
> > Insbesondere mit Debian Squeeze nicht. Wenn Du Bleeding Edge
> > einsetzen möchtest, empfehle ich Dir, auch die jeweils *neuesten*
> > Paketversionen einzusetzen, rückzuportieren.
>
> Wie auch immer handelt es sich dabei um Fehler (Wechselwirkungen), die
> beim Testen von Squeeze nicht aufgefallen sind. Es gibt nämlich keine
> Bugreports dazu, auch keine geschlossenen.
Oh, mir sind einige dieser Probleme sicherlich aufgefallen. Ich hab mir
nur damals nicht die Zeit genommen, sie zu berichten. Ich hatte schon
damals die Ansicht, dass Upstream nicht so weit ist, und es sich daher
eher um eine Vorschau auf das handelt, was hoffentlich mal auf eine schöne
Weise möglich sein wird.
Ob diese Pakete dann so in Debian Stable gehören? Gute Frage. Die btrfs-
tools sind auch drinnen und ich bin froh drum.
Bezüglich Bugreports: Es gibt vielleicht keine Debian-Bugreports.
Vielleicht aber Upstream-Bugreports. Wobei ich bei cgroup-bin nicht weiß,
inwiefern es einen Upstream-Bugtracker gibt.
> >> * cgroup-bin mountet nach /mnt/cgroup/cpu, /mnt/cgroup/devices
> >> usw., trägt diese mounts allerdings nicht nach /etc/mtab ein. Lxc
> >> verweigert dann die Arbeit und weist an, cgroups an geeigneter
> >> Stelle zu mounten.
>
> lxc-start -n xxx
> lxc-start: cgroup is not mounted
> lxc-start: failed to spawn 'xxx'
> lxc-start: cgroup is not mounted
Hmmm, lxc-start ist eine Binärdatei. Da wäre ein Blick in den Quelltext
interessant, wo es diese Fehlermeldung ausgibt und was es da prüft.
> > Schön länger nicht mehr:
> >
> > merkaba:~> grep cgroup /proc/mounts cgroup /sys/fs/cgroup cgroup
> > rw,relatime,cpu 0 0 cgroup /sys/fs/cgroup/cpuacct cgroup
> > rw,relatime,cpuacct 0 0 cgroup /sys/fs/cgroup/devices cgroup
> > rw,relatime,devices 0 0
>
> Ich weiß, dass neuere Versionen des Pakets cgroup-bin die cgroups
> woanderhin mounten, aber der Konflikt mit lxc scheint vom gewählten
> Mountpoint unabhängig zu sein.
Dann würde ich hierfür einen Bugreport gegen lxc aufmachen. lxc sollte
IMHO bereits gemountete cgroup-Dateisysteme weiternutzen, egal wo diese
gemountet sind.
> > /etc/mtab ist seit systemd mehr oder weniger deprecated. In Symlink
> > auf /proc/self/mounts müsste funktionieren. Ist hier aber auch noch
> > nicht geschehen. Hab aber auch systemd derzeit nicht drauf. Das ist
> > nämlich für Debian zumindest auch noch nicht so ganz fertig, finde
> > ich.
>
> Das mag sein, dann wäre ein weiterer Fehler in lxc, /etc/mtab
> auszuwerten.
Fehler? Es war durchaus mal üblich und ist es noch, das genau so zu
machen. Aber ja, es macht Sinn, das zu vereinheitlichen und alles deutet
darauf hin, in Zukunft /proc/self/mounts zu verwenden.
> >> * Kopiert man /proc/mounts nach /etc/mtab, so erkennt lxc, dass
> >> cgroups gemountet sind, kommt aber nicht damit klar. Lxc scheitert
> >> dann daran, dass es die Prozesse-ID des Containers nicht von
> >> /mnt/cgroup/<pid> nach /mnt/cgroup/<name> verschieben/umbenennen
> >> kann.
>
> lxc-start -n xxx
> lxc-start: No such file or directory - failed to rename cgroup
> /mnt/cgroups/cpu/5145->/mnt/cgroups/cpu/xxx
> lxc-start: failed to spawn 'xxx'
> lxc-start: No such file or directory - failed to remove cgroup
> '/mnt/cgroups/cpu/xxx'
>
> Mountet man via cgconfig alles alles /mnt/cgroup, nach /cgroup oder
> wohin auch immer, so ändert sich die Fehlermeldung nur hinsichtlich des
> Pfades.
Wie gesagt, Bugreport gegen lxc und bei näherem Interesse ggf. vorher noch
im Source schauen und ggf. einen eigenen Patch entwickeln. Vorher aber
ggf. mal auch Upstream schauen, ob es einen Bugreport gab oder die
Entwickler den Bug einfach so behoben (Git-Log).
> > Ggf. auch mal in Protokoll-Dateien schauen.
>
> Dort findet sich nichts. Eine Möglichkeit, das Ganze "more verbose" zu
> machen, habe ich auch nicht gefunden.
>
> lxc-start --logpriority=5 --logfile=$HOME/lx.log -n xxx
> erzeugt leider kein Logfile und scheint ebenfalls zu scheitern, wobei
> jegliche Ausgabe unterdrückt wird. Für 5 kann man auch andere Werte
> einsetzen.
Hmmm, mir fällt da aus dem Stegreif auch nichts an, da lxc-start eine
Binärdatei ist. Ich hätte ja vermutet, es sei ein Shell-Skript.
> > Willkommen als Betatester. ;) Das ist einfach Bleeding Edge, jeder
> > baut es ein, doch die Koordination steht noch aus. Das ist sicherlich
> > kein Debian spezifisches Problem. Mit anderen Worten: Das ist noch
> > nicht fertig. Das ist zumindest meine Einschätzung dazu.
>
> Na ja, erwartet hätte ich, dass man diese Abstimmungsprobleme vor dem
> Squeeze Release erkannt und die entsprechenden Pakete, dann ggf.
> entfernt hätte. Da ist man ja sonst auch wenig zimperlich ;) zu Gunsten
> der Stabilität. Obwohl "cgroups" bekannterweise ein neues Thema sind,
> mit viel Bewegung und wenig Erfahrung, hätte ich nicht gedacht, dass
> Squeeze hier zum Beta-Test gedacht ist. Ubuntu würde ich sowas
> zutrauen. ;)
Ich verweise auf oben: Hätte man auch btrfs-tools rausnehmen sollen,
solange BTRFS experimentell ist? Oder Ext4-fähige e2fsprogs und die
Entwicklerversion ext4dev in Debian Lenny?
Man kann da unterschiedlicher Ansicht sein. Ich bin froh, dass es drin
ist.
Es wäre aber sinnvoll, vielleicht bereits beim Installieren drauf
hinzuweisen, dass es sich hier noch um experimentelle Software für
Vorschau-Zwecke handelt.
> Debian steht mit dem Problem sicherlich nicht allein da, aber ich sehe
> es schon als Debians Aufgabe, verschiedene cgroup-nutzende Pakete
> administrativ unter einen Hut zu bekommen oder, wenn das nicht möglich
> oder angemessen erscheint, "conflicts"/"breaks" zu definieren.
Ja, das ist schon auch ein Debian-Thema. Okay.
Es steht Dir frei, Deine Ansicht durch entspechende Bugreports Kund zu tun
oder Dich selbst an der Entwicklung der Pakete zu beteiligen. Hier sehe
ich Debian-Bugreports tatsächlich als sinnvoll an.
Die Maintainer der entsprechenden Debian-Entwickler haben das ganz
offensichtlich nicht gemacht und anderer Ansicht dazu sein, ändert nichts
an der Situation. Ich würde sogar vermuten, nichtmal aus Absicht.
Vielleicht wissen die Maintainer von lxc und cgroup-bin nicht viel
voneinander? Ich vermute mal, das Problem war schlicht nicht bekannt. Ich
vermute sogar, dass sich die Maintainer aller cgroup-fähigen Pakete sich
nicht zusammengetan haben, um ihre Arbeit zu koordinieren... aber
letztlich ist das nur grob geraten. Es ist ein Haufen Arbeit, ein Debian-
Paket zu betreuen - ich weiß das von meinen letzten Arbeiten an fio 1.55,
das noch auf einen Upload wartet - da bin ich froh, über das, was ich
vorfinde.
Freie Software impliziert nicht, dass die Entwickler immer alles perfekt
machen.
> Eine "Lösung" könnte in diesem Fall darin bestehen, einen "conflict"
> zwischen zwischen cgroup-bin und lxc zu definieren, für die Versionen,
> in denen dieser Konflikt noch besteht.
Nun das wäre doch mal ein konkreter Vorschlag. Der meines Erachtens auch
für Debian Squeeze eine gewisse Relevanz hat.
> >> Ich würde gern einen Bug-Report schreiben, bin aber unsicher,
> >> welches Paket hier konkret die Schuld trifft. Generell wäre der
> >> richtige Ansatz vermutlich, eine Strategie für das cgroup-Handling
> >> festzulegen, zulässige Annahmen, und einige Vorgaben etc.
> >> definieren und alle Pakete mit cgroup Nutzung dagegen zu testen und
> >> anzupassen.
> >>
> >> [...]
> >
> > Ich würd *irgendwo* anfangen. Der Maintainer kann den Bug dann immer
> > noch woanders hin verschieben. Ich tendiere zu lxc, wenn lxc auf die
> > Schnauze fällt, wenn die cgroup-Dateisysteme anderswo gemountet sind.
> > Idealerweise würde es einfach schauen, wo sie gemountet sind oder
> > meinetwegen sie doppelt mounten, das geht glaub auch und man müsste
> > dann jeweils die gleiche Sicht sehen. Besser ist jedoch,
> > /sys/fs/cgroup zu verwenden. Das scheint sich als Standard
> > herauszukristallisieren.
> >
> > Bevor Du irgendwo anfängst, stelle aber sicher, dass Du die
> > *neuesten* Version von allem cgroup-bezogenen hast, was Du einsetzt.
> > Und am besten auch einen Kernel, der etwas neuer als 2.6.32 ist.
>
> Ich bin mir nicht sicher, ob ich das so verstehen soll, dass Bugs in
> stable nicht berichtet werden sollen, wenn sie in unstable nicht mehr
> zutreffend sind.
Jein!
1) Bezüglich Bugs, die Upstream zu lösen sind, sind aktuellste Versionen
wichtig! Upstream-Entwickler sagt Dir ansonsten wahrscheinlich: Teste mit
der aktuellen Version, bevor sie konkret auf Deinen Bericht eingehen. Ich
sehe das immer wieder bezüglich Upstream: Alte Versionen existieren
*nicht* oder sind ein Problem der Distributoren. Punkt.
2) Bezüglich der Debian-Thematik, welche Du oben erläutert hast, können,
das sehe ich jetzt auch, im begrenzten Umfang auch Änderungen an Stable
gerechtfertigt sein. Ich gehe jedoch davon aus, dass sich das auf wirklich
ganz einfache Änderungen beschränken würde, wie z.B. den von Dir erwähnten
Breaks/Conflict.
> > Wenn Dir das zu aufwändig ist, dann lasse lieber die Finger von
> > Control Groups. Zumindest solange Du Squeeze einsetzt.
>
> Mir ist das nicht zu aufwändig, ich möchte es auch noch nicht produktiv
> einsetzen, aber es ist ein interessantes Thema und irgendwann muss man
> ja anfangen, erste Erfahrungen sammeln und ggf. mal auf die Nase
> fallen.
Okay. Dann empfehle ich Dir, soweit Dir das zeitlich reinpasst, Dich mit
Bugreports, Patches ggf. zu beteiligen.
> > Bevor Du Fehlerberichte erstellst, gucke immer, welche es schon gibt.
> > Und am besten: Berichte gleich Upstream oder leite den
> > Debian-Bugreport Upstream weiter. Und poste mal die Links zu Deinen
> > Bug-Reports hier ;).
>
> Ich muss gestehen, dass ich noch nicht beurteilen kann, ob Upstream für
> die Konflikte verantwortlich ist oder Debian.
Dann ist ein Bugreport in Debian vielleicht erstmal der beste Weg. Mit dem
Hinweis, dass Du bereit bist, ggf. auch Bugreports Upstream einzureichen.
Das hören Debian-Entwickler durchaus gerne, weil Du ihnen damit etwas
Arbeit abnimmst.
Ich hab in der letzten Zeit gelernt, dass viel davon abhängt, wie ich
meine Bugreports formuliere, ob ich positive Reaktionen bekommen oder
nicht. Ein einfaches "This sucks" ohne konstruktiven Vorschlag oder
Angebot trägt nichts dazu bei, dass eine solche kommt. Und ja, ich habe
teilweise heftig über das ein oder andere gelästert. Es ist ja auch
frustrierend, wenns nicht geht, obwohl man es über Debian-Mechanismen
installierte und es ein Debian Stable ist. Ich kann das also durchaus
verstehen.
Aber ich hab auch keine einfache Antwort darauf, wie mit Upstream-
Projekten, die noch nicht ausgereift ist, am besten zu verfahren ist. Mein
Ansatz wäre: Je näher die Komponente am System ist, desto vorsichtiger,
konservativer wäre ich. Zusatzkomponenten, Optionales, da wäre ich
experimentierfreudiger. Es sieht mir so aus, dass Debian-Entwickler das
durchaus zu handhaben. Das Init-System setzt mittlerweile gerade mal auf
insserv auf, während im Grunde optionale Komponenten wie btrfs, lxc,
cgroup-bin bereits enthalten sind.
> PS: Falls der Eindruck entstehen sollte, dass ich die "Lage" ganz
> fürchterlich finde: das ist nicht der Fall.
Gutes PS, so ein wenig bekam ich in der Mitte der Mail den Eindruck.
Und nuja, es stimmt ja in Teilbereichen auch. Meine ehrliche Meinung nach
meinen Versuchen mit cgroup-bin: Es ist zumindest in Debian Squeeze noch
eine ziemliche Frickelei. Ich bin auch nicht einverstanden, wie die Tools
die Konfigurationsdateien auswertet. Bei kleinsten Fehlern gibt es ein
Parse-Fehler, ohne genau zu sagen, was dem Tool nicht passt.
Ich hab damals jedoch entschieden, nach dem ich mal einen Fehler
berichtete, mich erstmal zurückzulehnen und abzuwarten. Es ist jedoch
wichtig, dass jemand testet und Fehler berichtet, daher begrüße ich Dein
Engagement.
Ich versuche da für mich immer ein Gleichgewicht zu halten. Wenn es mir
zuviel ist, fliegts auch mal erstmal wieder raus und ich schau später
wieder rein, was ja auch völlig legitim ist. So hin- und wieder schon mit
systemd und pulseaudio geschehen. Letzteres läuft auf dem neuen ThinkPad
T520 mit neuer 64-Bit-Debian-Installation jedoch bislang problemlos.
Allerdings habe ich auch noch nicht mit der USB-Soundkarte getestet...
Ciao,
--
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7
Reply to: