Festplatten Speicherplatz Problem

Linux Clients
#1

Hallo,

wir haben bei uns das “Standard”-UCC2.1-Image auf “normalen”-PCs ausgerollt, ohne Änderungen an der Partitionsgröße
vorzunehmen.
Außerdem haben wir dann einige weitere (auch größere) Software-Pakte nachinstalliert.

War das ein “Fehler” bzw. kann es sein, dass der Platz für weitere Installationen zu knapp wird?
Einige Rechner haben Probleme z.B. Dateien in /tmp zu speichern und es kommt zu häufigen Abstürzen von LibreOffice.

Im Handbuch bin ich fündig geworden und habe auch das Script “desktop_encrypted.example” mir angeschaut. Ist das die richtige Stelle für zukünftige Installationen von PCs?
Gibt es eine Vorlage ohne Verschlüsselung in der ich einfach nur die Partitionsgrößen anpassen kann?

Viele Grüße
Torsten

#2

Hallo,

da ich den genauen Anwendungsfall bzw. die eingesetzten Programme nicht kenne, einige Hinweise und Lösungsmögilchkeiten.

Die UCC-Image Größe und die Partitionierung des UCC Desktop images bei der Generierung ist in der config Datei /usr/share/doc/ucc-image-toolkit/examples/ucc-desktop.cfg zu finden. Demnach hat die / Partition 18GiB, das Image ist ein wenig kleiner. Das reicht für vieles, wenn aber wie bei Ihnen /tmp stark genutzt wird, kann es durchaus knapp werden. Wieviel freien Speicher gibt es denn noch? Mit ‘df -h’ kann man das schnell prüfen.

Die Größe des Images selbst wird beim Image-Bau festgelegt. Um ein UCC-Image zu vergrößern hat mein Kollege schon einen Tipp gegeben, vorher muss aber die Partition, auf der das Image liegt, passend vergrößert werden.

Ein Beispielscript ohne crypt-setup, dass die konfigurierbaren Partitionsgrößen am Anfang der Datei enthält, lade ich an diesem Post mit hoch.

Eine weitere Möglichkeit ist es, ein UCC Image selbst zu erstellen. So kann die installierte Software vorausgewählt werden, und das Image hat, ebenso wie die Partitionseinstellungen, direkt die benötigte Größe.
simple_partition_script.sh (3.1 KB)

#3

Hallo,

vielen Dank für Ihre Antwort.
Ich habe verschiedene Clients mal geprüft mit “df -h”. Obwohl alle PCs (UCCs) gleich aufgesetzt sind, gibt es im Prinzip bei uns zwei Arten von Ergebnissen:
/dev/loop0 15G 15G 0 100% /
udev 1,9G 4,0K 1,9G 1% /dev
tmpfs 387M 1,3M 386M 1% /run
/dev/sda4 17G 16G 490M 97% /ucc_root
none 4,0K 0 4,0K 0% /sys/fs/cgroup
none 5,0M 0 5,0M 0% /run/lock
none 1,9G 0 1,9G 0% /run/shm
none 100M 0 100M 0% /run/user
overflow 1,0M 1,0M 0 100% /tmp
/dev/sda2 454M 145M 282M 34% /boot
/dev/sda5 441G 71M 419G 1% /home
oder
/dev/loop0 15G 5,8G 8,2G 42% /
udev 1,9G 4,0K 1,9G 1% /dev
tmpfs 376M 1,3M 375M 1% /run
/dev/sda4 17G 16G 490M 97% /ucc_root
none 4,0K 0 4,0K 0% /sys/fs/cgroup
none 5,0M 0 5,0M 0% /run/lock
none 1,9G 72K 1,9G 1% /run/shm
none 100M 40K 100M 1% /run/user
/dev/sda2 454M 176M 251M 42% /boot
/dev/sda5 93G 60M 88G 1% /home

Wenn ich das richtig deute, haben die ersten zwar ein Platzproblem, aber das scheint nicht ursächlich mi den installierten Paketen zu tun zu haben.
Konkret wird bei uns nachinstalliert:
nfs-common cifs-utils mc nano vlc audacity libxvidcore4 browser-plugin-vlc gimp gimp-help-de geogebra kdenlive kde-workspace-randr libreoffice-gtk numlockx rdesktop openjdk-7-jre icedtea-7-plugin freemind
Was könnte das Problem sein?

Die Probleme der Nutzer nehmen gerade stark zu. Die reichen von den im Anfangsbeitrag geschilderten weiter, dass die PCs extrem langsam reagieren, beim Anmelden Fehlermeldungen bringen, die Anmeldung nicht möglich ist (d.h. der Anmeldelogin verschwindet, aber der Ladebalken erscheint gar nicht oder bleibt hängen).

Ich werde unseren UCC-Clients mit “/dev/loop0 15G 15G 0 100% /” etwas mehr Platz verschaffen entsprechend der Anleitung Ihres Kollegen.
Wenn ich es außerdem richtig verstanden habe, nützt das Beispielscript für neue UCCs allein nichts, Das Image muss ich trotzdem anpassen?

Viele Grüße
Torsten

#4

Hallo,

[quote=“ucc-nutzer”]Hallo,

vielen Dank für Ihre Antwort.
Ich habe verschiedene Clients mal geprüft mit “df -h”. Obwohl alle PCs (UCCs) gleich aufgesetzt sind, gibt es im Prinzip bei uns zwei Arten von Ergebnissen:
/dev/loop0 15G 15G 0 100% /
[…]
oder
/dev/loop0 15G 5,8G 8,2G 42% /

Wenn ich das richtig deute, haben die ersten zwar ein Platzproblem, aber das scheint nicht ursächlich mi den installierten Paketen zu tun zu haben.
Konkret wird bei uns nachinstalliert:
nfs-common cifs-utils mc nano vlc audacity libxvidcore4 browser-plugin-vlc gimp gimp-help-de geogebra kdenlive kde-workspace-randr libreoffice-gtk numlockx rdesktop openjdk-7-jre icedtea-7-plugin freemind
Was könnte das Problem sein?

Die Probleme der Nutzer nehmen gerade stark zu. Die reichen von den im Anfangsbeitrag geschilderten weiter, dass die PCs extrem langsam reagieren, beim Anmelden Fehlermeldungen bringen, die Anmeldung nicht möglich ist (d.h. der Anmeldelogin verschwindet, aber der Ladebalken erscheint gar nicht oder bleibt hängen).
[/quote]

Auf den erstgenannten Rechnern ist / vollgelaufen. Die genannten Probleme sind mit hoher Wahrscheinlichkeit Auswirkungen des Problems. Irgend etwas schreibt also die Festplatte voll, die Ursache sollte gefunden werden. Ich erinnere mich, dass sie in einem anderen Thread NFS mounts einbinden wollten. Vielleicht ist das fehlgeschlagen und stattdessen wurde in das UCC Image geschrieben?

[quote=“ucc-nutzer”]
Ich werde unseren UCC-Clients mit “/dev/loop0 15G 15G 0 100% /” etwas mehr Platz verschaffen entsprechend der Anleitung Ihres Kollegen.[/quote]

Zunächst sollten Sie prüfen, wo der Plattenplatz verbraucht wird. Ich nutze dazu gerne das Programm ncdu aus dem gleichnamigen Paket. Der Aufruf sudo ncdu / gibt eine schnelle Übersicht, in welchen Verzeichnissen viele Daten liegen.

Genau, das Image muss nach dem Rollout noch angepasst werden.

#5

Hallo,
danke für die Antwort.
ncdu hat mir weitergeholfen.
Tatsächlich ist /var/tmp vollgelaufen.
Je Nutzer liegen da ca. 180MB kdecache. Diese verteilen sich vor allem auf 80MB plasma_theme_internal-system-colors.kcache und 80MB plasma_theme_default_v2.0.kcache.
Irgendwo zwischen dem 30. und 40. Nutzer ist dann /var/tmp/ .
Das Vergrößern hat bei den PCs, die am meisten genutzt werden Abhilfen geschaffen.

Gibt es dafür eine elegantere Lösung?

Viele Grüße
Torsten

#6

Hallo,

es gibt die Möglichkeit zu bestimmen, wo das kde-cache Verzeichnis angelegt wird - am besten wird es sein, dies nach /home/ zu verlagern. Es gibt bereits einen Bugeintrag, der das Verhalten in UCC verbessern soll. Dort finden Sie auch Hinweise, wie Sie das Verhalten bis dahin in Ihrer Umgebung anpassen können.

#7

Hallo,
ich kann das Problem noch nicht als gelöst abhaken.
Bei uns werden die Home-Verzeichnisse per cifs gemountet (außer bei dem RDP-Server).

  1. Versucht habe ich lokal auf den UCCs:
    mkdir /home/.kde-caches
    chgrp ‘Domain Users’ /home/.kde-caches/
    chmod 770 /home/.kde-caches/
    und im LDAP unter "users / richtlinien / desktop-richtlinien folgendes gesetzt.
    Variable: KDEVARTMP
    Value: /home/.kde-caches/
    Lokal habe ich /tmp und /var/tmp bereinigt.
    Beim Neuanmelden der Nutzer landen die kde-caches aber nach wie vor in tmp und nicht in /home/.kde-caches

  2. “spricht etwas dagegen” /var/tmp regelmäßig per Hand oder Script komplett zu bereinigen bis eine bessere Lösung greift?

  3. Eine Fehlermeldung taucht zusätzlich auf: "Call to lnusertemp failed (temporary directories full?), Check your installation
    df -h auf den betreffenden UCC bringt:
    /dev/loop0 35G 4.9G 28G 15% /
    udev 481M 4.0K 481M 1% /dev
    tmpfs 100M 1.2M 99M 2% /run
    /dev/sda4 156G 16G 133G 11% /ucc_root
    none 4.0K 0 4.0K 0% /sys/fs/cgroup
    none 5.0M 0 5.0M 0% /run/lock
    none 497M 4.0K 497M 1% /run/shm
    none 100M 4.0K 100M 1% /run/user
    /dev/sda2 454M 93M 334M 22% /boot
    /dev/sda5 73G 92M 69G 1% /home

  4. Der gepostete Script simple_partition_script.sh läuft beim Ausführen bei uns in eine Schleife.

#8

Hallo,

Wie mein Kollege am oben verlinkten Bug bemerkte, funktioniert der Workaround nur mit weiteren Tricks mit CIFS mounts.

Das sollte natürlich mit aller verwendeten Software getestet werden, grundsätzlich klingt das aber nach einem passenden Workaround. Eine Möglichkeit ist das Einrichten von cronjobs über die Univention Config Registry

Das kann neben einer vollen Festplatte auch ein Berechtigungsproblem von Verzeichnissen sein (/tmp, ~/.kde, …)

[quote=“ucc-nutzer”]
4. Der gepostete Script simple_partition_script.sh läuft beim Ausführen bei uns in eine Schleife.[/quote]
Können Sie nachvollziehen an welcher Stelle es nicht weitergeht? Gibt es einen Hinweis wenn Sie den bootsplash mit deaktivieren? Zusätzliche Hinweise kann das Einschalten des ausführlichen Logs beim booten sein (verbose=y)

#9

[url]Verzeichnis /var/tmp wird nicht bereinigt]

Wir hatten das Problem hier auch, und die Lösung mit tmpreaper funktioniert bei uns ganz gut.

#10

Hallo,

ich habe mir jetzt endlich mal Zeit für den simple_partition_script.sh nehmen können.
Die Installation läuft scheinbar gut durch und auch der Join in die Domäne klappt.
Der Neutstart nach dem Ausrollen zeigt dann das Problem.

Nach dem Durchlaufen des Rechner-Bios beginnt der PC unmittelbar neu zu starten, also genau an der Stelle an der das Betriebssystem starten sollte. Und das macht der Rechner dann halt immer im Kreis.

Ich könnte den PC vom USB-Stick booten, wenn ich wüsste nach was ich suchen soll?

Viele Grüße
Torsten

#11

Hallo,

das muss man jetzt in der Tiefe debuggen. Ich würde den Start genauer analysieren und dazu die erweiterten Startparameter debugshell=y und verbose=y setzen. Dann während des UCC Starts per ESC plymouth deaktivieren und prüfen, wo und warum der reboot erfolgt.

#12

Hallo,

ich habe den Bug im Script anscheinend gefunden. Es war

lvm vgcreate vg_ucc "${partition_device}"3

Heißen muß es aber wohl

lvm vgcreate vg_ucc "${partition_device}3"
#13

Hallo,
danke. Mit dem Tipp hat es bei mir jetzt auch funktioniert.

Mastodon