unser Samba in 7.2 bockt mal wieder oder immer noch.
Die smb-Sessions fressen mit der Zeit immer mehr RAM und alle gefragten Superschlau-KIs tippen auf ein Memory Leak. Sind wir wirklich die einzigen, die davon betroffen sind?
Dachten wir bewerfen das Problem mal mit RAM, also 60GByte, aber selbst das laeuft dann irgendwann voll.
es sit eine Eigenschaft von Linux den Hauptspeicher immer voll auszunutzen: warum sollte es auch etwas aus dem schnellen Zugriffsbereich heraus legen, wenn die Notwendigkeit nicht besteht. Insofern finde ich einen „vollen Hauptspeicher“ nicht besorgniserregend sondern wünschenswert.
Gibt es den negative Nebenwirkungen?
Es tut mir Leid, dass das Update bei euch nicht geklappt hat: die allgemeine Erfahrung zeigt inzwischen, nachdem sehr viele Schulen upgegradet haben, dass es dabei eher selten zu Problemen kommt.
WIe lange ist es den her, dass du das upgrade versucht hast?
Es kann gut sein, dass die aufgetretenen Probleme inzwischen gefixed wurden.
LG
Holger
Das geht halt bei uns schon bis zu oom-kill und das ist schon besorgniserregend, auch sollten so popelige Prozesse wie smb sich keine 1,2GByte RAM nehmen, vor allem wenn es davon je nach aktueller Userzahl hunderte geben kann.
Letztes Wochenende, hab einen Klon gemacht und das dann mal durchgespielt, aber nicht mehr lange gesucht, da Zeitmangel. So wie’s aussieht wurde da nur das darunterliegende Ubuntu geupgradet, Linuxmuster duempelt noch auf dem alten Stand rum.
I can confirm this, I associate it with updating the Ubuntu server samba packages (it did not occur with packages ending in version 1.6, but it probably does with the current 1.8 and the previous 1.7). For now, I have solved this by setting up a weekly reboot on the Proxmox server with crond at a late hour on the weekend.
Ich weiß nicht, ob die Dinge zusammenhängen … aber dass die Samba-Tasks so viel CPU-Last erzeugen, hatte ich ja schon vor längerer Zeit hier gepostet:
Diesen Effekt kann ich beobachten, seitdem wir
mailcow
edulution
per LDAP an den v7-Server anbinden. Die Ursache ist aber leider nach wie vor unklar. Wie man sieht, hat der Server eigentlich mehr als genug Ressourcen
Bei uns sind das ja im Moment die smbd-Sitzungen von den PCs und den Usern, die sich jeweils ueber den Tag zu jeweils mehr als 1 GByte hochjuckeln und das kann nicht korrekt sein.
Bei Dir sind die smbd-Prozesse ja noch im Rahmen.
Vielleicht habt ihr nicht soviele User gleichzeitig am Start, bei uns kommen schonmal 200 gleichzeitige Sitzungen zusammen, da duerfen sich die Prozesse nicht so vollhauen.
Wenn ich in top oder htop benutzten Swap sehe, dann werde ich immer unruhig.
Ich habe die Sache bisher nicht beobachtet, während Anmeldungen in den Computerräumen laufen. Das, was ich hier beobachte, hängt aber ganz offensichtlich mit den Sync-Scripten zusammen, die die User-Accounts auf den beiden o.g. Servern per LDAP mit dem v7-Server abgleichen. Wir werden in der kommenden Woche zumindest den mailcow-Server auf die „neue“ LDAP-Anbindung umstellen, so dass da nicht mehr dieses Python-Script im Hintergrund laufen muss. Ich hoffe, dass das Besserung bringen wird. Was edulution angeht, ist der Effekt aber der gleiche. Wie man das dort lösen soll, weiß ich bisher leider noch nicht. Dass die CPU-Last während des Abgleichs auf 100% hoch geht, finde ich jedenfalls nicht ganz normal.
Viele Grüße,
Michael
/usr/sbin/linuxmuster-release-upgrade | tee /root/migration-to-lmn73.log
Problem ist aber tatsaechlich, dass nur die Ubuntuquellen geaendert werden, lmn73 ist nirgends verlinkt. Ich schau mir morgen nochmal die Logs genauer an, da laeuft irgendwas schief.
Tach,
upgrade meckert wegen GRUB rum, vermutlich weil wir irgendwann die VM von KVM nativ auf Proxmox umgezogen haben und macht selbst nach dem Fixen des Problem nicht weiter mit der Migration von 7.2 auf 7.3. Kann man das auch haendisch anschuppsen?
Das ist relativ bekannt, dass manchmal das Upgrade von LTS zu LTS Probleme mit Grub hat. Das sieht man mit einer Suche wie z.B. „ubuntu lts upgrade grub problem“. Das war schon der Fall vor 10 Jahren.
Anscheinend gibt es dieses Mal etwas Richtung Secure Boot oder EFI zu suchen. Je nach Fehlermeldung gibt es bestimmt einige Antworte im Netz.
Hallo Arnaud,
mein Problem ist ja eher, dass dann die Migration von 7.2 auf 7.3 nicht mehr startet, die VM selbst bootet nach Ubuntuupgrade auf 24.04 einwandfrei, LMN bleibt aber auf 7.2 haengen, da die sources.list nicht umgeschrieben wird.
Ich pfusch das jetzt mal irgendwie hin, glaub nicht, dass das Migrationsskript wirklich tut.
Werden da eigentlich irgendwo die alten Quellen (LMN71 und LMN72) entfernt? Also vom Skript?
Meanwhile, I was looking at this smbd memory leak today (without too much traffic), and in one day, the freshly restarted samba grew from 200 MB to 7.3 GB. If it runs smoothly for several days, it can even eat up all the memory, so it’s quite a serious regression from 2:4.15. With version 13+dfsg-0ubuntu1.8, let’s hope the 1.9 patch comes quickly. Until then, if you haven’t updated from 1.6, don’t do it…
Ja, das kann sein. Ich glaube nicht, dass man es zwei mal hinter einander aufrufen kann. Lieber neu anfangen, und dieses Mal ganz genau die Fehlermeldung fangen, das könnte helfen um das Problem zu lösen.
Mit dem selben Key. D.h., muss man nur die Quelle unter /etc/apt hinzufügen.
Das passiert erst am Ende des Skripts, wie man es hier lesen kann:
Glaube ich nicht, aber das habe ich nicht überprüft.
I have the same version installed i none school. Actually, I can see 63 tasks running and 1,8GB memory used. That’s ok. I think what matter is not only the samba process itself, but the extern services which are binding to samba too (e.g. Nextcloud ?).
Ja, das hab ich gefunden und mit perplexity (gibt fuer Paypaluser uebrigens ein Jahr gratis Premium-Shit) angepasst auf 24.04, Migration meckert dann aber trotzdem noch wegen Keys und anderem Kram, hab aber alles irgendwie zurechtgepfuscht, keine Nerven mehr uebrig.
#!/bin/bash
#
# thomas@linuxmuster.net
# 20250721 angepasst für Ubuntu 24.04
#
# options
echo "$@" | grep -q "\-\-force" && donotask="yes"
echo "$@" | grep -q "\-\-reboot" && autoreboot="yes"
if echo "$@" | grep -q "\-\-help"; then
echo "Usage: linuxmuster-release-upgrade [--force|--reboot|--help]"
exit 0
fi
# security query
if [ -n "$donotask" ]; then
echo "### linuxmuster.net 7.3 upgrade ###"
else
answer="I have been warned"
echo "############################################################"
echo "# #"
echo "# ATTENTION! #"
echo "# #"
echo "# This script upgrades your system to linuxmuster.net 7.3! #"
echo "# Make sure you have created a snapshot before. #"
echo "# #"
echo "############################################################"
echo
echo -n "To continue enter \"$answer\": "
read given_answer
[ "$given_answer" = "$answer" ] || exit 1
fi
# save resolv.conf
cp /etc/resolv.conf /etc/resolv.conf.release-upgrade
UBUNTU_VERSION=$(lsb_release -rs)
if [ "$UBUNTU_VERSION" = "24.04" ]; then
echo "Ubuntu 24.04 erkannt. Ubuntu-Upgrade wird übersprungen."
else
# start release upgrade noninteractively
echo DPkg::options \{ \"--force-confdef\"\; \"--force-confold\"\; \} > /etc/apt/apt.conf.d/local
apt-get -y install --reinstall python3-debian # repair possibly broken package
if ! do-release-upgrade -m server -f DistUpgradeViewNonInteractive; then
rm -f /etc/apt/apt.conf.d/local
echo "An error ocurred!"
exit 1
fi
# test release number
if grep -q "22.04" /etc/issue; then
rm -f /etc/apt/apt.conf.d/local
echo "Upgrade failed!"
exit 1
fi
fi
# restore resolv.conf
rm -f /etc/resolv.conf
mv /etc/resolv.conf.release-upgrade /etc/resolv.conf
# disable obsolete services
for s in isc-dhcp-server6 systemd-resolved; do
for c in stop disable mask; do
systemctl $c $s
done
done
# ensure ntpsec pkgs are installed
DEBIAN_FRONTEND=noninteractive apt-get -y install ntpsec ntpsec-ntpdate ntpsec-ntpdig
# create repo list
echo "deb https://deb.linuxmuster.net/ lmn73 main" >> /etc/apt/sources.list.d/lmn.list
# upgrade linuxmuster pkgs
DEBIAN_FRONTEND=noninteractive linuxmuster-distupgrade && apt-get clean
# remove apt tweak
rm -f /etc/apt/apt.conf.d/local
# reboot
[ -n "$autoreboot" ] && reboot
Wuerde das nicht Sinn machen bei einem Migrationsskript?
Hat das Migrationsskript von 7.2 auf 7.3 bei irgendjemandem wirklich funktioniert? Ernstgemeinte Frage.
