Monat: Februar 2019

Kürzlich wurde auf einem unserer AIX Systeme kein Cron-Job mehr gestartet. Es gab keinen Eintrag im Error Report und auch per Syslog konnte kein Hinweis auf das Problem gefunden werden. Im Log des cron-Daemon fanden sich allerdings jede Menge Meldungen:

# cat /var/adm/cron/log
...
! c queue max run limit reached Sat Feb 23 08:49:00 2019
! rescheduling a cron job Sat Feb 23 08:49:00 2019
...

Unter AIX ist die Anzahl der aktiven Cron-Jobs standardmäßig auf maximal 100 gesetzt. Offensichtlich war diese Anzahl auf unserem System erreicht worden. Neue Einträge werden dann per Default 60 Sekunden später ausgeführt. Beides kann über die Datei /var/adm/cron/queuedefs konfiguriert werden. Der Wert 100 ist allerdings schon recht hoch und ein Erreichen des Wertes deutet auf ein Problem hin.

Die PID des cron-Daemon lässt sich schnell herausfinden:

$ ps -ef|grep cron
    root  6684924        1   0   Sep 26      -  8:03 /usr/sbin/cron
$

Die aktuell aktiven Cron-Jobs laufen als Sohn-Prozesse des cron. Mit der Option „-T“ des ps-Kommandos lassen wir uns diese auflisten:

$ ps -T 6684924
      PID    TTY  TIME CMD
  6684924      -  8:03 cron
  3276876      -  0:00    |\--perl
  9961588      -  0:00    |    \--mount
 12714002      -  0:07    |        \--nfsmnthelp
  3604516      -  0:00    |\--perl
 20185130      -  0:00    |    \--mount
 10158264      -  0:35    |        \--nfsmnthelp
  4587542      -  0:00    |\--perl
...

Es fällt sofort auf, das sich die Zeilen immer wieder wiederholen, d.h. ein Perl-Programm wurde per cron immer wieder gestartet, dieses hat versucht ein Filesystem per NFS zu mounten, was aber nicht funktioniert hat (keine Antwort vom NFS-Server) und das Perl-Skript hängt. Da das Skript immer wieder neu gestartet wurde, gab es dann ab irgendeinem Zeitpunkt 100 aktive Cron-Jobs und von diesem Moment an wurden dann keine weiteren Cron-Jobs mehr gestartet. Wir zählen kurz die aktiven Perl-Prozesse:

$ ps -T 6684924 |grep perl |wc -l
     100
$

Es sind genau 100 Perl-Prozesse, die von cron gestartet wurden. Wir beenden einige der hängenden Perl-Prozesse:

# kill 3276876 3604516  4587542
#

Ein Blick ans Ende der Logdatei von cron zeigt das Jobs beendet wurden, und nach kurzer Zeit taucht dann auch schon der erste neu gestartete Cron-Job auf:

# tail –f /var/adm/cron/log
…
Cron Job with pid: 3276876 Failed
Cron Job with pid: 3604516  Failed
Cron Job with pid: 4587542Failed
mqm       : CMD ( /appdata/mqm/admin/bin/checks/checkXmitMonitoring.sh >>/appdata/mqm/tracks/logs/scheduler/checkXmitMonitoring.fatal 2>&1 ) : PID ( 28442840 ) : Mon Feb 25 10:34:00 2019
…

Wir beenden auch die übrigen hängenden Prozesse und restarten den cron-Daemon sicherheitshalber, indem wir ihn einfach beenden:

# kill 6684924
#

Der cron-Daemon wird Dank eines /etc/inittab-Eintrags automatisch neu gestartet:

# lsitab cron
cron:23456789:respawn:/usr/sbin/cron
#

Nachdem cron wieder arbeitet, sollte das Perl-Skript untersucht werden, welches letztlich zum Hängen von cron geführt hat. Bei regelmäßig per cron gestarteten Skripten empfiehlt sich eine Überprüfung, ob der Job eventuell noch oder schon läuft.

Es gib verschiedene Möglichkeiten unter AIX fehlende Home-Verzeichnisse beim Login automatisch anlegen zu lassen. Dies ist insbesondere nützlich, wenn die Benutzer-Accounts über LDAP oder einen anderen Namensdienst verwaltet werden und nicht lokal angelegt werden. Wird ein Benutzer neu im LDAP angelegt, hat er zunächst kein Home-Verzeichnis auf dem AIX LDAP-Client:

$ ssh new_user@aix01
...
Could not chdir to home directory /home/new_user: No such file or directory
$ pwd
/
$ exit
$

Die wohl einfachste Möglichkeit das Home-Verzeichnis beim Login automatisch anzulegen, ist das Attribute mkhomeatlogin in der Datei /etc/security/login.cfg. Der Default für dieses Attribut ist „false“, falls es nicht gesetzt ist:

# lssec -f /etc/security/login.cfg -s usw -a mkhomeatlogin
usw mkhomeatlogin=
# 

Das Attribut lässt sich mit dem Kommando chsec auf den Wert true setzen:

# chsec -f /etc/security/login.cfg -s usw -a mkhomeatlogin=true
# lssec -f /etc/security/login.cfg -s usw -a mkhomeatlogin
usw mkhomeatlogin=true
#

Wir probieren den Login erneut aus:

$ ssh new_user@aix01
...
$ pwd
/home/new_user
$

Es wurde ein neues Home-Verzeichnis für den Benutzer angelegt.

Auf vielen AIX Systemen wird aktuell noch SDDPCM als Multipathing Lösung eingesetzt. Allerdings wird SDDPCM auf POWER 9 Hardware von IBM nicht mehr unterstützt.

Im folgenden soll daher die Migration von SDDPCM nach AIX PCM gezeigt werden. Auf unserem Beispielsystem haben wir die folgenden Physical Volumes:

$ lspv
hdisk0          00abcdefabcde000                    datavg          active     
hdisk1          00abcdefabcde001                    datavg          active     
hdisk2          none                                None                       
hdisk3          00abcdefabcde003                    altinst_rootvg             
hdisk4          00abcdefabcde004                    rootvg          active     
$

Bei den Physical Volumes handelt es sich um Platten, die über einen SVC zur Verfügung gestellt werden:

$ lsdev -l hdisk0 -F uniquetype
disk/fcp/2145
$

Als Path Control Module (PCM) wird SDDPCM verwendet:

$ lsattr -El hdisk0 -a PCM -F value
PCM/friend/sddpcm
$

Dies sieht man auch, wenn man sich die Liste der Kernel Extensions anschaut:

$ genkex | grep pcm
f1000000c012a000    af000 /usr/lib/drivers/sddpcmke
$

Welcher PCM Treiber für welche Disk Typen verwendet wird, lässt sich leicht mit dem Kommando „manage_disk_drivers“ sehen:

$ manage_disk_drivers -l
Device              Present Driver        Driver Options    
2810XIV             AIX_AAPCM             AIX_AAPCM,AIX_non_MPIO
DS4100              AIX_SDDAPPCM          AIX_APPCM,AIX_SDDAPPCM
DS4200              AIX_SDDAPPCM          AIX_APPCM,AIX_SDDAPPCM
DS4300              AIX_SDDAPPCM          AIX_APPCM,AIX_SDDAPPCM
DS4500              AIX_SDDAPPCM          AIX_APPCM,AIX_SDDAPPCM
DS4700              AIX_SDDAPPCM          AIX_APPCM,AIX_SDDAPPCM
DS4800              AIX_SDDAPPCM          AIX_APPCM,AIX_SDDAPPCM
DS3950              AIX_SDDAPPCM          AIX_APPCM,AIX_SDDAPPCM
DS5020              AIX_SDDAPPCM          AIX_APPCM,AIX_SDDAPPCM
DCS3700             AIX_APPCM             AIX_APPCM
DCS3860             AIX_APPCM             AIX_APPCM
DS5100/DS5300       AIX_SDDAPPCM          AIX_APPCM,AIX_SDDAPPCM
DS3500              AIX_APPCM             AIX_APPCM
XIVCTRL             MPIO_XIVCTRL          MPIO_XIVCTRL,nonMPIO_XIVCTRL
2107DS8K            NO_OVERRIDE           AIX_AAPCM,AIX_non_MPIO,NO_OVERRIDE
IBMFlash            NO_OVERRIDE           AIX_AAPCM,AIX_non_MPIO,NO_OVERRIDE
IBMSVC              NO_OVERRIDE           AIX_AAPCM,AIX_non_MPIO,NO_OVERRIDE
$

In unserem Falle, SVC Platten, ist die letzte Zeile relevant (IBMSVC). Als aktueller PCM Treiber ist hier NO_OVERRIDE gelistet, mögliche andere Treiber sind AIX_AAPCM (AIX PCM für active/active und ALUA Systeme) und AIX_non_MPIO (Platten ohne Multi-Pathing betreiben). Der Wert NO_OVERRIDE bedeutet, das wenn kein Multipathing-Treiber explizit angegeben wird, nach Möglichkeit ein Multipathing-Treiber verwendet wird (falls vorhanden), ansonsten wird kein Multipathing-Treiber verwendet. Steht mehr als ein Multipathing-Treiber zur Verfügung (bei uns AIX PCM und SDDPCM, dann hat SDDPCM Priorität).

In einem nachfolgenden Blog-Eintrag werden wir die möglichen Werte noch einmal genauer anschauen, sowie die Stelle in AIX, an der die Auswahl festgehalten wird.

Bevor wir jetzt den Treiber für IBMSVC Platten ändern (hierzu ist ein Reboot notwendig), schauen wir uns noch die Attribute unsere Platten an, hier exemplarisch für die hdisk0:

$ lsattr -El hdisk0
PCM             PCM/friend/sddpcm                                   PCM                                     True
...
algorithm       load_balance                                        Algorithm                               True+
...
queue_depth     120                                                 Queue DEPTH                             True+
...
reserve_policy  no_reserve                                          Reserve Policy                          True+
...
$

Durch Ändern des Treibers gehen die Werte einiger gesetzter Attribute verloren, bzw. werden durch neue default Werte des neuen Treibers ersetzt. Dies gilt insbesondere für die queue_depth (hier: 120), die reserve_policy (hier: no_reserve) und die Load-Balancing-Policy (algorithm). Die aktuellen Werte sollte man notieren, um dann nach der Umstellung auf den AIX PCM Treiber diese dann entsprechend anzupassen.

Das Wechseln auf AIX PCM kann mit dem Kommando „manage_disk_drivers“ durchgeführt werden. Hierzu wird dem Kommando der Disk-Typ (hier IBMSVC) mit der Option „-d“ und der gewünschte Treiber (hier AIX_AAPCM für den AIX PCM Treiber) mit der Option „-o“ mitgegeben:

# manage_disk_drivers -d IBMSVC -o AIX_AAPCM
********************** ATTENTION *************************
  For the change to take effect the system must be rebooted
#

Die geänderte Konfiguration lässt sich unmittelbar mit „manage_disk_drivers -l“ auflisten:

$ manage_disk_drivers -l
Device              Present Driver        Driver Options    
...
IBMSVC              AIX_AAPCM             AIX_AAPCM,AIX_non_MPIO,NO_OVERRIDE
$

Für die Durchführung der Änderung muss das System nun rebootet werden:

# shutdown -r now

SHUTDOWN PROGRAM
Thu Feb  7 09:43:38 CET 2019
...

Wir führen die 3 Kommandos vom Anfang noch einmal aus (lspv, lsdev und lsattr):

$ lspv
hdisk0          00abcdefabcde000                    datavg          active     
hdisk1          00abcdefabcde001                    datavg          active     
hdisk2          none                                None                       
hdisk3          00abcdefabcde003                    altinst_rootvg             
hdisk4          00abcdefabcde004                    rootvg          active     
$

Die Physical Volumes sind unverändert.

$ lsdev -l hdisk0 -F uniquetype
disk/fcp/mpioosdisk
$

Der Typ der Platten hat sich geändert von disk/fcp/2145 auf disk/fcp/mpioosdisk. Dies deutet schon an, das sich der Multipathing-Treiber geändert hat.

$ lsattr -El hdisk0 -a PCM -F value
PCM/friend/fcpother
$

Das Path Control Module (PCM) hat sich ebenfalls geändert. Der Typ ist nicht mehr sddpcm sondern fcpother. Das schaut erst einmal nicht direkt nach AIX PCM aus. Ein Blick auf den zugehörigen Treiber zeigt aber sofort das hier AIX PCM in Verwendung ist:

$ lsdev -P -c PCM -s friend -t fcpother -F DvDr
aixdiskpcmke
$

Die zugehörige Kernel Extension aixdiskpcmke ist auch aktuell geladen und in Verwendung:

$ genkex | grep pcm
         73e2000    57000 /usr/lib/drivers/aixdiskpcmke
$

Schauen wir uns nun, wieder exemplarisch für hdisk0, die Attribute an. Wir erwarten ja hier geänderte Werte für einige Attribute:

$ lsattr -El hdisk0
PCM             PCM/friend/fcpother                                 Path Control Module              False
...
algorithm       fail_over                                           Algorithm                        True+
...
queue_depth     20                                                  Queue DEPTH                      True+
...
reserve_policy  single_path                                         Reserve Policy                   True+
...
$

Der Wert 120 für die queue_depth ist verloren gegangen und wurde durch den default Wert 20 ersetzt. Die reserve_policy hat sich auf single_path geändert und der Load-Balancing Algorithmus ist nun fail_over, d.h. es wird immer nur ein Pfad verwendet.

Wir ändern die Einstellungen auf eine Konfiguration die der Ausgangssituation entspricht:

# chdev -P -l hdisk0 -a algorithm=shortest_queue -a queue_depth=120 -a reserve_policy=no_reserve
hdisk0 changed
#

Da das Physical Volume in Benutzung ist, kann die Einstellung nur in der ODM geändert werden und es ist ein weiterer Reboot notwendig.

Nachdem alle Platten über die ODM umkonfiguriert worden sind, muss das System ein zweites Mal rebootet werden:

# shutdown -r now

SHUTDOWN PROGRAM
Thu Feb  6 20:07:12 CET 2019
...

Nach dem Reboot kann SDDPCM dann deinstalliert werden:

# installp -u devices.fcp.disk.ibm.mpio.rte devices.sddpcm.72.rte
+-----------------------------------------------------------------------------+
                    Pre-deinstall Verification...
+-----------------------------------------------------------------------------+
Verifying selections...done
Verifying requisites...done
Results...

SUCCESSES
...
0503-292 This update will not fully take effect until after a
        system reboot.

    * * *  A T T E N T I O N  * * *
    System boot image has been updated. You should reboot the
    system as soon as possible to properly integrate the changes
    and to avoid disruption of current functionality.

installp:  bosboot process completed.
+-----------------------------------------------------------------------------+
                                Summaries:
+-----------------------------------------------------------------------------+

Installation Summary
--------------------
Name                        Level           Part        Event       Result
-------------------------------------------------------------------------------
devices.sddpcm.72.rte       2.7.1.1         ROOT        DEINSTALL   SUCCESS   
devices.sddpcm.72.rte       2.7.1.1         USR         DEINSTALL   SUCCESS   
devices.fcp.disk.ibm.mpio.r 1.0.0.25        USR         DEINSTALL   SUCCESS   
#

Das SDDPCM Fileset, sowie das zugehörige Host-Attachment Fileset, konnten erfolgreich deinstalliert werden.

Da der SDDPCM-Treiber nicht geladen war, und sich damit auch keine Änderungen am Kernel ergeben haben, sollte eigentlich ein weiterer Reboot nicht notwendig sein. Da allerdings ausdrücklich auf einen schnellen Reboot hingewiesen wird, und es auch eine gute Idee ist mit der finalen Konfiguration einen Reboot-Test zu machen, rebooten wir das System ein drittes und letztes Mal:

# shutdown -r now

SHUTDOWN PROGRAM
Thu Feb  6 20:17:21 CET 2019
...

Nach dem Reboot kontrollieren wir noch einmal die Platten-Attribute:

$ lsattr -El hdisk0
PCM             PCM/friend/fcpother                                 Path Control Module              False
...
algorithm       shortest_queue                                      Algorithm                        True+
...
queue_depth     120                                                 Queue DEPTH                      True+
...
reserve_policy  no_reserve                                          Reserve Policy                   True+
...
$

Das System verwendet nun den AIX PCM Treiber für Multipathing:

$ manage_disk_drivers -l
Device              Present Driver        Driver Options    
...
IBMSVC              AIX_AAPCM             AIX_AAPCM,AIX_non_MPIO,NO_OVERRIDE
$

Die Migration von SDDPCM zu AIX PCM ist also in der Durchführung ziemlich einfach.