Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 15 Next »

Mit der neuen Kernelserie 4.9 wird es einige grundlegende Änderungen und weitergehende Möglichkeiten geben.

Die Bootdateien des neuen Kernels nutzen schon udev und bringen außerdem alle möglichen Module für Festplatten-Controller mit. Dadurch kann eine Installation ohne Änderung der initrd auf eine neue Hardware übertragen werden und sollte dort problemlos booten.

Dadurch werden allerdings die Bootdateien viel größer als bisher, wodurch der Platz in /boot eng werden kann. Gegebenenfalls muss mittels entsprechender Tools die boot-Partition vergrößert werden.

Es werden prinzipiell nur zwei Varianten der initrd erzeugt, je nachdem, ob das spätere Bootmedium eine interne Platte oder ein USB-Stick ist:

Im ersten Fall werden die Module usb-storage und uas blacklisted, damit sich Devices eventuell angeschlossener USB-Sticks/Platten nicht zwischen die Devices der internen Platten schieben können; insbesondere könnte es sonst passieren, dass sich ein USB-Device zwischen die Platten eines RAIDs drängelt. Die Module usb-storage und uas werden in diesem Fall erst nach der Durchlaufen der initrd im Init-Prozess geladen.

Im zweiten Fall werden die Module usb-storage und uas nicht blacklisted, da sie beim Booten für den Zugriff auf das auf USB installierte System benötigt werden.

Mit dem Base-Update 2.8.18 wurde die fstab derart angepasst, dass die Partitionen der Boot-Platte (boot, swap und root) mittels UUID gemountet werden, so dass der Boot nicht davon abhängt, wie udev die sdX-Devices auf die physikalischen Platten verteilt. Eine entsprechende Konvertierung auf eindeutige Platten- und Partitions-UUIDs der /etc/lilo.conf nehmen die aktuellen Kernelpakete beim Update vor.

Mit dem Kernel 4.9 entfällt das alte fest in den Kernel integrierte IDE-Modul und somit nun auch die hdX-Devices. IDE-Devices werden nun auch von den libata basierten Modulen behandelt, womit diese zu sdX-Devices werden. Dies kann auf Systemen, die bislang hdX- und sdX-Devices hatten, zu Verschiebungen führen.

Vergrößerung der boot-Partition

Da die Boot-Dateien, insbesondere die initrd, die nun alle möglichen Festplattenkontroller-Module mitbringt, deutlich größer sind (Kernel 3.16 ca. 7-8 MB, Kernel 4.9 12-14 MB), wird für die Bootvarianten eis, oldeis und gegebenenfalls auch die Fallback-Option mehr Platz in der Boot-Partition benötigt, als es ältere Installer eingerichtet haben. Zukünftige Installer werden für die Boot-Partition 96 MB vorsehen, wenn das Installationsmedium größer als 1 GB ist. Mittels gparted (https://gparted.org/livecd.php) kann boot auf Kosten der anderen Partitionen vergrößert werden. Auf einer Standard eisfair-Installation mit boot (1. Partition), swap (2. Partition) und root (3. Partition) könnte man mittels gparted die swap-Partition am Anfang um einige MB verkleinern und diese dann der boot-Partition zuschlagen. Ohne swap-Partition muss man den notwendigen Platz durch Verkleinern der root-Partition freiräumen. Eine Kurzanleitung zu gparted hat Heise/c't als Tipp und Trick https://www.heise.de/tipps-tricks/Linux-Partition-vergroessern-4164154.html veröffentlicht.

Auch wenn gparted selbst bei richtiger Anwendung perfekt funktioniert, ist ein Image der Platte Pflicht, denn Bedienfehler, Rechnerabstürze oder Stromausfälle kann auch gparted nicht ungeschehen machen!

Im folgenden eine Schritt für Schritt Anleitung zur Vergrößerung der boot-Partition (/dev/sdX1) auf Kosten der swap-Partition (/dev/sdX2), natürlich ohne jede Gewähr; sdX bezeichnet hier und im folgenden das Device der Platte, wie es in gparted erscheint:

  • Booten des gparted-Livesystem von CD-Rom oder USB-Stick - Nach Aufbau des Desktop startet gparted mit root-Rechten automatisch.
  • Wähle aus der Schaltfläche am rechten oberen Bildschirmrand die richtige Platte aus.
  • Mit Rechtsklick auf die Partition /dev/sdX1 das Kontextmenü aufrufen, "Überprüfen" auswählen und mit dem "Anwenden"-Button durchführen.
  • Mit Rechtsklick auf die Partition /dev/sdX2 das Kontextmenü aufrufen, "Größe ändern/Verschieben" auswählen.
  • Nun wenden wir uns zunächst der swap-Partition zu und verkleinern diese, so dass vor ihr freier Platz entsteht.
  • Im "Größe ändern/Verschieben"-Fenster zunächst die Option "Ausrichten an:" auf MiB stellen.
  • Nun mit der Maus das schwarze Dreieck an der linken Seite anfassen (Rechts-Links-Pfeil erscheint) und wie gewünscht nach rechts verschieben; die Eingabeboxen zeigen die gewählten Werte numerisch an.
  • Durch Klick auf "Größe ändern/Verschieben" wird die eingestellte Operation vorgemerkt.
  • Nun wenden wir uns der boot-Partition zu und vergrößern diese bis zum Beginn der swap-Partition.
  • Mit Rechtsklick auf die Partition /dev/sdX1 das Kontextmenü aufrufen, "Größe ändern/Verschieben" auswählen.
  • Im "Größe ändern/Verschieben"-Fenster zunächst die Option "Ausrichten an:" auf MiB stellen.
  • Nun mit der Maus das schwarze Dreieck an der rechten Seite anfassen (Rechts-Links-Pfeil erscheint) und bis an den rechten Rand verschieben; die Eingabeboxen zeigen die gewählten Werte numerisch an.
  • Durch Klick auf "Größe ändern/Verschieben" wird die eingestellte Operation vorgemerkt.

Nun sind die gewünschten Operationen vorgemerkt, sie werden im unteren Abschnitt des gparted-Fensters aufgelistet, aber bis auf den Dateisystemcheck der boot-Partition ist noch nichts passiert. Man kann durch Rechtsklick in diesem Operationen-Abschnitt auch "alle Operationen löschen", mit "letzte Operation rückgängig machen" der Reihe nach Operationen wieder entfernen oder gparted beenden.

  • Zur Durchführung der vorgemerkten Operationen, klickt man nun auf den "Anwenden"-Button. Nun werden alle Operationen in der festgelegten Reihenfolge abgearbeitet. Danach kann gparted beendet, der PC heruntergefahren und eisfair wieder gebootet werden.

Hat man keine swap-Partition, muss man obige Schritte ebenfalls für /dev/sdX2 durchführen, nur das dies dann eben die root-Partition ist. Diese sollte, wie oben für die boot-Partition geschehen, vorher überprüft werden.

Ist es nicht gewollt, eine vorhandene swap-Partition (/dev/sdX2) zu verkleinern, muss der für boot zusätzlich benötigte Platz durch Verkleinern der root-Partition (/dev/sdX3) bereitgestellt werden:

  • Nach Überprüfung verkleinern der root-Partition (/dev/sdXa3), so dass vor ihr Freiraum entsteht.
  • Verschieben der swap-Partition (/dev/sdX2) bis zum Beginn der root-Partition; im "Größe ändern/Verschieben"-Fenster mit Partition mit der Maus innerhalb des Partitions-Rechtecks anfassen und ganz nach rechts schieben.
  • Wie oben beschrieben nun die boot-Partition (/dev/sdX1) vergrößern.

Befindet sich auf der eisfair-Systemplatte neben den drei Standardpartitionen auch eine vierte Partition (/dev/sdX4), die sogenannte data-Partition, kann auch diese den für die boot-Partition zusätzlich benötigten Platz bereitstellen:

  • Nach Überprüfung verkleinern der data-Partition (/dev/sdX4), so dass vor ihr Freiraum entsteht
  • Verschieben der root-Partition (/dev/sdX3) bis zum Beginn der data-Partition; im "Größe ändern/Verschieben"-Fenster mit Partition mit der Maus innerhalb des Partitions-Rechtecks anfassen und ganz nach rechts schieben.
  • Verschieben der swap-Partition (/dev/sdX2) bis zum Beginn der root-Partition; im "Größe ändern/Verschieben"-Fenster mit Partition mit der Maus innerhalb des Partitions-Rechtecks anfassen und ganz nach rechts schieben.
  • Wie oben beschrieben nun die boot-Partition (/dev/sdX1) vergrößern

Empfehlenswert ist es, mit dem gparted-Programm vorher mal an einem in Partitionen unterteilten Stick zu üben.

Benennung von Platten- und Partitions-Devices durch udev und daraus folgende Konsequenzen

Jedem Platten- oder Partitions-Device werden durch udev in /dev/disk/by-id und /dev/disk/by-uuid eindeutige Devicenamen zugeordnet:

# ls -l /dev/disk/by-id 
total 0
lrwxrwxrwx 1 root root  9 Oct 15 18:38 ata-ATAPI_DVD-ROM_16XMax -> ../../sr0
lrwxrwxrwx 1 root root  9 Oct 15 18:38 ata-WDC_WD10EFRX-68PJCN0_WD-WCC4J0123456 -> ../../sdb
lrwxrwxrwx 1 root root 10 Oct 15 18:38 ata-WDC_WD10EFRX-68PJCN0_WD-WCC4J0123456-part1 -> ../../sdb1
lrwxrwxrwx 1 root root 10 Oct 15 18:38 ata-WDC_WD10EFRX-68PJCN0_WD-WCC4J0123456-part2 -> ../../sdb2
lrwxrwxrwx 1 root root 10 Oct 15 18:38 ata-WDC_WD10EFRX-68PJCN0_WD-WCC4J0123456-part3 -> ../../sdb3
lrwxrwxrwx 1 root root 10 Oct 15 18:38 ata-WDC_WD10EFRX-68PJCN0_WD-WCC4J0123456-part4 -> ../../sdb4
lrwxrwxrwx 1 root root  9 Oct 15 18:38 ata-WDC_WD10EFRX-68PJCN0_WD-WCC4J6543210 -> ../../sda
lrwxrwxrwx 1 root root 10 Oct 15 18:38 ata-WDC_WD10EFRX-68PJCN0_WD-WCC4J6543210-part1 -> ../../sda1
lrwxrwxrwx 1 root root 10 Oct 15 18:38 ata-WDC_WD10EFRX-68PJCN0_WD-WCC4J6543210-part2 -> ../../sda2
lrwxrwxrwx 1 root root 10 Oct 15 18:38 ata-WDC_WD10EFRX-68PJCN0_WD-WCC4J6543210-part3 -> ../../sda3
lrwxrwxrwx 1 root root 10 Oct 15 18:38 ata-WDC_WD10EFRX-68PJCN0_WD-WCC4J6543210-part4 -> ../../sda4
lrwxrwxrwx 1 root root  9 Oct 15 18:38 ata-WDC_WD5002AALX-00J37A0_WD-WCAYUX987654 -> ../../sdc
lrwxrwxrwx 1 root root 10 Oct 15 18:38 ata-WDC_WD5002AALX-00J37A0_WD-WCAYUX987654-part1 -> ../../sdc1
lrwxrwxrwx 1 root root  9 Oct 15 18:38 md-uuid-135afd76:948553dc:948eeef1:172592f9 -> ../../md2
lrwxrwxrwx 1 root root  9 Oct 15 18:38 md-uuid-203badca:8a80e9c7:8dc76d1d:46951125 -> ../../md1
lrwxrwxrwx 1 root root  9 Oct 15 18:38 md-uuid-36bc0c98:73b1d447:1ed7b829:58d71fd0 -> ../../md4
lrwxrwxrwx 1 root root  9 Oct 15 18:38 md-uuid-40fd76c9:661c73fe:a10f393a:eaf0a8dd -> ../../md3
lrwxrwxrwx 1 root root  9 Oct 15 18:38 wwn-0x50014ee1da2a4aa0 -> ../../sdc
lrwxrwxrwx 1 root root 10 Oct 15 18:38 wwn-0x50014ee1da2a4aa0-part1 -> ../../sdc1
lrwxrwxrwx 1 root root  9 Oct 15 18:38 wwn-0x50014ee2093d24c2 -> ../../sdb
lrwxrwxrwx 1 root root 10 Oct 15 18:38 wwn-0x50014ee2093d24c2-part1 -> ../../sdb1
lrwxrwxrwx 1 root root 10 Oct 15 18:38 wwn-0x50014ee2093d24c2-part2 -> ../../sdb2
lrwxrwxrwx 1 root root 10 Oct 15 18:38 wwn-0x50014ee2093d24c2-part3 -> ../../sdb3
lrwxrwxrwx 1 root root 10 Oct 15 18:38 wwn-0x50014ee2093d24c2-part4 -> ../../sdb4
lrwxrwxrwx 1 root root  9 Oct 15 18:38 wwn-0x50014ee2095c32c1 -> ../../sda
lrwxrwxrwx 1 root root 10 Oct 15 18:38 wwn-0x50014ee2095c32c1-part1 -> ../../sda1
lrwxrwxrwx 1 root root 10 Oct 15 18:38 wwn-0x50014ee2095c32c1-part2 -> ../../sda2
lrwxrwxrwx 1 root root 10 Oct 15 18:38 wwn-0x50014ee2095c32c1-part3 -> ../../sda3
lrwxrwxrwx 1 root root 10 Oct 15 18:38 wwn-0x50014ee2095c32c1-part4 -> ../../sda4

# ls -l /dev/disk/by-uuid
total 0
lrwxrwxrwx 1 root root 10 Oct 15 18:38 12834961-5ffc-4893-b0d6-06290813633d -> ../../sdc1
lrwxrwxrwx 1 root root  9 Oct 15 18:38 d1e22432-f054-4de6-b96b-a6fc4a48ff1d -> ../../md4
lrwxrwxrwx 1 root root  9 Oct 15 18:38 ae8c6c23-60b2-4db6-9b8f-34558604c9d4 -> ../../md3
lrwxrwxrwx 1 root root  9 Oct 15 18:38 bfb57216-0e4f-4ba8-b2da-d4c34530cb27 -> ../../md1
lrwxrwxrwx 1 root root  9 Oct 15 18:38 f11c5f08-8f4d-49bb-aa19-f90918329887 -> ../../md2

Wie zu erkennen ist, handelt es sich bei diesen eindeutigen Devicenamen in /dev/disk/by-id und /dev/disk/by-uuid um Links auf die aktuell den Platten und Partitionen zugeordneten /dev/sdXn-Devices, wobei /dev/sdX-Namen die Platte und /dev/sdXn-Namen Partitionen bezeichnen. Für physikalische Platten und Partitionen werden in /dev/disk/by-id sogar deren zwei angelegt, nämlich einmal von Plattenname und Seriennummer abgeleitet und einmal mit dem Prefix wwn (World Wide Number). Die Partitionslinks in /dev/disk/by-id leiten sich von den Links für die ganze Platte und einem angehängten Suffix "-partN" für die jeweilige Partition ab, die Links in /dev/disk/by-uuid werden aus der UUID des Dateisystems gebildet.

Durch die Verwendung von udev im Bootprozess und/oder das Entfallen des alten kernelintegrierten IDE-Moduls kann es zu Umbennung der Platten- und Partitions-Devices kommen. Deshalb wird zukünftig in der /etc/lilo.conf und auch in der fstab für die Systemplatte mit von by-id und by-uuid abgeleiteten Devicenamen gearbeitet, die eindeutig und fix sind. Jedoch können an anderer Stelle in der Konfiguration diverser Pakete oder eigener Skripte noch hdX- oder sdX-Devices genutzt worden sein, die gegebenenfalls angepasst werden müssen.

Soweit möglich, ist die Verwendung eindeutiger Devicenamen vorzuziehen, für Partitionen vorzugsweise aus /dev/disk/by-uuid, da diese z. B. beim Klonen auf eine neue Platte erhalten bleiben.

Besitzt ein Rechner mehrere verschiedene Festplatten-Controller mit jeweils einer oder mehreren angeschlossenen Festplatten, können die Devicenamen sogar ineinander verwoben sein, z. B.: Controller 1 Platte 1 → /dev/sda, Controller 2 Platte 1 → /dev/sdb, Controller 1 Platte 2 → /dev/sdc, ...

Im Folgenden sollen verschieden Fälle behandelt werden:

Bisher eine SATA- oder SCSI-Platte als sda-Device

Es sind keine Korrekturen erforderlich.

Bisher eine IDE-Platte als hda-Device

Diese wird nun zu sda; in allen Paketen oder eigenen Skripte ist also eine Referenz von /dev/hda auf /dev/sda bzw. bei Partitionsverweisen von /dev/hdaX auf /dev/sdaX zu ändern oder man benutzt die eindeutigen Devicenamen.

Bisher eine IDE-Platte als hda-Device und eine oder mehrere interne SATA- und/oder SCSI-Platten (sdX-Devices)

Die IDE-Platte wird nun zu einem sdX-Device, wobei vorab nicht vorhersehbar ist, in welcher Reihenfolge den Platten durch udev die fortlaufenden Devicenamen sda, sdb, ... zugeordnet werden. Für eine stabile Zuordnung sollten in Paketkonfigurationen, eigenen Skripten oder der /etc/fstab die eindeutigen Devicenamen benutzt werden.

Bisher eine IDE-Platte als hda-Device und eine oder mehrere externe USB-Platten (sdX-Devices)

Die IDE-Platte wird nun zu einem sdX-Device. Die Devicenamen der USB-Platten verschieben sich dadurch um eine Position (sda→sdb; sdb→sdc, ...). Für eine stabile Zuordnung sollten in Paketkonfigurationen, eigenen Skripten oder der /etc/fstab die eindeutigen Devicenamen benutzt werden.

Bisher eine IDE-Platte als hda-Device, eine oder mehrere interne SATA- und/oder SCSI-Platten (sdX-Devices) und eine oder mehrere externe USB-Platten (sdX-Devices)

Die IDE-Platte wird nun zu einem sdX-Device, wobei vorab nicht vorhersehbar ist, in welcher Reihenfolge den Platten durch udev die fortlaufenden Devicenamen sda, sdb, ... zugeordnet werden. Für eine stabile Zuordnung sollten in Paketkonfigurationen, eigenen Skripten oder der /etc/fstab die eindeutigen Devicenamen benutzt werden. Die USB-Platten reihen sich hinter den internen Platten ein, wobei man hier auch die UUID basierten Devicenamen in Paketkonfigurationen, eigenen Skripten oder der /etc/fstab nutzen kann.

Bisher zwei oder mehr interne SATA- und/oder SCSI-Platten (sdX-Devices)

Es ist vorab nicht vorhersehbar, in welcher Reihenfolge den Platten durch udev die fortlaufenden Devicenamen sda, sdb, ... zugeordnet werden. Für eine stabile Zuordnung sollten in Paketkonfigurationen, eigenen Skripten oder der /etc/fstab die eindeutigen Devicenamen benutzt werden.

Bisher zwei oder mehr interne SATA- und/oder SCSI-Platten (sdX-Devices) und eine oder mehrere externe USB-Platten (sdX-Devices)

Es ist vorab nicht vorhersehbar, in welcher Reihenfolge den Platten durch udev die fortlaufenden Devicenamen sda, sdb, ... zugeordnet werden. Für eine stabile Zuordnung sollten in Paketkonfigurationen, eigenen Skripten oder der /etc/fstab die eindeutigen Devicenamen benutzt werden. Die USB-Platten reihen sich hinter den internen Platten ein, wobei man hier auch die UUID basierten Devicenamen in Paketkonfigurationen, eigenen Skripten oder der /etc/fstab nutzen kann.

Bisher RAID mit 2 oder 3 Platten

RAIDs werden schon bislang über die UUIDs assembliert. Für Überwachungsaufgaben/Monitoring wird man aber auch auf die einzelnen Member des RAIDs zugreifen wollen; für eine fixe Zuordnung empfiehlt sich daher die Nutzung der eindeutigen Devicenamen für die einzelnen Member des RAIDs.

Bisher RAID mit 2 oder 3 Platten und eine oder mehrere weitere SATA- oder SCSI-Platten

RAIDs werden schon bislang über die UUIDs assembliert, die sdX-Devices können sich aber zwischen die Devices des RAIDs schieben. Für Überwachungsaufgaben/Monitoring wird man aber auch auf die einzelnen Member des RAIDs zugreifen wollen bzw. auf die weiteren Platten in Paketkonfigurationen, eigenen Skripten oder der /etc/fstab; für eine fixe Zuordnung empfiehlt sich daher die Nutzung der eindeutigen Devicenamen.

Bisher RAID mit 2 oder 3 Platten und eine oder mehrere externe USB-Platten

RAIDs werden schon bislang über die UUIDs assembliert. Für Überwachungsaufgaben/Monitoring wird man aber auch auf die einzelnen Member des RAIDs zugreifen wollen; für eine fixe Zuordnung empfiehlt sich daher die Nutzung der eindeutigen Devicenamen. Die USB-Platten reihen sich hinter den internen Platten ein, wobei man hier auch die eindeutigen Devicenamen in Paketkonfiguration, eigenen Skripten oder der /etc/fstab nutzen kann.

Bisher RAID mit 2 oder 3 Platten, eine oder mehrere weitere SATA- oder SCSI-Platten und eine oder mehrere externe USB-Platten

RAIDs werden schon bislang über die UUIDs assembliert, die sdX-Devices können sich aber zwischen die Devices des RAIDs schieben. Für Überwachungsaufgaben/Monitoring wird man aber auch auf die einzelnen Member des RAIDs zugreifen wollen bzw. auf die weiteren Platten in Paketkonfigurationen, eigenen Skripten oder der /etc/fstab; für eine fixe Zuordnung empfiehlt sich daher die Nutzung der eindeutigen Devicenamen. Die USB-Platten reihen sich hinter den internen Platten ein, wobei man hier auch die eindeutigen Devicenamen in Paketkonfiguration, eigenen Skripten oder der /etc/fstab nutzen kann.

Angabe von Devicenamen in eigenen Skripten

Eine eindeutige fixe Zuordnung erhält man durch Verwendung von eindeutigen Devicenamen. Im Falle von wechselnden externen USB-Platten z. B. für Backupzwecke kann es jedoch sinnvoll sein, wie bisher mit einem sdX-Device bzw. sdXn-Device zu arbeiten. Aufgrund des Wegfalls der hdX-Devices werden hdX-Devices zu sdX-Devices und es kommt zu Verschiebungen, die in eigenen Skripten zu berücksichtigen sind.

Angabe von Devicenamen in der Konfiguration von Paketen

Eine eindeutige fixe Zuordnung erhält man durch Verwendung von eindeutigen Devicenamen, sofern der Konfigurationscheck eines Paketes dies zuläßt . Aufgrund des Wegfalls der hdX-Devices werden hdX-Devices zu sdX-Devices und es kommt zu Verschiebungen, die in den Paketkonfigurationen zu berücksichtigen sind.

hddtemp: Änderung von hdX-Devices in sdX-Devices, Berücksichtigung von Vertauschungen und Verschiebungen oder Verwendung eindeutiger Devicenamen aus /dev/disk/by-id. Es ist zu beachten, dass andere Pakete (z. B. eisgraph, ...) die Werte des hddtemp-Daemons auswerten und daher eventuell auch neu zu konfigurieren sind.

monitoring: Änderung von hdX-Devices in sdX-Devices, Berücksichtigung von Vertauschungen und Verschiebungen oder Verwendung eindeutiger Devicenamen aus /dev/disk/by-id (Platten) und /dev/disk/by-uuid (Partitionen).

smartmon: Änderung von hdX-Devices in sdX-Devices, Berücksichtigung von Vertauschungen und Verschiebungen oder Verwendung eindeutiger Devicenamen aus /dev/disk/by-id.

backup-zip, rsnapshot: Änderung von hdXn-Devices in sdXn-Devices, Berücksichtigung von Vertauschungen und Verschiebungen oder Verwendung eindeutiger Devicenamen aus /dev/disk/by-uuid.

Kernel 4.9 und das haveged-Paket

Der Kernel 4.9 erfordert einen größeren Entropiepool (Pool für Zufallszahlen) als unsere bisherigen Kernelserien. Auf einem System ohne Benutzerinteraktion stehen nicht genügend Quellen für zufällige Ereignisse zur Verfügung, so dass dieser Entropiepool oftmals nicht genügend Daten enthält und dieses dann zu stark verzögerter Ausführung bestimmter Vorgänge wie z. B. dem Aufbau von ssh-Verbindungen führt. Daher wird das haveged-Paket zwangsweise installiert und aktiviert, welches dem Entropiepool ausreichend zufällige Daten zuführt. Das haveged-Paket sollte daher weder deaktiviert noch deinstalliert werden.

Ausführung von Programmen mit festgelegtem Speicherlimit

Startet eine Anwendung unter dem neuen Kernel mit Verweis auf Speichermangel nicht mehr, sollte überprüft werden, ob für diese Anwendung eine Speicherlimit z. B. mittel "ulimit -u 100000 (entspricht 100000 KB) in der Startdatei dieser Anwendung in /etc/init.d festgelegt wurde. Setzt man dieses höher, sollte auch diese Anwendung wieder starten. So startet der Datenbankserver firebird mit vorgenannten ulimit von 100000 unter dem Kernel 3.16 neue Threads auf eine Connectanfrage, mit dem Kernel 4.9 ist das Limit jedoch auf mindestens 130000 zu setzen.

  • No labels