Dove trovo i messaggi che appaiono durante il bootstrap del sistema?

[e-commerce84]

Ciao,
stavo legendo questa guida:
http://linux.html.it/guide/lezione/2137/il-bootstrap-parte-seconda/

Uso Linux Ubuntu

Se una volta che ho effettuato l'accesso ad Ubuntu e da Gnome apro un terminale e lancio il comando: dmesg | more mi compare di tutto di più ma non riesco a trovare i messaggi di ciò che avviene durante il bootstrap del sistema come mostrato nella guida.

A rigor di logica credo che ciò dipenda dal fatto che una volta entrato in Gnome il kernel ha fatto altre cose ed ha sovrascritto il buffer di dmseg...almeno credo, confermate o smentite?

Comunque...come faccio a vedere i messaggi che vengono visualizzati durante il bootstrap...suppongo che da qualche parte verranno salvati...

Grazie

[Gimli[2BV!2B]]

Il buffer visualizzato da dmesg è abbastanza generoso ed è contenuto all'interno del kernel.
Molto raramente un processo di boot standard lo esaurisce (tranne in caso di valanghe di errori).

I messaggi che ti interessano sono quelli dei demoni. Con le impostazioni standard questi vanno persi non appena si avvia il server grafico.

In Debian, e mi risulta anche in *buntu, è possibile attivarne l'archiviazione da parte di bootlogd nel file /var/log/boot
Occorre modificare il file /etc/default/bootlogd e riavviare. (http://ubuntuforums.org/showthread.php?t=49925)

[e-commerce84]

;34396639']Il buffer visualizzato da dmesg è abbastanza generoso ed è contenuto all'interno del kernel.
Molto raramente un processo di boot standard lo esaurisce (tranne in caso di valanghe di errori).

I messaggi che ti interessano sono quelli dei demoni. Con le impostazioni standard questi vanno persi non appena si avvia il server grafico.

In Debian, e mi risulta anche in *buntu, è possibile attivarne l'archiviazione da parte di bootlogd nel file /var/log/boot
Occorre modificare il file /etc/default/bootlogd e riavviare. (http://ubuntuforums.org/showthread.php?t=49925)

Ah quindi secondo te dipende dal fatto che questi dati vengono cancellati nel momento in cui mi si avvia X ?!?!

In effetti anche /var/log/boot risulta essere vuoto...ora provo ad attivare il logging (magari è una domanda banale ma perdo in prestazioni loggando?)

Non è una cosa indispensabile però stò cercando di capire come funziona Linux e cosa c'è dietro alle belle finestrelle di Gnome e non riuscire a fare una cosa mi fà rosicare...ora provo...

Tnx

[e-commerce84]

Ok...grazie a quello che mi hai detto ora in parte funziona...tranne che in boot.log non trovo tutte le informazioni che mi sarei aspettato (almeno leggendo i 2 articoli: http://linux.html.it/guide/lezione/2136/il-bootstrap-parte-prima/ e http://linux.html.it/guide/lezione/2137/il-bootstrap-parte-seconda/ )

In pratica dentro il file boot.log ho solo le seguenti linee:


fsck from util-linux-ng 2.17.2

/dev/sda5: clean, 539601/1540096 files, 5381712/6150879 blocks (controllo dopo il prossimo mount)

* Starting AppArmor profiles  Skipping profile in /etc/apparmor.d/disable: usr.bin.firefox


[ OK ]

* Setting sensors limits 
[ OK ]

* Starting BOINC core client: boinc 
[ OK ]

* Setting up scheduling for BOINC core client and children: 
[ OK ]

* Not starting jetty - edit /etc/default/jetty and change NO_START to be 0 (or comment it out).

speech-dispatcher disabled; edit /etc/default/speech-dispatcher

* Starting the Winbind daemon winbind 
[ OK ]

* PulseAudio configured for per-user sessions

saned disabled; edit /etc/default/saned

* Enabling additional executable binary formats binfmt-support 
[ OK ]

* Starting web server apache2 
[ OK ]

* Checking battery state... 


In pratica mi pare che mi dica che:
/dev/sda5 è la partizione del disco su cui risiede il sistema ed una lista di servizzi e demoni che vengono avviati durante l'avvio del sistema però nulla riguardo l'INIT e tutte le tante altre informazioni sul sistema mostrate nelle 2 guide precedentemente linkate...qualche idea del perchè ?

Grazie mille

[Gimli[2BV!2B]]

Il tuo /var/log/boot è abbastanza leggero, ma non conosco la tua installazione: ipotizzerei però che vari messaggi finiscano da qualche altra parte, o persi.

Per esempio questo è il log della Debian Sid che ho sotto mano:Mon Jan 3 14:18:54 2011: Setting parameters of disc: /dev/sda.
Mon Jan 3 14:18:54 2011: Activating swap...done.
Mon Jan 3 14:18:54 2011: Checking root file system...fsck from util-linux-ng 2.17.2
Mon Jan 3 14:18:54 2011: /dev/sda1: clean, 159930/750720 files, 887531/1500061 blocks
Mon Jan 3 14:18:54 2011: done.
Mon Jan 3 14:18:54 2011: Cleaning up ifupdown....
Mon Jan 3 14:18:54 2011: Loading kernel modules...done.
Mon Jan 3 14:18:55 2011: Activating lvm and md swap...done.
Mon Jan 3 14:18:55 2011: Checking file systems...fsck from util-linux-ng 2.17.2
Mon Jan 3 14:18:55 2011: /dev/sda6: recovering journal
Mon Jan 3 14:18:55 2011: /dev/sda6: clean, 2016/8962048 files, 7009182/17920499 blocks
Mon Jan 3 14:18:55 2011: done.
Mon Jan 3 14:18:56 2011: Mounting local filesystems...done.
Mon Jan 3 14:18:56 2011: Activating swapfile swap...done.
Mon Jan 3 14:18:56 2011: Cleaning up temporary files....
Mon Jan 3 14:18:56 2011: Setting kernel variables ...done.
Mon Jan 3 14:18:56 2011: Setting up resolvconf...done.
Mon Jan 3 14:18:57 2011: Setting up networking....
Mon Jan 3 14:18:57 2011: Configuring network interfaces...done.
Mon Jan 3 14:18:59 2011: Cleaning up temporary files....
Mon Jan 3 14:18:59 2011: Setting up ALSA...done.
Mon Jan 3 14:19:00 2011: Setting console screen modes and fonts.
Mon Jan 3 14:19:00 2011: Setting sensors limits.
Mon Jan 3 14:19:00 2011: INIT: Entering runlevel: 2
Mon Jan 3 14:19:01 2011: Using makefile-style concurrent boot in runlevel 2.
Mon Jan 3 14:19:01 2011: Network Interface Plugging Daemon...start eth1...start eth2...done.
Mon Jan 3 14:19:02 2011: Starting system logging: syslog-ng.
Mon Jan 3 14:19:02 2011: Checking battery state...done.
Mon Jan 3 14:19:02 2011: Starting ACPI services....
Mon Jan 3 14:19:04 2011: Starting domain name service...: bind9.
Mon Jan 3 14:19:05 2011: Starting periodic command scheduler: cron.
Mon Jan 3 14:19:05 2011: Starting Music Player Daemon: mpd.
Mon Jan 3 14:19:05 2011: Starting Common Unix Printing System: cupsd.
Mon Jan 3 14:19:07 2011: Starting system message bus: dbus.
Mon Jan 3 14:19:07 2011: Starting MTA: exim4.
Mon Jan 3 14:19:10 2011: Starting Hardware abstraction layer: hald.
Mon Jan 3 14:19:11 2011: Starting NTP server: ntpd.
Mon Jan 3 14:19:11 2011: Not starting internet superserver: no services enabled.
Mon Jan 3 14:19:11 2011: Starting Hardware RNG entropy gatherer daemon: rngd.
Mon Jan 3 14:19:12 2011: Starting Samba daemons: nmbd smbd.
Mon Jan 3 14:19:12 2011: Starting SANE network scanner server: saned.
Mon Jan 3 14:19:12 2011: Starting sensor daemon: sensord.
Mon Jan 3 14:19:13 2011: Enabling S.M.A.R.T..../dev/sda...done.
Mon Jan 3 14:19:13 2011: Starting S.M.A.R.T. daemon: smartd.
Mon Jan 3 14:19:15 2011: Starting OpenBSD Secure Shell server: sshd.Puoi notare vari punti simili all'esempio del tuo link, nonostante il boot dell'articolo sia avvenuto nella primavera del 2001, ma *buntu ha accumulato varie differenze rispetto a mamma Debian nel processo di boot.
In primo luogo hanno scritto ed adottato l'init Upstart (primo sospettato per la mancanza di informazioni nel log, una bestia di razza diversa rispetto all'init SysV classico ancora in uso in Debian), ma poi hanno anche deciso di utilizzare una formattazione bellina e più ordinata (gli [OK] colorati a destra), hanno coperto il tutto con un bootsplash, più altre cose che ho l'impressione di non ricordare, data l'ora.

Concludendo ti consiglierei di provare a spulciare un po' tutti i log in /var/log, anche se non dovessi trovare i messaggi che cerchi avrai comunque modo di scoprire varie cose.
Oppure puoi provare a sentire che dicono nella discussione ufficiale su Ubuntu.

P.S. quel log attivo senz'altro necessiterà di qualche istante per essere scritto; personalmente preferisco attivarlo in Debian, ma visto che il tuo è così scarno sta a te valutarne l'utilità.

[e-commerce84]

;34397683']Il tuo /var/log/boot è abbastanza leggero, ma non conosco la tua installazione: ipotizzerei però che vari messaggi finiscano da qualche altra parte, o persi.

Per esempio questo è il log della Debian Sid che ho sotto mano:Mon Jan 3 14:18:54 2011: Setting parameters of disc: /dev/sda.
Mon Jan 3 14:18:54 2011: Activating swap...done.
Mon Jan 3 14:18:54 2011: Checking root file system...fsck from util-linux-ng 2.17.2
Mon Jan 3 14:18:54 2011: /dev/sda1: clean, 159930/750720 files, 887531/1500061 blocks
Mon Jan 3 14:18:54 2011: done.
Mon Jan 3 14:18:54 2011: Cleaning up ifupdown....
Mon Jan 3 14:18:54 2011: Loading kernel modules...done.
Mon Jan 3 14:18:55 2011: Activating lvm and md swap...done.
Mon Jan 3 14:18:55 2011: Checking file systems...fsck from util-linux-ng 2.17.2
Mon Jan 3 14:18:55 2011: /dev/sda6: recovering journal
Mon Jan 3 14:18:55 2011: /dev/sda6: clean, 2016/8962048 files, 7009182/17920499 blocks
Mon Jan 3 14:18:55 2011: done.
Mon Jan 3 14:18:56 2011: Mounting local filesystems...done.
Mon Jan 3 14:18:56 2011: Activating swapfile swap...done.
Mon Jan 3 14:18:56 2011: Cleaning up temporary files....
Mon Jan 3 14:18:56 2011: Setting kernel variables ...done.
Mon Jan 3 14:18:56 2011: Setting up resolvconf...done.
Mon Jan 3 14:18:57 2011: Setting up networking....
Mon Jan 3 14:18:57 2011: Configuring network interfaces...done.
Mon Jan 3 14:18:59 2011: Cleaning up temporary files....
Mon Jan 3 14:18:59 2011: Setting up ALSA...done.
Mon Jan 3 14:19:00 2011: Setting console screen modes and fonts.
Mon Jan 3 14:19:00 2011: Setting sensors limits.
Mon Jan 3 14:19:00 2011: INIT: Entering runlevel: 2
Mon Jan 3 14:19:01 2011: Using makefile-style concurrent boot in runlevel 2.
Mon Jan 3 14:19:01 2011: Network Interface Plugging Daemon...start eth1...start eth2...done.
Mon Jan 3 14:19:02 2011: Starting system logging: syslog-ng.
Mon Jan 3 14:19:02 2011: Checking battery state...done.
Mon Jan 3 14:19:02 2011: Starting ACPI services....
Mon Jan 3 14:19:04 2011: Starting domain name service...: bind9.
Mon Jan 3 14:19:05 2011: Starting periodic command scheduler: cron.
Mon Jan 3 14:19:05 2011: Starting Music Player Daemon: mpd.
Mon Jan 3 14:19:05 2011: Starting Common Unix Printing System: cupsd.
Mon Jan 3 14:19:07 2011: Starting system message bus: dbus.
Mon Jan 3 14:19:07 2011: Starting MTA: exim4.
Mon Jan 3 14:19:10 2011: Starting Hardware abstraction layer: hald.
Mon Jan 3 14:19:11 2011: Starting NTP server: ntpd.
Mon Jan 3 14:19:11 2011: Not starting internet superserver: no services enabled.
Mon Jan 3 14:19:11 2011: Starting Hardware RNG entropy gatherer daemon: rngd.
Mon Jan 3 14:19:12 2011: Starting Samba daemons: nmbd smbd.
Mon Jan 3 14:19:12 2011: Starting SANE network scanner server: saned.
Mon Jan 3 14:19:12 2011: Starting sensor daemon: sensord.
Mon Jan 3 14:19:13 2011: Enabling S.M.A.R.T..../dev/sda...done.
Mon Jan 3 14:19:13 2011: Starting S.M.A.R.T. daemon: smartd.
Mon Jan 3 14:19:15 2011: Starting OpenBSD Secure Shell server: sshd.Puoi notare vari punti simili all'esempio del tuo link, nonostante il boot dell'articolo sia avvenuto nella primavera del 2001, ma *buntu ha accumulato varie differenze rispetto a mamma Debian nel processo di boot.
In primo luogo hanno scritto ed adottato l'init Upstart (primo sospettato per la mancanza di informazioni nel log, una bestia di razza diversa rispetto all'init SysV classico ancora in uso in Debian), ma poi hanno anche deciso di utilizzare una formattazione bellina e più ordinata (gli [OK] colorati a destra), hanno coperto il tutto con un bootsplash, più altre cose che ho l'impressione di non ricordare, data l'ora.

Concludendo ti consiglierei di provare a spulciare un po' tutti i log in /var/log, anche se non dovessi trovare i messaggi che cerchi avrai comunque modo di scoprire varie cose.
Oppure puoi provare a sentire che dicono nella discussione ufficiale su Ubuntu.

P.S. quel log attivo senz'altro necessiterà di qualche istante per essere scritto; personalmente preferisco attivarlo in Debian, ma visto che il tuo è così scarno sta a te valutarne l'utilità.

Ok,
ti ringrazio...ho seguito i tuoi consigli ed ho spulciato un po' la directory /var/log trovando nel file /var/log/kernel.log (nella versione giornaliera) però insieme a tanta altra roba (ma credo perchè la macchina è diversa da quella dell'esempio ed ha più cose)

Ma in pratica se lancio il comando dmsg mi viene visualizzato il contenuto dell'ultima versione di kernel.log o cosa?

Però ancora non riesco a trovare informazioni relative all'INIT che pare non essere presente neanche in questo file...qualche idea?
Che cos'è l'init Upstart ?

Grazie
Andrea

[Gimli[2BV!2B]]

dmesg visualizza il buffer circolare dei messaggi del kernel, solitamente ha una dimensione di 64 o 128 KiB.
Questi vengono archiviati in tre log:

/var/log/dmesg fotografia del contenuto del buffer del kernel all'avvio del sistema
/var/log/kern.log tutti i messaggi provenienti dal kernel, esclusi quelli di debug
/var/log/syslog è un calderone: tutti i messaggi, tranne quelli di autorizzazione, server mail e debug

Se quei messaggi non sono rintracciabili da nessuna parte non so cosa aggiungere.

Upstart (http://upstart.ubuntu.com/) è un progetto nato in seno ad Ubuntu che ha portato alla sostituzione dell'init classico con un programma più moderno.

È implementato in C mentre l'init SysV non fa quasi altro che invocare script in un certo ordine.
L'ordine di esecuzione degli script viene stabilito in base alle reciproche dipendenze dei demoni, mentre un tempo era necessario creare link fissi cercando di soddisfare a priori tutte le possibili dipendenze di ogni particolare sottoinsieme di demoni potenzialmente installati.
È possibile comunicare coi demoni tramite D-bus (http://it.wikipedia.org/wiki/D-Bus).
Grazie all'implementazione di "eventi" (http://upstart.ubuntu.com/wiki/JobEvents?highlight=%28%28CategorySpec%29%29) si ha la possibilità di controllare più efficacemente i demoni e di scatenare attività in funzione dei loro cambi di stato.
Permette una più efficace parallelizzazione dell'avvio dei demoni.
Rimane comunque retrocompatibile con gli script init classici.


Nel complesso ha molti pro ma:

la transizione non è completa (il primo che ricordo è /etc/init.d/networking)
il problema della soddisfazione delle dipendenze è stato risolto anche in Debian con insserv e informazioni aggiuntive negli script (http://wiki.debian.org/LSBInitScripts/DependencyBasedBoot)
la parallelizzazione è attuabile anche con init basati su script (CONCURRENCY=shell (http://www.debian-administration.org/article/629/Concurrent_boot_sequence)), anche se non con la stessa efficienza
i messaggi dei demoni vanno persi? (Non avendo *buntu a disposizione non lo so)


Resta fuori la questione degli eventi, che sembra un'ottima cosa.

[e-commerce84]

Ok...mi sono documentato un po' su Upstart ma ho ancora qualche problemino...

Da quello che ho capito fino ad un po' di tempo fà all'avvio del sistema veniva letto il file /etc/inittab che conteneva il runlevel di default con il quale si doveva avviare il sistema, adesso questo sistema è stato abbandonato da Ubuntu in favore del sistema UPSTART che stò appunto cercando di capire come funzioni...

Leggo online che sostanzialmente il file /etc/inittab è stato eliminato (ed infatti non è presente nel mio sistema) e sostituito dalla directory /etc/event.d che al suo interno dovrebbe contenere un file per ogni runlevel ed ognuno di questi file contiene al proprio interno le informazioni relative ai serivizzi che devono partire e che devono fermarsi a quel determinato runlevel, giusto? ho capito bene ?

Il grosso problema è che sul mio sistema NON RIESCO A TROVARE LA CARTELLA /etc/event.d (neanche abbilitando la visualizzazione di file e directory nascoste...), non c'è !!! E allora come fà a funzionare il sistema se non c'è ne il vecchio file /etc/inittab ne la nuva cartella /etc/event.d di UPSTART ?!?!

Avviando una ricerca su tutto il disco fisso cercando appunto la stringa "event.d" mi trova queste 3 directory (che però non sò cosa c'entrino):

/etc/apm/event.d
/etc/dbus-1/event.d
/etc/power/event.d

Insomma della cartella /etc/event.d che dovrebbe contenere un file per ogni runlevel non c'è traccia !!! COME MAI ?!?! Cosa mi sfugge ?!?!

Tnx

[Gimli[2BV!2B]]

Le cartelle event.d (in generale tutte quelle che terminano con un .d, anche init.d) contengono script che vengono invocati automaticamente quando avvengono alcuni eventi relativi al demone a cui appartengono.

La mia esperienza di utilizzo di Upstart è quasi nulla e non ho installazioni su cui controllare, ma, basandomi sull'elenco di file contenuti nel pacchetto upstart (http://packages.ubuntu.com/it/maverick/i386/upstart/filelist), ipotizzerei che la cartella che cerchi sia /etc/init/

[e-commerce84]

;34413494']Le cartelle event.d (in generale tutte quelle che terminano con un .d, anche init.d) contengono script che vengono invocati automaticamente quando avvengono alcuni eventi relativi al demone a cui appartengono.

La mia esperienza di utilizzo di Upstart è quasi nulla e non ho installazioni su cui controllare, ma, basandomi sull'elenco di file contenuti nel pacchetto upstart (http://packages.ubuntu.com/it/maverick/i386/upstart/filelist), ipotizzerei che la cartella che cerchi sia /etc/init/

Allora,
intanto grazie mille...sei veramente una miniera di conoscienza :D

Mi stò addentrando da poco nello scoprire cosa c'è dietro alle finestrelle di Ubuntu ed anche reperire la documentazione non è facilissimo...alcune cose non si trovano...altre si ma non è detto che siano aggiornate o che coincidano con la mia distribuzione...interessante questo elenco dei contenuti dei pacchetti...possono tornare utili, buono a sapersi...

Allora io ho 2 cartelle:
/etc/init/ che contiene dei file .conf
/etc/init.d/ che contiene degli script (almeno credo...) però mi sembrano scriptt relativi appunto ai demoni, tipo c'è cron,cups, apache2 tanto per citarne alcuni...

Però sulla guida che avevo letto diceva esplicitamente che dentro la cartella /etc/event.d (che stiamo supponendo essere equivalente a /etc/init.d) dovrebbe esserci un file per ogni runlevel che dice quali servizzi (demoni) lanciare all'avvio...questa cosa non mi torna...

[Gimli[2BV!2B]]

Posso dirti che mi risulta sia normale che in /etc/init.d siano presenti molti script, credo siano presenti tutti quelli dei demoni installati come in un normale sistema che usa l'init SysV.
Ricordo però che tentando di invocare direttamente gli script di servizi gestiti con Upstart non accade nulla e si riceve un messaggio che suggerisce di utilizzare i comandi start, stop o restart (per esempio sudo restart gdm).

Vedo che i demoni gestiti con Upstart installano un file conf in /etc/init, quindi credo che il cuore sia quella cartella. Cosa c'è scritto in quei file?

Non trovo traccia della /etc/event.d che citi.

P.S. visto che non conoscevi il sito packages ti segnalo anche una sua "interfaccia" da console: apt-file (http://guide.debianizzati.org/index.php/Apt-file:_ricerca_all'interno_dei_pacchetti).
Per esempio lo potresti utilizzare per cercare se un qualsiasi pacchetto contiene file per questa cartella /etc/event.d:apt-file search /etc/event.d(In Debian non si ottiene nulla)

[e-commerce84]

Allora, dopo aver installato il programma apt-file che non era presente nel mio sistema, ho lanciato il comando che mi hai detto e mi ha dato il seguente output che però non sò cosa sgnifichi:


andrea@andrea-laptop:~$ apt-file search /etc/event.d
grub: /etc/event.d/last-good-boot
runit: /etc/event.d/runsvdir
ubuntu-mid-default-settings: /etc/event.d/session


Comunque da quello che ho capito leggendo un po' in giro la cosa dovrebbe essere così:

1) Gli script che lanciano i vari servizzi e domoni sono tutti nella cartella /etc/init.d

2) Ogni runlevel è gestito da un'apposita cartella /etc/rcX.d (con X che và da 0 a 6: rc0.d, rc1.d,....rc6.d e poi c'è anche rcS.d che dovrebbe essere per il runlevel speciale di booting del sistema...almeno credo...almeno così ho capito leggendo il file readme in questa cartella). Insomma dentro ognuna di queste cartelle ci sono dei collegamenti agli opportuni script nella cartella /etc/init.d
Ad esempio nella cartella rcS.d che dovrebbe gestire il runlevel relativo all'avvio del sistema ci saranno i link ai soli script necessari per l'avvio di Linux (ma non era 0 un tempo?!?1 perchè lo chiama S ?!?!)

Poi leggo solo ora questa cosa (trovata quì http://www.linux.com/archive/feature/125977 ):


As more system services are put under the control of Upstart, entries in the /etc/event.d directory will replace the contents of the /etc/init.d and /etc/rc?.d directories. Runlevels will no longer be a formal feature of Ubuntu, although they will be maintained for compatibility with third-party software. Eventually Upstart will also replace crond.

In pratica da quel che leggo in futuro dovrebbero sostituire la gestione dei runlevel messi in /etc/rc?.d con la gestione che dicevo io all'inizio usando appunto i file nella directory /etc/event.d ?!?!

Tnx
Andrea

[Gimli[2BV!2B]]

L'output di apt-file significa che la cartella /etc/event.d verrà creata solo se si installerà grub (http://packages.ubuntu.com/maverick/grub) legacy, runit (http://packages.ubuntu.com/maverick/runit) (altro init ancora) o ubuntu-mid-default-settings (http://packages.ubuntu.com/maverick/ubuntu-mid-default-settings)

Insomma, direi che la cartella /etc/event.d non serve praticamente a nulla e non c'entra con Upstart. Probabilmente è stata utilizzata in una delle prime versioni.
Ipotizzo che ora usi /etc/init/

Non trovo niente di sbagliato nei tuoi punti 1 e 2.
Il runlevel S è il single user, vale a dire quello in cui il sistema avvia solo ed esclusivamente gli script di inizializzazione fondamentali (mount delle partizioni di sistema, networking, keymaps, ora, ecc...). Al termine dell'esecuzione degli script è attivo un solo terminale virtuale ed è possibile fare login con un solo utente.
Il runlevel 1 riporta il sistema all'S fermando tutti i demoni.
Lo 0 spegne il sistema.
Il 2 è quello standard.
Il 6 riavvia.
Quelli in mezzo sono personalizzabili.

Non so più cosa aggiungere su Upstart, non sono in grado di andare oltre e non ho *buntu installate.

[e-commerce84]

;34423004']L'output di apt-file significa che la cartella /etc/event.d verrà creata solo se si installerà grub (http://packages.ubuntu.com/maverick/grub) legacy, runit (http://packages.ubuntu.com/maverick/runit) (altro init ancora) o ubuntu-mid-default-settings (http://packages.ubuntu.com/maverick/ubuntu-mid-default-settings)

Insomma, direi che la cartella /etc/event.d non serve praticamente a nulla e non c'entra con Upstart. Probabilmente è stata utilizzata in una delle prime versioni.
Ipotizzo che ora usi /etc/init/

Non trovo niente di sbagliato nei tuoi punti 1 e 2.
Il runlevel S è il single user, vale a dire quello in cui il sistema avvia solo ed esclusivamente gli script di inizializzazione fondamentali (mount delle partizioni di sistema, networking, keymaps, ora, ecc...). Al termine dell'esecuzione degli script è attivo un solo terminale virtuale ed è possibile fare login con un solo utente.
Il runlevel 1 riporta il sistema all'S fermando tutti i demoni.
Lo 0 spegne il sistema.
Il 2 è quello standard.
Il 6 riavvia.
Quelli in mezzo sono personalizzabili.

Non so più cosa aggiungere su Upstart, non sono in grado di andare oltre e non ho *buntu installate.

Già già...in effetti hai ragione...proprio oggi googlando ho trovato questo: https://wiki.ubuntu.com/KarmicKoala/ReleaseNotes/it#/etc/event.d%20non%20pi%C3%B9%20utilizzato

Sostanzialmente dice che dalla versione 9.10 KarmicKoala la cartella in questione non è più /etc/event.d ma è cambiata in /etc/init come tu mi hai detto...il perchè non lo sò però...

Mi chiedo però il perchè questi cambiamenti da una versione all'altra e sopratutto mi pare che spesso le informazioni siano eccessivamente frammentate e difficili da reperire (ma magari sono solo un po' tonto io).

Ad esempio io avevo provato a vedere nella documentazione della mia versione di Ubuntu che è la 10.10 e di questo cambiamento che è partito nella 9.10 non ve ne era traccia...ma dico io...posso capire se fossero cose vecchissime...ma ancora oggi il 99% dei tutorial e delle guide online fà riferimento a questa cartella /etc/event.d...magari una notina anche nella documentazione della 10.10 non avrebbe guastato...

Solo una piccola nota a quanto hai detto te sui runlevel, a me risulta che:

0: spegne il sistema
1: single user mode (e non s) e che non faccia partire i servizzi dedicati alla gui ne tantomeno il networking
2: multi user mode: fà partire gui, networking e gestione multiutenza
3,4,5 == 2
6: reboot del sistema

S: mi pare di capire che sia solo per lo start del sistema e che è una sorta di runlevel nascosto e che una volta che ha avviato il sistema cede il controllo al runlevel di default (in genere il 2)

Ho capito bene?

[Gimli[2BV!2B]]

Sul boot process mi sembra ben fatta questa pagina della wiki Debian. (http://wiki.debian.org/BootProcess)S /etc/rcS.d/ Single-user mode on boot. The lower case s can be used as alias.
1 /etc/rc1.d/ Single-user mode switched from multi-user mode.L'S è single se ci si ferma lì al boot (http://www.cyberciti.biz/faq/grub-boot-into-single-user-mode/); l'1 è per tornare a single da un runlevel superiore (telinit 1). Insomma, sono entrambi single mode, ma il primo è quello che definisce il runlevel single: l'1 ferma tutti i servizi e riporta il sistema in uno stato S.

Ti confermo che anch'io faccio fatica a trovare informazioni su Upstart. Trattandosi di una scatola nera scritta in C ipotizzo che gli unici file potenzialmente personalizzabili siano quelli in /etc/init/, che peraltro non ho ancora visto in faccia, quindi non ne conosco la complessità.
Per finire mi risulta che non sia ancora completo, quindi soggetto a sostanziali modifiche che non permettono la scrittura di documentazione duratura.

[e-commerce84]

;34424653']Sul boot process mi sembra ben fatta questa pagina della wiki Debian. (http://wiki.debian.org/BootProcess)S /etc/rcS.d/ Single-user mode on boot. The lower case s can be used as alias.
1 /etc/rc1.d/ Single-user mode switched from multi-user mode.L'S è single se ci si ferma lì al boot (http://www.cyberciti.biz/faq/grub-boot-into-single-user-mode/); l'1 è per tornare a single da un runlevel superiore (telinit 1). Insomma, sono entrambi single mode, ma il primo è quello che definisce il runlevel single: l'1 ferma tutti i servizi e riporta il sistema in uno stato S.

Ti confermo che anch'io faccio fatica a trovare informazioni su Upstart. Trattandosi di una scatola nera scritta in C ipotizzo che gli unici file potenzialmente personalizzabili siano quelli in /etc/init/, che peraltro non ho ancora visto in faccia, quindi non ne conosco la complessità.
Per finire mi risulta che non sia ancora completo, quindi soggetto a sostanziali modifiche che non permettono la scrittura di documentazione duratura.

mmm ora dò un'occhiata al link che mi hai mandato ma appunto mi pare faccia riferimento al sistema di boot usato da Debian che ha scelto di continuare ad usare i runlevel (almeno per ora) mentre su Ubuntu i runlevel sono solo simulati...

Quindi mi pare di capire che quel link vada benissimo qualora volessi lanciare dei miei servizzi usando la classica gestione a runlevel (simulandola) ma non va bene se volessi appunto usare sto benedetto UpStart...

Da quello che ho capito se volessi usare UpStart devo creare un file che contiene un job dentro la cartella /etc/init/
La cartella /etc/init contiene dei file .conf che non sò bene cosa rappresentino...da quello che ho capito invece i file di job da metterci dentro sono dei file full text privi di estensione che contengono appunto i job nella forma base <evento, comando>, credo qualcosa del tipo: <collegato un nuovo hard disk esterno, montalo e scrivi un log su un file>

Poi magari stò dicendo una marea di sciochezze perchè ancora non ho avuto modo di provare...

Su come funziona la modalità di come viene simulato il vecchio demone init invece credo di aver capito perchè riesco comunque a fargli cambiare runlevel alla vecchia maniera...

Continuo ad indagare...se poi riesco a capire decentemente magari ci scrivo una guida in italiano...magari a qualcuno potrebbe servire :-)

Tnx

[e-commerce84]

Doh...rieccomi...mi sono imbattuto in una cosa alquanto strana...

Allora...sono riuscito a scrivere il mio primo job seguento questa guida: http://www.linux.com/archive/feature/125977

Il job l'ho chiamato mudat ed è questo:


start on runlevel 2
exec echo "Entering multiuser mode on " $(date) > /tmp/mudat.out


Semplicemente mette una stringa del tipo: "Entering multiuser mode on Sun Feb 13 12:13:35 CET 2011" dentro il file /tmp/mudat.out quando si passa a runlevel 2 (ho provato ad esempio a portarlo a runlevel 3 e poi di nuovo a runlevel 2 con il comando init ed effettivamente funziona)

Questo job è stato messo nella cartella /etc/inint/ come avevamo appurato...la cosa strana è che sia su quell'articolo che ho seguito, sia sulla documentazione ufficiale di UpStart: http://upstart.ubuntu.com/getting-started.html dice chiaramente che i job devono essere messi in file di tipo plain text senza l'estensione *.conf

Jobs are defined in files placed in /etc/init, the name of the job is the filename under this directory without the .conf extension. They are plain text files and should not be executable.

Il fatto è che se non ci metto l'estenzione .conf non succede nulla...se lo stesso job lo rinomino e gli aggiungo il .conf alla fine del nome pare funzionare perfettamente...COME MAI QUESTA COSA ?!?! Contraddice anche la documentazione ufficiale...tra l'altro mi pare che tutti i file .conf dentro /etc/init/ contengano script che avviano servizzi quando si verifica un determinato evento...booo

Parere in merito?

Tnx

[Gimli[2BV!2B]]

Immagino che in una versione precedente di Upstart i file fossero sprovvisti di estensione.
Poi avranno cambiato idea; personalmente trovo preferibile avere un'estensione che permetta di attivare/disattivare l'esecuzione o creare file di backup (anche gli init.d devono essere .sh).

P.S. servizi

[e-commerce84]

;34443350']Immagino che in una versione precedente di Upstart i file fossero sprovvisti di estensione.
Poi avranno cambiato idea; personalmente trovo preferibile avere un'estensione che permetta di attivare/disattivare l'esecuzione o creare file di backup (anche gli init.d devono essere .sh).

P.S. servizi

Ok...però mi pare assurdo che nel sito ufficiale di UpStart abbiano lasciato la vecchia documentazione che dice chiaramente che i file devono essere senza estensione...che fanno? cambiano le regole del gioco e non lo scrivono ?!?! DOH...

Altra domandinae...magari è banale ma che differenza c'è tra gli script dentro /etc/init.d e quelli in /etc/init ?

Tnx

[Gimli[2BV!2B]]

Dalla descrizione della sintassi che ho visto nei tuoi link, i file /etc/init sono script con un linguaggio specifico per l'"interprete" Upstart, con la possibilità di integrare porzioni di script shell standard.
Immagino che i pid dei processi avviati siano salvati nella memoria dello stesso Upstart.

Gli script init classici sono semplici script shell; in Debian sono privi di bashismi (http://mywiki.wooledge.org/Bashism), in quanto devono funzionare con l'interprete Dash (http://man.he.net/man1/dash).
Gli init SysV salvano le informazioni relative ai demoni avviati nella cartella /var/run (pid, socket e file ausiliari).
Il comando principe per la gestione dei processi demonizzati è start-stop-daemon (http://man.he.net/man8/start-stop-daemon)

[e-commerce84]

;34447475']Dalla descrizione della sintassi che ho visto nei tuoi link, i file /etc/init sono script con un linguaggio specifico per l'"interprete" Upstart, con la possibilità di integrare porzioni di script shell standard.
Immagino che i pid dei processi avviati siano salvati nella memoria dello stesso Upstart.

Gli script init classici sono semplici script shell; in Debian sono privi di bashismi (http://mywiki.wooledge.org/Bashism), in quanto devono funzionare con l'interprete Dash (http://man.he.net/man1/dash).
Gli init SysV salvano le informazioni relative ai demoni avviati nella cartella /var/run (pid, socket e file ausiliari).
Il comando principe per la gestione dei processi demonizzati è start-stop-daemon (http://man.he.net/man8/start-stop-daemon)

Si hai ragione...dentro /etc/init a quanto pare ho sia gli script init classici di tipo shell (quelli che sono a loro volta puntati dai link simbolici in /etc/init.d che con le cartelle rc? dovrebbe simulare il vecchio init SystemV), sia gli eventuali script natvi per UpStart che come tu mi dici dovrebbero comunque poter includere anche porzioni di script shell standard tramite il "tag" script....codice...end script

Comunque anche io che ho UpStart dentro /var/run/ credo di avere le informazioni di cui mi parlavi con file del tipo apache2.pid

Però credo che entrare in certi dettagli complichi moltooo la questione

Tnx

[e-commerce84]

mmmm rivedendo gli esempi ho ancora una domandina (lo sò..sono un rompi balle :D )

Questa volta la domanda riguarda al come definire un evento personale ed impostare un job che viene attivato da quello specifico evento. Sempre facendo riferimento all'articolo: http://www.linux.com/archive/feature/125977 mi riferisco in particolar modo a questo esempio:


start on hithere
script
echo "Hi there, here I am!" > /tmp/myjob.out
date >> /tmp/myjob.out
end script


In questo caso il comportamento del job credo sia definito da uno script bash (credo perchè ancora non mi è mai capitato di studiare gli script bash) che a senso mette la frase "Hi there, here I am!" e la data e ora di quando ciò accade nel file /tmp/myjob.out

Tale job che lancia il bash script viene attivato da un evento chiamato hithere che credo sia un evento personale (nel senso che è un evento che definisco io e non come "start on runlevel 2" che invece dovrebbe proprio essere un evento di sistema)

Allora il job pare funzionare se lo lancio usando il comando: initctl sudo start myjob (o usando semplicemente sudo start myjob) perchè appunto mi crea il file /tmp/myjob.out contenente le 2 righe informative previste dallo script bash che il job esegue

Il fatto è che l'evento hithere se ben capisco è un evento personale che deve in qualche modo essere collegato ad un qualche evento di sistema (o forse anche a più di uno)....dico bene? Ma come ?!?!

Nell'articolo dice che è possibile usare il comando emit initctl per triggare il job e fà vedere l'output del seguente comando:

OUTPUT NELL'ARTICOLO:

$ sudo initctl emit hithere
hithere
myjob (start) waiting
myjob (start) starting
myjob (start) pre-start
myjob (start) spawned, process 6064
myjob (start) post-start, (main) process 6064
myjob (start) running, process 6064
myjob (stop) running
myjob (stop) stopping
myjob (stop) killed
myjob (stop) post-stop
myjob (stop) waiting


Ma il mio OUTPUT PERSONALE se lo lancio nella mia shell è vuoto:


andrea@andrea-laptop:~$ sudo initctl emit hithere
andrea@andrea-laptop:~$


Mi sfugge qualcosa? come faccio a collegare l'evento personale hithere con qualcosa del sistema? o se non ho capito una mazza del concetto alla base mi sai dire cosa?

Grazie mille

[Gimli[2BV!2B]]

Non trovo nulla di sbagliato nelle tue affermazioni.

Da quel che ho trovato scritto in giro non dovrebbe essere necessario fare altro per definire un evento...

Riguardo agli output differenti dell'esempio sudo initctl emit hithere, trascurando la mancanza di output, hai controllato se il file /tmp/myjob.out viene modificato?
Credo che il comando sia stato eseguito o con uno script Upstart differente da quello dell'esempio, oppure con un initctrl molto più verboso (cioè con molti più output di debug) come consono ad una versione di sviluppo.

Ti riporto due link più recenti di quelli che hai trovato tu, prova a controllare gli esempi che forniscono loro:
Ubuntu's Success Story: the Upstart Startup Manager (http://www.linuxplanet.com/linuxplanet/tutorials/7033/1/)
Controlling Ubuntu's and Fedora's Upstart (http://www.linuxplanet.com/linuxplanet/tutorials/6749/1/)

[e-commerce84]

Allora,
ora andrò a leggermi i link che mi hai passato...

Il fatto è che l'evento hithere dovrebbe essere appunto un evento che ho definito io ma che non dovrebbe essere associato a nulla (nel senso che non si verifica ne quando passo ad uno specifico runlevel, ne quando attacco una pennetta usb al computer, insomma...non saprei come spiegare diversamente...è un evento mio che non viene innescato da una particolare situazione che accade nella\alla macchina...)

Eventualmente mi viene da pensare che possa essere io a far partire l'evento hithere, ma come ?!?! Cioè che magari posso dirgli io in modo fittizio: "Guarda che è avvenuto l'evento hithere"

Per quanto riguarda le tue affermazioni...ho appena controllato, se faccio: sudo initctl emit hithere in effetti mi crea il file /tmp/myjob.out ed esso contiene i dati previsti (così come ciò accade se sono io a scegliere di lanciare direttamente il job con un sudo start myjob)

mmm allora forse mi sfugge il senso vero e proprio del comando: sudo initctl emit hithere

Di preciso che fà? forse è questo che mi manca...mi sai illuminare?

Mi leggerò anche i link che mi hai passato che sembrano molto interessanti ;-)

Tnx

[Gimli[2BV!2B]]

Beh, direi che sudo initctl emit hithere emette l'evento hithere, scatenando quindi l'invocazione dello script. Mi sembra si tratti di ciò che stai cercando.

L'altro modo principale per utilizzare gli eventi dovrebbe essere attraverso D-Bus (http://it.wikipedia.org/wiki/D-Bus).
Qui c'è la pagina wiki su D-Bus (http://upstart.ubuntu.com/wiki/DBusInterface), ma temo sia obsoleta.

P.S. ho trovato traccia delle modifiche ai file di configurazione (https://launchpad.net/upstart/+announcement/3170) (Upstart 0.6.0 2009-07-09):

Configuration paths have changed. Global configuration now resides in "/etc/init.conf" while jobs are now configured in "/etc/init"
Job configuration filenames must now end in ".conf"
Default configuration files are now supplied in the "conf" sub-directory of the source, and installed into "/etc/init".

[e-commerce84]

;34455501']Beh, direi che sudo initctl emit hithere emette l'evento hithere, scatenando quindi l'invocazione dello script. Mi sembra si tratti di ciò che stai cercando.

L'altro modo principale per utilizzare gli eventi dovrebbe essere attraverso D-Bus (http://it.wikipedia.org/wiki/D-Bus).
Qui c'è la pagina wiki su D-Bus (http://upstart.ubuntu.com/wiki/DBusInterface), ma temo sia obsoleta.

P.S. ho trovato traccia delle modifiche ai file di configurazione (https://launchpad.net/upstart/+announcement/3170) (Upstart 0.6.0 2009-07-09):

Configuration paths have changed. Global configuration now resides in "/etc/init.conf" while jobs are now configured in "/etc/init"
Job configuration filenames must now end in ".conf"
Default configuration files are now supplied in the "conf" sub-directory of the source, and installed into "/etc/init".


Per quanto riguarda i cambiamenti apportati mi risulta tutto tranne il file /etc/init.conf che non mi risulta averlo....vabbè...comunque credo che l'arcano sia stato risolto...

Ok...allora il comando emit appunto fà emettere l'evento...ma all'atto pratico a cosa mi serve? Ad esempio potrei scrivere un mio programma od un mio script che in base a determinate condizioni emette un MIO evento che appunto fà partire il mio job ? E' questo il senso pratico della questione?

Avevo sentito parlare di D-Bus come metodo di comunicazione tra processi anche se non lo conosco per niente all'atto pratico...

Per proseguire con il mio studio del pinguino (ora come ora stò solamente studiacchiando nei ritagli di tempo e non ho uno scopo preciso) con cosa mi consigli di procedere?
Diciamo che al momento stavo seguendo questa guida abbastanza vecchiotta: http://linux.html.it/guide/leggi/72/guida-linux/ e poi visto che non mi tornavano i conti nel capitolo dedicato ai demoni e servizzi ho passato circa una settimana ad approfondire altrove...

Ora cosa mi consiglieresti di vedere per proseguire un po' su questa strada? Magari lo scripting in bash o cos'altro? Quali sono gli argomenti must per un buon conoscitore di Linux?

Grazie mille

[Gimli[2BV!2B]]

Ok...allora il comando emit appunto fà emettere l'evento...ma all'atto pratico a cosa mi serve? Ad esempio potrei scrivere un mio programma od un mio script che in base a determinate condizioni emette un MIO evento che appunto fà partire il mio job ? E' questo il senso pratico della questione?Esatto. Se si volesse fare la stessa cosa con degli script sarebbe molto più scomodo/delicato o quasi impossibile.

Io di D-Bus conosco giusto il nome e lo scopo...

Quali argomenti ti posso consigliare...
Se sei proprio a zero sull'argomento script shell ti consiglierei di darci un'occhiata: le distribuzioni sono solitamente permeate di script. Torna spesso utile, non dico scrivere grossi script, ma almeno leggere ciò che viene fatto ed essere in grado di fare piccole modifiche.
Inoltre, hai familiarità con almeno un linguaggio di programmazione? Questo non solo torna utile per assimilare meglio lo scripting ad apprezzarne le potenzialità ed i grossi limiti, ma anche per capire parecchie cose. Personalmente non saprei quale linguaggio consigliarti, ma puoi trovare molte discussioni sull'argomento nella sezione programmazione (http://www.hwupgrade.it/forum/forumdisplay.php?f=38) o intervenire anche là.

[e-commerce84]

;34464013']Esatto. Se si volesse fare la stessa cosa con degli script sarebbe molto più scomodo/delicato o quasi impossibile.

Io di D-Bus conosco giusto il nome e lo scopo...

Quali argomenti ti posso consigliare...
Se sei proprio a zero sull'argomento script shell ti consiglierei di darci un'occhiata: le distribuzioni sono solitamente permeate di script. Torna spesso utile, non dico scrivere grossi script, ma almeno leggere ciò che viene fatto ed essere in grado di fare piccole modifiche.
Inoltre, hai familiarità con almeno un linguaggio di programmazione? Questo non solo torna utile per assimilare meglio lo scripting ad apprezzarne le potenzialità ed i grossi limiti, ma anche per capire parecchie cose. Personalmente non saprei quale linguaggio consigliarti, ma puoi trovare molte discussioni sull'argomento nella sezione programmazione (http://www.hwupgrade.it/forum/forumdisplay.php?f=38) o intervenire anche là.

Programmare sò programmare perchè mi mancano 4 esami alla triennale di informatica...prevalentemente Java ed un po' di C...ma più Java perchè in Java conosco un po' il framework Spring e lo sviluppo di applicazioni su piattaforma Android

Proprio oggi ho iniziato uno stage in un'azienda e stò su un progetto Java in ambiente LifeRay (ahhhhh....impazzirò perchè mi pare un bel casino...)

Spero di riuscire a dedicare ancora un po' delle mie energie al pinguino in questo tempo perchè mi interessa molto...in questi 6 mesi sarò letteralmente sommerso da Java ma nei ritagli di tempo un po' di scripting in bash me lo sparo volentieri così come cercare di capire come funziona il sistema operativo in maniera un po' più approfondita...

Forse pecco di superbia ma vedo tanta gente che magari sà solo programmare in Java e magari non sà nulla di Linux o dell'architettura di un SO in generale, così come al lavoro conobbi persone espertissime di Linux che sostenevano che Java era il male (perchè secondo me non lo conoscono e non vogliono conoscerlo) e che tutto ciò che puoi fare in Java lo puoi fare anche in C (mmm con tutto che non sono un fan delle web application in Java ma vorrei vedere come fai a farle in C...)

Io booo....vorrei specializzarmi in qualcosa ma vorrei anche avere conoscenze decenti in altro per lasciarmi delle porte aperte...spero sia fattibile come cosa

[Gimli[2BV!2B]]

Anch'io son ing. junior e programmatore, prevalentemente C++, ma sto contribuendo a variegare un minimo i linguaggi aziendali.
Personalmente adoro andare oltre la sola programmazione e sono convinto che sia stupido fossilizzarsi su di un solo linguaggio.

Quel LifeRay l'avevo già sentito, molto enterprisey; Tomcat e JSP, in percentuale non ci lavoro molto ma lo considero un ambiente di sviluppo abbastanza comodo. Non so bene cosa comporti aggiungere in mezzo questa enterprise web platform, ma immagino si possa immaginare come una stanza da rifinire e ammobiliare, senza aver la necessità di tirar su i muri e stendere gli impianti.

[e-commerce84]

;34465383']Anch'io son ing. junior e programmatore, prevalentemente C++, ma sto contribuendo a variegare un minimo i linguaggi aziendali.
Personalmente adoro andare oltre la sola programmazione e sono convinto che sia stupido fossilizzarsi su di un solo linguaggio.

Quel LifeRay l'avevo già sentito, molto enterprisey; Tomcat e JSP, in percentuale non ci lavoro molto ma lo considero un ambiente di sviluppo abbastanza comodo. Non so bene cosa comporti aggiungere in mezzo questa enterprise web platform, ma immagino si possa immaginare come una stanza da rifinire e ammobiliare, senza aver la necessità di tirar su i muri e stendere gli impianti.

Beh diciamo che da novellino...attualmente per me la grossa difficoltà è proprio mettere le mani su qualcosa che ha già i muri costruiti ed è da rifinire perchè devo capire tutta la logica del framework e come interagiscono i vari pezzi tra loro...diciamo che sono ancora abituato all'esercizietto in cui parti da 0 e creis econdo la tua logica...toccherà imparare...per ora stò leggendo documentazione