I servizi di OpenSolaris (SMF) parte #2

Nella precedente puntata abbiamo visto rapidamente come creare un nuovo SMF, oggi cercheremo di approfondire alcuni aspetti riprendendo sempre il manifesto creato come esempio.

Per quello che riguarda il prologo del nostro manifesto è possibile andare a definire alcune tipologie differenti rispetto a quelle utilizzate; per il tag service_bundle è possibile indicare:

• type='manifest' (il nostro caso) indichiamo che stiamo descrivendo un servizio vero e proprio


• type='profile' indica che stiamo descrivendo un profilo (simile ad una collezione di servizi)

per il tag service possiamo avere tre tipologie differenti:

• type='service' indica un servizio vero e proprio


• type='restarter' definisce un servizio "speciale" che si occupa di controllare lo status (partenza/arresto e riavvio) di una sottocategoria di servizi, di default viene usato svc.startd ma ad esempio per i servizi di rete viene usato come restarter inetd


• type='milestone' rappresenta un servizio che in realtà aggrega più servizi e proprietà, sono a tutti gli effetti paragonabili con i "vecchi" runlevel (ad esempio in runlevel 3 corrisponde alla milestone milestone/multi-user-server:default)

Passando invece alle dipendenze (tag dependency) possiamo innanzi tutto definire la tipologia di dipendenze:

• type='service' in questo caso andremo a descrivere una o più dipendenze da altri servizi


• type='path' così indicheremo la dipendenza da uno o più file presenti nel sistema, attualmente viene controllata solo l'esistenza del file ma non vengono monitorati eventuali cambiamenti o cancellazioni

successivamente possiamo indicare il grado di dipendenza dai servizi (o dai file) con la proprietà grouping:

• grouping='require_any' occorre che almeno un servizio tra quelli elencati sia online per far partire il nostro (oppure deve essere presente almeno un file)


• grouping='require_all' tutti i servizi indicati devono essere online prima che possa partire il nostro (oppure tutti i file devono essere presenti)


• grouping='optional_all' tutti i servizi devono essere online oppure possono essere anche in offline purchè questa disabilitazione non sia stata espressamente settata dall'operatore


• grouping='exclude_all' tutti i servizi elencati devono essere offline (oppure i file indicati non devono esistere)

Infine possiamo decidere il legame tra il nostro servizio e le sue dipendenze nel caso in cui queste ultime subiscano delle variazioni, in particolare:

• restart_on='none' ignora errori o cambiamenti di stato della dipendenza


• restart_on='restart' il nostro servizio viene riavviato al riavviarsi della dipendenza


• restart_on='refresh' se il servizio da cui dipendiamo subisce un refresh


• restart_on='error' in caso errore di una (o più dipendenze) il nostro servizio verrà riavviato.

Termina qui questa seconda parte di approfondimento, la prossima volta analizzeremo nel dettaglio le proprietà e i metodi di esecuzione dei nostri servizi.