Opensuse 12.2 – textbasierter Boot Screen ohne Plymouth Animation

Leider ist unter einem aktuellem Suse oder Red Hat System Plymouth so stark in das Gespann grub2 und systemd integriert, dass ich mich eher davor hüte, alle Plymouth bezogenen Pakete zu deinstallieren. Nebenbei: Inzwischen ist wohl auch unter Ubuntu eine starke Einbindung von Plymouth in die Prozesse beim Systemstart vorgenommen worden. Siehe: http://ubuntuforums.org/showthread.php?t=1457388

Dennoch kommt ab und zu der Wunsch auf, den animierten Plymouth-Splash-Screen während des Boot-Vorgangs los zu werden, um ohne Umwege die Boot-Meldungen sehen zu können. Diesen Wunsch hatte zumindest ein Admin, der mich vorgestern per Mail anschrieb.

Auf meinen Opensuse 12.2-Systemen mit Grub2 half hier folgendes Vorgehen:

Deaktivieren des animierten Plymouth-Boot-Screens mit Hilfe von YaST2

Man öffne unter YaST2 das Modul “Boot Loader”. Im sich öffnenden Fenster gehe man zum Button “Boot Loader Options”. Das nächste Fenster zeigt eine Zeile zu Kerneloptionen:

no_plymouth_600

In dieser Zeile setzt man

splash=0

ein. Zudem entfernt man ein evtl. vorhandenes Schlüsselwort “quiet”. In Fall meines betrachteten Systems lautet die fertige Zeile dann:

video=1920×1200 resume=/dev/disk/by-id/scsi-3600050e004a669001c4b00002aaf0000-part1 splash=0 showopts

Auf anderen Systemen wird natürlich das Resume-Device für den Swap-Bereich eine andere Bezeichnung haben. Danach schließt man sukzessive die YaST2-Fenster.

YaST2 speichert die eben angegebenen YaST2-Bootloader-Daten übrigens in der Datei “/etc/default/grub” ab. Es lohnt sich, bei Gelegenheit mal einen Blick in diese Datei zu werfen! In dieser Datei kann man Basisoptionen für Grub2 hinterlegen. Auch ganz ohne YaST2, wenn es ein muss.

Auf dem hier veränderten System sieht die Datei dann so aus:

GRUB_DISTRIBUTOR=openSUSE
GRUB_DEFAULT=saved
GRUB_HIDDEN_TIMEOUT=0
GRUB_HIDDEN_TIMEOUT_QUIET=true
GRUB_TIMEOUT=300
GRUB_CMDLINE_LINUX_DEFAULT=” video=1920×1200 resume=/dev/disk/by-id/scsi-3600050e004a669001c4b00002aaf0000-part1 splash=0 showopts”
# kernel command line options for failsafe mode
GRUB_CMDLINE_LINUX_RECOVERY=”showopts apm=off noresume edd=off powersaved=off nohz=off highres=off processor.max_cstate=1 nomodeset x11failsafe”
GRUB_CMDLINE_LINUX=””
# Uncomment to enable BadRAM filtering, modify to suit your needs
# This works with Linux (no patch required) and with any kernel that obtains
# the memory map information from GRUB (GNU Mach, kernel of FreeBSD …)
#GRUB_BADRAM=0x01234567,0xfefefefe,0x89abcdef,0xefefefef
# Uncomment to disable graphical terminal (grub-pc only)
GRUB_TERMINAL=gfxterm
# The resolution used on graphical terminal
# note that you can use only modes which your graphic card supports via VBE
# you can see them in real GRUB with the command "vbeinfo"
GRUB_GFXMODE=auto
# Uncomment if you don’t want GRUB to pass "root=UUID=xxx" parameter to Linux
#GRUB_DISABLE_LINUX_UUID=true
# Uncomment to disable generation of recovery mode menu entries
#GRUB_DISABLE_LINUX_RECOVERY=true
# Uncomment to get a beep at grub start
#GRUB_INIT_TUNE="480 440 1"
GRUB_THEME=/boot/grub2/themes/openSUSE/theme.txt
GRUB_BACKGROUND=/boot/grub2/themes/openSUSE/background.png

Die dortigen Infos werden dann von einem der Scripts unter /etc/grub.d aufgegriffen, sobald YaST2 im Hintergrund
zusätzlich
grub2-mkconfig -o /boot/grub2/grub.cfg
ausführt, um die eigentliche grub2-Konfigurationsdatei unter /boot/grub2/grub.cfg erstellen zu lassen. Dort findet man die getroffenen Einstellungen letztlich natürlich auch wieder.

Bootet man nun neu, fährt das System dann schön im Textmodus hoch und man kann einen Blick auf die schnell vorbeiziehenden Meldungen von systemd und den gestarteten Applikationen zum Bootvorgang werfen.

——–
Drei ergänzende Hinweise

Hinweis 1:Grub 2
Nebenbei haben wir mal wieder gelernt, dass Grub2 relativ kompliziert – nämlich teils über die über die “/etc/default/grub”, teils über Script-Dateien – zu konfigurieren ist. Hierzu ein paar Links;
http://www.dedoimedo.com/computers/grub-2.html
http://doc.opensuse.org/documentation/html/openSUSE/opensuse-reference/grub2.html
http://manual.siduction.org/de/sys-admin-grub2-de.htm

Hinweis 2: Etwas Tipparbeit beim Umgang mit grub2 sparen
Übrigens (off topic):
Um beim Experimentieren mit Grub etwas Tipparbeit zu sparen und eine Ähnlichkeit mit (älteren) Debian-Derivaten herzustellen, kann man sich unter SuSE einen abgekürzten Befehl “update-grub” als Skript (an geeigneter Stelle im Suchpfad) hinterlegen:

#!/bin/sh
set -e
exec grub2-mkconfig -o /boot/grub2/grub.cfg “$@”

Wer sich über das “$@” wundert: grub2-mkconfig hat z.Z. zwar nur 3 Parameter, kann ja aber künftig noch mehr bekommen:

mysystem:~/bin # ./update-grub -v
grub2-mkconfig (GRUB2) 2.00
mysystem:~/bin # ./update-grub -h
Usage: grub2-mkconfig [OPTION]
Generate a grub config file
 
-o, –output=FILE output generated config to FILE [default=stdout]
-h, –help print this message and exit
-v, –version print the version information and exit
 
Report bugs to <bug-grub@gnu.org>.
mysystem:~/bin #

Hinweis 3: Kein graphischer Grub2-Bildschirm
Übrigens: Will man neben Plymouth auch den grafischen Grub2-Schirm loswerden, so muss man im oben dargestellten YaST2-Fenster den Haken bei der Option “use graphical console” entfernen. Dies führt dann zu einem Eintrag “GRUB_TERMINAL=console” in der “/etc/default/grub”.

Opensuse 12.2, systemd, 3ware 9650, Filesystem-Fehler

Ich habe auf einem System, das ich von Opensuse 12.1 auf Opensuse 12.2 upgegraded hatte, zweimal kurz hintereinander Probleme mit der Konsistenz des Root-Filesystems unter “ext4” bekommen.

Diese Schwierigkeiten kamen nach einigen größeren Update-Läufen, die ich nach dem Upgrade durchgeführt hatte.

Das Workstation-System beinhaltet einen LSI/3ware-Raid-Controller 9650SE mit einem Raid 10 Array. Das System hat sowohl unter Opensuse 11.4 als auch unter Opensuse 12.1 im Dauereinsatz gut und sehr performant funktioniert. Unter Opensuse 12.2 dagegen bereitet es nun leider Probleme nach Shutdowns mit PowerOff – die führen nämlich mindestens bei einer performance-orientierten Einstellung des Controllers zu Datenverlust und resultierenden Filesystem-Inkonsistenzen.

Interessanterweise konnte ich ähnliche Inkonsistenzen des Root-Filesystems trotz mehrer Anläufe und unterschiedlicher Einstellungen des Controllers nicht unter den auf dem PC immer noch vorhandenen Versionen Opensuse 11.4 und 12.1 provozieren. Das schließt RAM-Defekte praktisch aus. Man könnte nun noch auf einen Platten-Defekt in Sektoren, die die Root-Partition des Opensuse 12.2-Systems betreffen, als eigentliche Ursache tippen. Aber auch smartd zeigte keine Auffälligkeiten.

Die eine Frage ist also, wieso diese Probleme auf ein und demselben System hauptsächlich unter Opensuse 12.2 (vor allem nach umfangreichen SW-Updates) auftreten und nicht unter Opensuse 11.4 oder Opensuse 12.1.

Die andere Frage – und diese ist die für diesen Beitrag interessantere – ist, wie eigentlich systemd beim Booten mit einem inkonsistenten, korrumpierten Root-Filesystem umgeht.

Man muss sich ja selten genug mit dieser Situation auseinandersetzen – und fast hätte ich gerade wegen systemd nicht einmal gemerkt, dass ein gravierendes Problem vorlag ….

Früheres Verhalten von Opensuse bei defekten Root-Filesystemen unter System V

Man erinnere sich:

Unter System V stoppte der Bootprozess, wenn Opensuse 11.4 beispielsweise einen inkonsistenten Zustand des Filesystems entdeckte und wenn das dann automatisch gestartete “fsck” den Schaden nicht automatisch beheben wollte oder konnte. Der Admin wusste dann Bescheid, das System befand sich im Systemverwaltungs-Modus (Runlevel 1) und man konnte sich sofort um das Filesystem kümmern.

Das hatte u.a. den Vorteil, dass sich der Filesystem-Schaden in den vorgefundenen Grenzen hielt und nicht weiter durch Benutzung des fehlerhaften und inkonsistenten Systems verschlimmert wurde.

Aktuelles Verhalten von Opensuse 12.2 mit Systemd bei defekten Root-Filesystemen

Unter Opensuse 12.2 mit systemd ist die oben beschriebene, kluge Politik leider nicht mehr gegeben:

“fsck” (genauer e2fsck) wird zwar gestartet. Aber kommt “fsck” mit der Anzahl oder Qualität nicht klar, wird das fehlerhafte Root-Filesystem durch “systemd” nach kurzem Einblenden einer Warnung in die laufenden Startmeldungen gnadenlos gemounted und der Systemd-Bootvorgang setzt sich fort ! Ja – man mag es kaum glauben – mit einem korrumpierten Filesystem !

Das fand und finde ich nicht nur schockierend, sondern geradezu fahrlässig!

Denn man merkt das Ganze ggf. nur zufällig – nicht zuletzt wegen der hohen Geschwindigkeit von systemd. Bei angeschaltetem Plymouth sieht man u.U. gar nichts, wenn man nicht aufpasst. Zwar wechselt der Schirm beim Start von fsck zu einer Konsole mit Textmodus, aber danach geht es zügig weiter und man landet nach wenigen Sekunden im grafischen Modus – als ob nichts wäre.

Bei textorientiertem Startup ist es fast noch schwerer, das Problem mitzubekommen – die “fsck”-Warnung geht in
der Flut der schnell ablaufenden “systemd”-Meldungen zum Systemstart unter. Was für ein Sch….

Aber der Reihe nach!

Wann traten die Probleme auf?

Die Probleme traten bislang ausnahmslos nach umfangreichen mit YaST2 durchgeführten SW-Updates (KDE, Kernel, … ) auf. Und zwar dann, wenn ich nach den Updates nicht sofort einen Systemneustart durchgeführt hatte, sondern mehrere Stunden weiterarbeitete und danach einen Shutdown mit PowerOff machte.

Auf einem ähnlichen System, auf dem OS 12.2 neu installiert wurde, traten solche Probleme bislang nicht auf. Auch ein anderes upgegradetes System zeigt das Verhalten (noch) nicht. Die anderen Systeme befinden sich jedoch noch auf einem anderen SW-Update-Level.

Allerdings weisen diese anderen Systeme bzgl. des Write-Caches des Raid-Controllers auch andere Einstellungen auf:

Der Parameter “StorSave” des 9650-Raid-Controllers steht im Fall der anderen Systemen auf “Balance” – im Fall der problematischen Systeme jedoch auf “Performance”.

Der Controller der problembehafteten Systeme ist ferner nicht batteriegepuffert. Vielleicht passieren im Rahmen des von systemd gesteuerten Shutdowns bei “performanter” Nutzung des Schreibcaches ja unangenehme Dinge. Vielleicht wird der Puffer des LSI/3ware-Controllers beim Shutdown nicht rechtzeitig geleert, vielleicht wird kein “sync” mehr aufgerufen – was weiß ich.

Man muss die Sache, die erst mit Opensuse 12.2 aufgetreten ist, jedenfalls beobachten:

Das Problem trat ausschließlich auf dem Root-Filesystem auf. Alle anderen gemounteten Filesysteme (alle vom Typ “ext4”) des gleichen Raid 10 Arrays – auch solche für virtuelle Maschinen – meldeten auch bei regelmäßig erzwungenen fsck-Vorgängen keinerlei Problem. Das ist deswegen interessant, weil das Root-Filesystem vor dem Power Off als letztes ausgehängt wird.

Ein Verify des Raid-Arrays zeigt nach einem Auftreten von Fehlern im Root-Filesystem jedenfalls auch aufgetretene Parity-Fehler an. Das spricht ein wenig dafür, dass der Shutdown unter “systemd” ggf. zu rasch erfolgt. Komisch nur, dass das auf dem gleichen System unter Opensuse 12.1 nicht geschieht ! Eine Problem zwischen Treiber und Kernel 3.4 ???

Ich habe den LSI/3ware-Controller nun einige Wochen im “Balanced” Modus des Schreibcaches betrieben. Es trat bis heute kein weiteres Problem mit dem Root-Filesystem auf.

Noch fehlt allerdings noch die Gegenprobe, um auszuschließen, dass das Problem nicht einfach durch problematische Update-Pakete oder Update-Vorgänge erzeugt wurde. Ich hatte dafür wegen anderer Themen bislang einfach keine Zeit.

Wegen der Raid-Controller-Einstellungen möchte ich das Ganze bislang also lediglich als Beobachtung ansehen, deren Ursache unklar ist. Ich werde den Raid-Controller nun wieder auf “Performance” stellen und die Sachlage weiter verfolgen.

Nachtrag 19.01.2013:

Nach vielen Tests muss ich leider feststellen: Bei einem Shutdown mit PowerOff kommt es unter OS 12.2 und systemd mit relativ hoher Wahrscheinlichkeit zu Datenverlusten und inkonsistentem Root-Filesystem, wenn der 3Ware-Controller bzgl. der Schreibpufferung (Parameter “Storsave”) auf “Performance” eingestellt ist.

Wie äußerte sich die Inkonsistenz des Root-Filesystems?

Falsche Inode-Verweise, vor allem etliche verwaiste Inodes und falsche Referenz-Counter. Interessant ist, dass die Dateien, die im Rahmen der letzten “fsck”-Bereinigung im Verzeichnis “lost&found” auftauchten, alle mit YaST2 selbst zu tun
hatten.

Die Schäden waren insgesamt jedenfalls von einer solchen Qualität, dass das automatisch gestartete “fsck” damit nicht mehr ohne User-Eingriffe klarkommen wollte. In den von mir beobachteten 2 Fällen tauchte deshalb der Hinweis auf ein manuell durchzuführendes “e2fsck” auf (s.u.) !

Was macht Systemd beim Starten mit Inkonsistenzen im Root-Filesystem ?

Tja, in meinen Fällen bemerkte systemd beim Starten zwar die Fehler im Filesystem.
fsck wurde dann gestartet. Aber in den Fällen, in denen fsck nicht mehr ohne Userunterstützung mit den Fehlern klarkommen wollte, wurde das kaputte Filesystem – wie gesagt – gnadenlos gemountet.

Dies geschah in meinem Fall an vier Tagen hintereinander (2.11. bis 5.11.), weil ich von den Fehlern – dank des “fantastisch” schnellen systemd – im Entwicklungsstress nichts mitbekommen habe. Erstaunlich, dass ich überhaupt arbeiten konnte.

Nachfolgend ein Auszug aus “/var/log/messages”:

Nov 2 08:49:25 mux kernel: [ 36.774057] EXT4-fs (sda6): warning: mounting fs with errors, running e2fsck is recommended
Nov 2 08:49:25 mux kernel: [ 36.774270] EXT4-fs (sda6): re-mounted. Opts: acl,user_xattr
 
Nov 2 08:53:58 mux kernel: [ 325.684513] EXT4-fs (sda6): error count: 1896
Nov 2 08:53:58 mux kernel: [ 325.684518] EXT4-fs (sda6): initial error at 1351765087: ext4_lookup:1045: inode 922772
Nov 2 08:53:58 mux kernel: [ 325.684523] EXT4-fs (sda6): last error at 1351786094: ext4_lookup:1045: inode 922772
 
Nov 3 09:41:24 mux kernel: [ 30.059173] bootsplash: status on console 0 changed to on
Nov 3 09:41:24 mux kernel: [ 30.849236] EXT4-fs (sda6): warning: mounting fs with errors, running e2fsck is recommended
Nov 3 09:41:24 mux kernel: [ 30.855514] EXT4-fs (sda6): re-mounted. Opts: acl,user_xattr
 
Nov 3 09:46:00 mux kernel: [ 322.602348] EXT4-fs (sda6): error count: 1896
Nov 3 09:46:00 mux kernel: [ 322.602353] EXT4-fs (sda6): initial error at 1351765087: ext4_lookup:1045: inode 922772
Nov 3 09:46:00 mux kernel: [ 322.602357] EXT4-fs (sda6): last error at 1351786094: ext4_lookup:1045: inode 922772
 
Nov 4 08:34:31 mux kernel: [ 34.497854] bootsplash: status on console 0 changed to on
Nov 4 08:34:31 mux kernel: [ 35.111163] EXT4-fs (sda6): warning: mounting fs with errors, running e2fsck is recommended
Nov 4 08:34:31 mux kernel: [ 35.111397] EXT4-fs (sda6): re-mounted. Opts: acl,user_xattr
 
Nov 4 08:39:07 mux kernel: [ 326.695619] EXT4-fs (sda6): error count: 1898
Nov 4 08:39:07 mux kernel: [ 326.695621] EXT4-fs (sda6): initial error at 1351765087: ext4_lookup:1045: inode 922772
Nov 4 08:39:07 mux kernel: [ 326.695623] EXT4-fs (sda6): last error at 1352014560: ext4_lookup:1045: inode 922286
 
Nov 5 09:37:30 mux kernel: bootsplash: status on console 0 changed to on
Nov 5 09:37:31 mux kernel: EXT4-fs (sda6): warning: mounting fs with errors, running e2fsck is recommended
Nov 5 09:37:31 mux kernel: EXT4-fs (sda6): re-mounted. Opts: acl,user_xattr
 
Nov 5 09:42:22 mux kernel: EXT4-fs (sda6): error count: 2368
Nov 5 09:42:22 mux kernel: EXT4-fs (sda6): initial error at 1351765087: ext4_lookup:1045: inode 922772
Nov 5 09:42:22 mux kernel: EXT4-fs (sda6): last error at 1352067644: ext4_lookup:1045: inode 922721

Hübsch, nicht? Seitdem lasse ich “/var/log/messages” nach jedem Bootvorgang auf entsprechende Schlüsselwörter scannen.

Systemd im aktuellen Zustand ist dem Admin jedenfalls nicht dabei behilflich, solche katastrophalen Entwicklungen mit korrumpierten Filesystemen zu vermeiden.

Aber: ich will mich ja nicht aufregen …..

Schadensbehebung – trotz Chaos mit dem Rescue Target

Nun versuche man mal, auf einem von “systemd” gesteuerten Opensuse-System, das Rescue-Target zu erreichen, um “fsck” – wie empfohlen – manuell ablaufen zu lassen. Ich habe das interessehalber auf verschiedenen Systemen in verschiedenem Upgrade-Zuständen getestet.

Ergebnis: Es war unter Opensuse 12.1 und zeitweise (!) auch unter Opensuse 12.2 (vor allem im Originalzustand) fast abenteuerlich, das “isolated rescue target” zu erreichen:

  • Das lt. SuSE angeblich noch funktionierende “init 1” führte auf mehreren Systemen zu einem Herunterfahren des Systems mit unmittelbar danach – und ohne oder gar trotz Userinteraktion – ablaufendem Restart in das “default target” – also den grafischen Modus.
  • “systemctl isolate rescue.target” zeigte – je nach Update-Zustand des Opensuse 12.1 oder 12.2-Systems das gleiche fehlerhafte Verhalten wie “init 1” oder aber ein unterschiedliches Verhalten – je nachdem, ob es von Konsole “tty2” oder “tty1” gestartet wurde.
  • Zwischenzeitlich funktionierte dann lediglich “systemctl rescue” halbwegs wie erwartet. Einen Wechsel der Konsole musste man dabei aber vermeiden. Das Verhalten von systemd war in jedem Fall schwierig – oft verlor man auch den Prompt auf der Konsole, von der der Shutdown gestartet wurde. Überhaupt mutet es merkwürdig an, dass im “Rescue Modus” mehrere Konsolen ansprechbar sind.
  • Ein mehrfaches Hintereinanderausführen des Herunterfahrens in den Rescue Modus mit anschließendem Hochfahren in den Default-Modus mit Konsol-Wechsel verhielt sich z.T. unberechenbar.

Wohlgemerkt: Ich spreche hier von Tests auf Systemen, die (außer systemd) keine Defekte beherbergen.

Inzwischen – also auf dem aktuellen Update-Niveau des Opensuse 12.2-Systems – haben sich die Dinge aber deutlich verbessert. Nun funktionieren

“systemctl isolate rescue.target”

und

“systemctl rescue”

im wesentlichen wie erwartet. Man habe Geduld – die Meldung zum Eingeben des Passwortes und der Prompt erscheinen manchmal zeitversetzt.

Bevor nun aber möglicherweise Ekstase bei den systemd-Anhängern aufkommt – es gibt immer noch gravierende Probleme mit der systemd-Logik:

  • Ein anschließendes “systemctl default” führt zwar zum Hochfahren in den graphischen Modus – auf der ursprünglichen Konsole mag sich unter Opensuse 12.2 aber der Prompt nicht mehr einstellen.
  • Ferner läuft der “agetty”-Prozess nach “systemctl rescue” und einem anschließenden “systemctl default” unter Opensuse 12.2 regelmäßig Amok und verbraucht 90% der CPU-Zeit eines Prozessor-Cores. Man muss “agetty” tatsächlich abschießen, um dem Herr zu werden.

So ist das halt, wenn ein einziges Super-Programm wie “systemd” alles und jedes im System unter Kontrolle behalten muss. Die Tatsache, dass es mit mehreren Konsolen umgehen muss, ist von der neuen Superlösung wohl noch nicht richtig verdaut worden.

Aber ich rege mich nicht auf ….. auch vor den letzten Systemupdates kam man (nach mehreren Konsole-Wechseln und unermüdlichem Probieren) meist doch irgendwie in einen Zustand, der dem früheren “init 1 ” irgendwie ähnelte.

Leider, leider hieß das aber noch lange nicht, dass dann unter “systemd” immer ein

“mount -o remount,ro /dev/rootdevice

für einen manuellen fsck-Lauf möglich gewesen wäre.

Das ging nur in 50 % der von mir untersuchten Fälle. Bei den Systemen mit bereits vorhandenem Filesystem-Fehler gar nicht. Vielleicht auch bedingt durch die sich inzwischen vergrößerten Probleme mit dem inkonsistenten Filesystem.

Ich musste
jedenfalls in zwei Fällen auf eine CD mit “Rescue-System” ausweichen und von dort meine Root-Partition auf der Platte reparieren.

Seitdem habe ich wieder Ruhe. Was immer die Ursache des defekten Filesystems war – der eigentliche Skandal ist der Umgang von systemd mit einem defekten Filesystem beim Booten !

Opensuse 12.2 – mysql, logrotate error

Vor einigen Tagen habe ich den Mysql-Community-Server über das entsprechende Opensuse “Database”-Repository upgedated. Seitdem erhalte ich beim Systemstart Meldungen der Art

Nov 15 18:30:04 myserver logrotate: ALERT exited abnormally with [1]
Nov 15 18:30:04 myserver logrotate: #007/usr/bin/mysqladmin: refresh failed; error: ‘Unknown error’
Nov 15 18:30:04 myserver logrotate: /logrotate.d/mysql failed, probably because
Nov 15 18:30:04 myserver logrotate: the root acount is protected by password.
Nov 15 18:30:04 myserver logrotate: See comments in /logrotate.d/mysql on how to fix this
Nov 15 18:30:04 myserver logrotate: error: error running non-shared postrotate script for /var/log/mysql/mysqld.log of ‘/var/log/mysql/mysqld.log ‘

Diese Meldung erhalte ich, obwohl es unter dem “/root”-Verzeichnis die notwendige “/root/.my.cnf”-Datei mit den Account-/Passwort-Daten für den MySQL-Admin (MySQL root-Account) gibt. Die Fehlermeldung führt einen daher in die Irre.

Der Fehler liegt wohl eher im Startup-Skript “/etc/init.d/mysql” für den MySQL-Server.

Das habe nicht ich herausgefunden sondern Archie Cobbs, der das bei Novell als Bug eingestellt hat.

Siehe :
http://lists.opensuse.org/opensuse-bugs/2012-11/msg01186.html
und
https://bugzilla.novell.com/show_bug.cgi?id=789263

Dort findet man auch den notwendigen Hinweis, wie man das Startup-Skript abändern muss, damit Logrotate wieder funktioniert:

The bug is in the line “chmod 660 $log_dir”.
That should be “chmod 770 $log_dir”.

Scheint rechtemäßig logisch zu sein und hat bei mir funktioniert.