Far partire automaticamente una applicazione in Suse

Come far partire automaticamente una applicazione in Suse?

Ci sono vecchi e nuovi sistemi e addirittura deprecati ovvero che non si devono usare più.

Uso parte della guide di Linuxaria e Archlinux che ringrazio di cuore.

Vediamoli

Cron e at

La cosa migliore per eseguire un programma automaticamente quando si vuole è usare questi comandi che dispongono addirittura di un calendario per eseguirli.

-AT

At è un vecchio comando UNIX deprecato in Linux (ma non BSD, usato ma deprecato anche in Windows) quindi se avete qualcosa in at (ma anche atq, atrm, batch[]) vedete di trasformarlo velocemente nel comando cron o altri.

Una guida su at e qui (della Microsoft) e una UNIX qui. Potete anche usare la guida MAN.

-Cron & crontab

Cron è un comando più evoluto (nella precisione crontab) ed è anche un demone (cron, servizio di basso livello) per eseguire applicazioni automaticamente, però è già preventivato che anche questo comando passerà deprecato quando scomparirà at in favore di systemd.service ovvero un proprio servizio di gestione.

Però questo avverrà tra molto tempo dato che systemd.service non è ancora completato anche se già funzionante (devono espanderlo) e quindi potete usarlo tranquillamente.

Dato che cron è un demone controllate prima che sia in esecuzione nella lista de servizi, altrimenti non funziona. (yast2->servizi)

Come usare questo comando che prende il nome dalla divinità greca del Dio del tempo e padre degli Dei?

Meglio usare le tante GUI (programmi grafici) per modificarlo come gnome-schedule ma è possibile usare la semplice tastiera!

-Sintassi ed utilizzo del Crontab

La configurazione di crontab è in un file di testo con un formato particolare, per modificarlo andare nel terminale e scrivete:

crontab -e

ATTENZIONE : Viene richiamato l’editor VI (o VIM) dunque studiatevi VI prima di farlo.

Nota: Altri comandi QUI

Modificare il file come si desidera e salvarlo.
È possibile controllare il crontab per l’utente corrente con il comando:

crontab -l

Questo è il formato utilzzato generalmente in crontab:

MIN ORE GDM MESE GDS CMD

Campo	Descrizione	Valori Permessi
MIN	Minuti	0 a 59
ORE	Ore	0 a 23
GDM	Giorno Del Mese	0 a 31
MESE	Mese	1 a 12
GDS	Giorno della Settimana	0 a 6
CMD	Comando	Il comando da essere eseguito

Un campo può essere un asterisco (*), che significa per “dal primo all’ultimo valore”.

Intervalli di numeri sono ammessi. Gli intervalli sono due numeri separati da un trattino. L’intervallo specificato è compreso. Per esempio, 8-11 per una voce “ore” specifica l’esecuzione alle ore 8, 9, 10 e 11.

Le liste sono ammesse. Una lista è un insieme di numeri (o intervalli) separati da virgole. Esempi: “1,2,5,9”, “0-4,8-12”.

Valori di frequenza possono essere utilizzati in combinazione con i range. A seguito di un range con uno “/” specifico salta del valore del numero attraverso la serie. Ad esempio, “0-23/2” può essere utilizzato nel campo ora per specificare l’esecuzione del comando ogni due ore.

Al posto dei primi cinque campi, uno delle otto stringhe speciali (macro) possono essere utilizzate:

Stringa                     Significato
------                      -------------
@reboot                   Esegue una vola all'avvio e riavvio
@yearly                   Esegue una volta l'anno, "0 0 1 1 *".
@annually                 (lo stesso di @yearly)
@monthly                  Esegue una volta al mese, "0 0 1 * *".
@weekly                   Esegue una volta alal settimana, "0 0 * * 0".
@daily                    Esegue una volta al giorno, "0 0 * * *".
@midnight                 (lo stesso di @daily)
@hourly                   Esegue una volta ogni ora, "0 * * * *".

Il “sesto” campo (il resto della linea) specifica il comando da eseguire. L’intero comando, fino ad un carattere di nuova riga o %, sarà eseguito da /bin/sh o dalla shell specificata nella variabile SHELL del file crontab.

Nota: Ci possono essere altre macro e si possono addirittura crearne di proprie, per maggiori informazioni guardate il MAN.

ATTENZIONE: I comandi nel Crontab vengono eseguiti da cron quando i campi minuto, ora, mese ed anno coincidono con l’ora corrente e quando almeno uno dei due campi del giorno (giorno del mese, o giorno della settimana) corrisponde al giorno attuale, insomma non è ammessa discrepanza quindi è meglio usare * per definire un secondo campo nel caso prende come 00.

Nota: Se sbagliate qualcosa nel comando non solo il comando non funzionerà correttamente ma può incasinare altri “avviamenti”, dunque attenzione alla sua formulazione e per questo esiste questo sito (in inglese) per scriverlo correttamente.

–Esempio di crontab

Di seguito un esempio di file crontab in cui sono specificate le variabili d’ambiente e i settaggi di comando:

# Crontab Environmental settings
SHELL=/bin/bash
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root

# Crontab Command settings

# m h dom m dow command
00 3 * 7 0 /comando/da/eseguire
15 20 * 1-7 * /comando/da/eseguire2
*/30 7,21 1-15 1 * /comando/da/eseguire3
@reboot /comando/da/eseguire4

Init

Un modo per far partire i programmi all’inizio è init che in realtà è una serie di script che vengono eseguiti alla partenza di Linux. Guardate che è un deprecato per la sua pericolosità.

Come? Avvia Dolphin in modalità superutente ed edita il file

/etc/init.d/boot.local

All’interno basta aggiungere il comando (meglio all’ultimo rigo) per farlo partire.

Nota: il file /etc/init.d/boot.local viene letto automaticamente ad ogni avvio del sistema ed i comandi all’interno vengono eseguiti. Potresti aggiungere anche altri comandi se necessario. Viene eseguito anche in caso di riavvio, ibernazione e simili.

ATTENZIONE: Se scrivete male i successivi comandi non verranno eseguiti e questo potrebbe rendere instabile il sistema!

Se volete farlo appena prima dello spegnimento del sistema

/etc/init.d/halt.local

Ci sono diversi init dentro ognuno è relativo all’avvio di un sistema!

Nota: Notate che in Suse, spesso e volentieri SONO VUOTI! Questo perchè questo sistema è già deprecato in favore di Systemd.

Da DE/WM

Ogni Desktop (sono DE il KDE, TDE, Gnome, ecc..) o Window_manager  (sono WM il IceWM, ecc..) possiede una sua cartella o un file apposito dove se mettete un lanciatore questo verrà eseguito all’avvio del DE/WM.

Ovviamente vi rimando alle guide di ogni singolo WM/DE.

Systemd

Questo è il servizio/demone che controlla tutti i servizi demoni e anche tutte le partenze/uscite ecc..

Attenzione: Sysvinit che è il vecchio sistema è deprecato quindi passate al systemd, menomale che questo problema non esiste con le nuove versioni di Suse.

Molti pensano che Systemd serva solo per velocizzare l’avvio: NIENTE DI PIÙ SBAGLIATO!!!

Nota: Visto che i demoni e servizi sono programmi e può lanciare anche semplici programmi userò solo la terminologia programmi.

• Systemd gestisce non solo servizi di sistema e avvio automatico di programmi-utente, ma anche dispositivi, mount point, timer, e gli altri componenti del sistema.
• Far sparire e/o semplificare e/o diminuire l’importanza degli script portanti in “/etc/sysconfig" "/etc/default" ovvero la bolgia!
• Fa in modo, se volete, che il servizio non si avvia più automaticamente, ma anche assicura che un servizio non può nemmeno essere avviato più manualmente. (mascherare un servizio)
  
• Grazie al systemd-analyze si può controllare veramente le fasi di partenza e correggere gli errori e/o velocizzare il sistema.
• Systemd organizza tutti i programmi, fin usare CGROUP. (isolamento dei programmi)
• Systemd gestisce degli eventi ACPI
• Fornisce una libreria in comune per i programmi
• Fornisce dei servizi e utilità (esempio riavvio se crolla) per i programmi
• Permette che i programmi siano più leggeri (quindi anche veloci) dato che fornisce API dedicate e utilità.
• Pre-carica i programmi e non li esegue (on-demand) fin quando non avviene un evento.
• Controlla automaticamente le loro dipendenze e conflitti.
• Controlla e permette il controllo anche di sicurezza (limiti) dei programmi
• Programma la loro partenza dei i programmi e possiede anche un calendario (come cron) per questo.
• Avvio dei programmi in parallelo e attivazione tramite socket o DBus
• Molto altro ancora (la lista in realtà è lunga) e prossimamente anche molto altro con systemd seconda versione-base (siamo alla ver.16 della prima versione-base).

Come fare per eseguire un programma automaticamente, dato che è di questo che punta questo articolo?

Prima i principali comandi:

per abilitare un servizio presente nella lista e non abilitato aprire il terminale e digitare

 sudo systemctl enable NOMEDELSERVIZIO

per disabilitare un servizio presente nella lista abilitato aprire il terminale e digitare

sudo systemctl disable NOMEDELSERVIZIO

per far partire un servizio presente nella lista e che non è in esecuzione digitare

sudo systemctl start NOMEDELSERVIZIO

per far cessare un servizio presente nella lista ed in esecuzione digitare

sudo systemctl stop NOMEDELSERVIZIO

Per inserire un proprio servizio (attenzione non dovete abilitare un timer che spiegherò più in avanti) ed abilitarlo con systemd è necessario creare le istruzioni che devono essere eseguite (lo script bash) in un file dentro la cartella, qui vediamo un esempio:

/usr/lib/systemd/script/

scrivere le istruzioni dentro e salvare

POI creare un file .service ed inserirlo nella cartella

/usr/lib/systemd/system/

all’interno del file, scrivere

 [Unit]
 Description=Startup Commands
 [Service]
 Type=oneshot
 ExecStart=/usr/lib/systemd/scripts/NOMEFILE
 [Install]
 WantedBy=multi-user.target

dopo aver scritto le istruzioni dentro, (per informazioni sui comandi qui) salvare e dobbiamo abilitare il servizio con

sudo systemctl enable NOMEFILE

Fine.

Qui la “faccio facile” ma esistono una quantità enorme di parametri da applicare: Come vedrete è molto complesso perchè molto potente!!! Studiare tutto il sistema Systemd però permette di avere una vera potenza in mano. Qui mi limiterò ad usi pratici e concreti e non tutto il suo scibile!

Vediamo un esempio lanciando un servizio TOR che è in fondo un programma.

Per prima cosa creiamo un file torLaunch.service:

[Unit]
Description=Launch Tor
DefaultDependencies=no

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/bin/chroot --userspec=tor:tor /opt/torchroot /usr/bin/tor

[Install]
WantedBy=multi-user.target

E lo copiamo in:

/usr/lib/systemd/system/

Ora basterà abilitarlo:

systemctl enable torLaunch

Description=Launch Tor

Contiene le informazioni di base del servizio. I campi più importanti di questa sezione sono:

• Description: una riga che descriva il servizio;
• Wants: lista di servizi che sono necessari per questo servizio. Se il vostro programma usa l’attivazione via socket o dbus, systemd gestisce automaticamente le dipendenze e questo campo non è necessario;
• After: aspetta che i servizi indicati in questo campo sia partiti prima di far partire questo processo. Anche questo campo può essere omesso se si usa l’attivazione via socket o dbus

DefaultDependencies=no

Se ci sono dipendenze da controllare prima di eseguire il programma (dunque il programma non deve contenere codice per controllare se esistono)

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/bin/chroot --userspec=tor:tor /opt/torchroot /usr/bin/tor

Fine esempio.

Ma noi vogliamo eseguirlo in particolari momenti? Systemd controlla gli eventi ACPI e quindi:

Possono essere configurati attraverso le seguenti opzioni di /etc/systemd/logind.conf:

• HandlePowerKey : specifica che azione deve essere eseguita quando viene premuto il bottone di avvio
• HandleSuspendKey : specifica che azione deve essere eseguita quando viene premuto il bottone di sospensione
• HandleHibernateKey : specifica che azione deve essere eseguita quando viene premuto il bottone di ibernazione
• HandleLidSwitch : specifica che azione deve essere eseguita quando il coperchio del portatile viene chiuso.

Le azioni specificate possono essere una qualsiasi di ignore, poweroff, reboot, halt, suspend, hibernate, hybrid-sleep o kexec.

Se queste opzioni non sono configurate, systemd userà quelle di default: HandlePowerKey=poweroff, HandleSuspendKey=suspend, HandleHibernateKey=hibernate, and HandleLidSwitch=suspend.

DUNQUE se vogliamo farlo prima di una “sospensione PC” nel file

/etc/systemd/system/suspend@.service

[Unit]
Description=User suspend actions
Before=sleep.target

[Service]
User=%I
Type=forking
Environment=DISPLAY=:0
ExecStartPre= -/usr/bin/pkill -u %u unison ; /usr/local/bin/music.sh stop ; /usr/bin/mysql -e 'slave stop'
ExecStart=/usr/bin/sflock

[Install]
WantedBy=sleep.target

Combinato suspend/resume ?

/etc/systemd/system/wicd-sleep.service

[Unit]
Description=Wicd sleep hook
Before=sleep.target
StopWhenUnneeded=yes

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=-/usr/share/wicd/daemon/suspend.py
ExecStop=-/usr/share/wicd/daemon/autoconnect.py

[Install]
WantedBy=sleep.target

Qui dopo 15 minuti dalla partenza

/etc/systemd/system/wicd-sleep.service

[Unit]
Description=Wicd sleep hook
Before=sleep.target
StopWhenUnneeded=yes

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=-/usr/share/wicd/daemon/suspend.py
ExecStop=-/usr/share/wicd/daemon/autoconnect.py

[Install]
WantedBy=sleep.target

Ecc..

I timer sono systemd file di unità con un suffisso di .timer I timer sono come gli altri file di configurazione unità e vengono caricati dagli stessi percorsi, ma dispone di un [Timer] sezione. Il [Timer] sezione definisce quando e come il timer si attiva. Temporizzatori sono definiti come uno di due tipi:

• Temporizzatori monotone (non in tempo reale) attivano dopo un intervallo di tempo rispetto a un punto di partenza diversi. Ci sono diversi timer monotone ma tutti hanno la forma di: On Type Sec= OnBootSec e OnActiveSec sono timer monotone comuni.
• Timer in tempo reale (aka timer wallclock) attivano su un evento del calendario (come cronjobs). L’opzione OnCalendar= viene utilizzata per definire loro.

Per ogni .timer file, un corrispondente .service file esiste (ad esempio foo.timer e foo.service Il .timer  attiva e controlla il .service file. Il .service e non richiede un [Install] sezione in quanto è l’unità del timer che sono abilitati. Se necessario, è possibile controllare una unità diversamente denominato utilizzando Unit= opzione del timer [Timer] sezione.

ATTENZIONE: Non avviate mai un Timer come servizio, è la corrispondenza di nome tra nome-servizio e nome-timer che li lega in automatico, dunque fatto partire un servizio questo guarda quando partire dal suo Timer.

Vogliamo farlo secondo un calendario o ore, minuti, ecc… Creiamo il “timer” foo (si legherà in automatico al servizio foo)

/etc/systemd/system/foo.timer

[Unit]
Description=Run foo weekly

[Timer]
OnCalendar=weekly
Persistent=true     
 
[Install]
WantedBy=timers.target

oppure “monolitico”

/etc/systemd/system/foo.timer

[Unit]
Description=Run foo weekly and on boot

[Timer]
OnBootSec=15min
OnUnitActiveSec=1w 

[Install]
WantedBy=timers.target

Consiglio: Se volete far partire dei semplici programmi, meglio che li mettete tutti in un gruppo grazie al Cgrup in modo da controllarli meglio.

Come vedete è molto complesso perchè molto potente!!! Studiare tutto il sistema però permette di avere una vera potenza in mano.

In questo caso potete usare dei programmi che semplificano l’introduzione dei dati per gestire le partenze: systemd-crontab-generator e systemd-cron (replica cron usando systemd) che però non sono ancora arrivati nei repo Suse e nemmeno in Yast (il che è un male) se non guardare e SS (start/stop) i servizi.

Però per visualizzarli per KDE esiste il bellissimo modulo kcm_systemd che compare nelle impostazioni di KDE, in Yast vedere il journal (ovvero il suo log) di systemd, nel repo per Gnome troviamo systemd-ui (si esegue come systemadm) che è abbastanza simpatico come front-end.

-Ricapitolando:

1: per far partire un programma metti in:

/usr/lib/systemd/script/FILENAME

i comandi che vuoi effettuare al boot
2: in

/usr/lib/systemd/system/NOMEFILE.service

imposti il servizio/programma, nel mio caso il file contiene

[Unit]
 Description=Startup Commands
 
 [Service]
 Type=oneshot
 ExecStart=/usr/lib/systemd/scripts/NOMEFILE
 
 [Install]
 WantedBy=multi-user.target

3: Abilita il servizio con

systemctl enable NOMEFILE

/etc/systemd/system/

Ciaooooooooooooooooooooooooooooo

Leggi il contenuto originale su Blog di trucchisuse