Tsm Scheduler Client & Systemd

Per chi fosse interessato a far girare sotto le moderne distribuzioni, che utilizzano systemd come gestore di avvio dei processi di sistema, lo scheduler del TSM (Tivoli Storage Manager), qui di seguito trovate lo Unit da creare che avvierà tale scheduler e lo riavvierà qualora morisse, ipotesi tutt’altro che rara.

Unit

Per prima cosa va creato lo unit file sotto la directory /etc/systemd/system :

[Unit]
Description=Dsm Scheduler
After=syslog.target network.target

[Service]
Type=forking
PIDFile=/var/run/dsmsched.pid
ExecStart=/usr/local/sbin/dsmsched.sh
Restart=always

[Install]
WantedBy=multi-user.target

dove diamo una descrizione (Description) e indichiamo dopo quali servizi deve partire (After). Informiamo Systemd che lo script (perché di uno script si tratta) si chiuderà subito, qual’è il PID che deve monitorare, lo script da lanciare e che va riavviato in caso muoia. Inoltre gli indichiamo pure in quale target va installato.

Io questo file l’ho chiamato dsmsched.service.

Script

Dobbiamo creare quindi uno script che ci lanci lo scheduler vero e proprio dato che quest’ultimo, di suo, non crea il PID:

#!/bin/sh
nohup dsmc sched 2>&1 > /dev/null &
PID=$(ps -ef | grep “dsmc sched” | grep -v “grep” | awk {‘print $2’});
echo $PID > /var/run/dsmsched.pid

dove nel primo rigo (saltando ovviamente il bin/sh) lanciamo lo scheduler come normalmente faremmo da inittab (o da dove l’abbiate mai lanciato), nel secondo ricaviamo il PID interrogando i processi attivi e conseguentemente lo scriviamo nel file delegato a contenerlo.

Questo file io l’ho nominato dsmsched.sh e come avrete già visto nel file unit precedente, l’ho posizionato sotto /usr/local/sbin

Completiamo

A questo punto non ci resta che rendere eseguibile lo script:

:~# chmod +x /usr/local/sbin/dsmsched.sh

e far caricare il nuovo file unit a systemd, abilitarlo per l’avvio e naturalmente avviarlo:

:~# systemctl load dsmsched.service
:~# systemctl enable dsmsched.service
:~# systemctl start dsmsched.service

se tutto è andato bene al comando systemctl status dovremmo avere un output simile a questo:

:~# systemctl status dsmsched.service
dsmsched.service – Dsm Scheduler
Loaded: loaded (/etc/systemd/system/dsmsched.service; enabled)
Active: active (running) since Thu, 29 Nov 2012 16:02:45 +0100; 22h ago
Main PID: 1505 (dsmc)
CGroup: name=systemd:/system/dsmsched.service
└ 1505 dsmc sched

se così non è, perché ad esempio quando ne avete effettuato lo start, molto probabilmente c’è qualche errore all’avvio dello scheduler stesso, quindi vi consiglio di eseguire magari lo script dsmsched.sh da shell e verificare i messaggi che ritorna in output (se non ne da, togliete la redirezione a /dev/null)

Considerazioni finali

Systemd è stato oramai adottato dalle maggiori distribuzioni che puntano sull’innovazione (no debian non ne fa, è debian) (si, neanche slackware..). E’ multithread, sfrutta i cgroups, è veloce all’avvio e un fulmine allo spegnimento. Riavvia i servizi da solo se istruito per farlo e fa anche molto altro, come avviare sottoprocessi, monitorare gli stessi, inviarci una mail, ect.

C’è perché non conoscerlo e iniziarlo a sfruttare al pieno delle sue potenzionalità?

Una risposta a “Tsm Scheduler Client & Systemd”

  1. Thank you for this info!
    Strangely there are not many online resources showing how to use systemd to autostart the tsm scheduler.
    I had an issue though, seems like systemd is launching the script as a normal user and dsm throws an permission error that it cannot write to dsmerror.log.
    The fix for me was to change the location of dsmerror.log and modify permissions on it, as from this site:
    http://www-01.ibm.com/support/docview.wss?uid=swg21633869
    Now it starts dmsc sched ok after a reboot.
    rhel 7 and tsm client 7.1.2
    Thanks!
    Alexander

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *