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’è e allora perché non conoscerlo e iniziarlo a sfruttare al pieno delle sue potenzionalità?