Re: Konflikt zwischen lxc und cgroup-bin
Hallo Martin,
vielen Dank für Deine Antwort.
On 03.07.2011 09:59, Martin Steigerwald wrote:
>
>> offenbar gibt es Konflikte zwischen lxc und cgroup-bin. Ich konnte
>> diese nicht abschließend lösen, so dass ich nur entweder lxc oder
>> cgroup-bin einsetzen kann.
>
> Zunächst einmal: Die Userspace-Seite der cgroups ist noch sehr jung
> und meines Erachtens noch nicht ausgereift. Und das hat meines
> Erachtens recht wenig mit Debian zu tun. Das dürfte anderswo auch so
> sein.
Das ist mir bekannt. Auf die Probleme damit bin ich gestoßen, als ich
erste Gehversuche damit wagte bzw. versuchte, mich hinzufinden,
hineinzulesen und zu experimentieren. Warum ein Debian-Bezug meiner
Ansicht nach schon gegeben ist, erläutere ich weiter unten.
> 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.
>> * Lxc verweigert in jedem Fall den Start eines Containers, wenn
>> cgroup-bin alle Prozesse in die Gruppe sysdefault verschiebt. Diea
>> lässt sich duch eine Änderung in /etc/default/cgconfig abstellen.
>> Der Standardwert ist meiner Ansicht nach unglücklich gewählt.
>
> Nennt Lxc einen Grund dafür? Gibt es eine Fehlermeldung?
Dieses Verhalten konnte ich aktuell nicht mehr reproduzieren. Das
spricht nun eher dafür, dass die Gruppe sysdefault keine Auswirkung auf
lxc hat.
libvirt kann lxc-Container mit und ohne cgroup sysdefault erzeugen,
lxc-start scheitert, wie weiter unten beschrieben in beiden Fällen.
>> * 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
> 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.
> /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.
>> * 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.
> 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.
> 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. ;)
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.
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.
>> 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.
> 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.
> 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.
Viele Grüße
Michael
PS: Falls der Eindruck entstehen sollte, dass ich die "Lage" ganz
fürchterlich finde: das ist nicht der Fall.
--
EDV-Serviceteam Annika & Michael Hierweck GbR
Egerstraße 53, 44225 Dortmund (Germany)
http://www.edv-serviceteam.net
Reply to: