Linux Tutorial – Puntata 7
di jolek78
Care/i fruitrici e fruitori del blog, in questi post – ogni domenica mattina – si parlerà del sistema operativo GNU/Linux e degli strumenti per utilizzarlo al massimo delle potenzialità. Cercheremo di spiegare come funziona, cosa è il kernel, come costruirsi una vpn, come settare un firewall e giocare col terminale, usare adb e altro. Se il capitalismo della sorveglianza ci vuole passivi consumatori-consumatrici di servizi noi si risponde con un po’ di “cultura informatica” e un MARAMEO (quasi affettuoso). Buona lettura!
Bentornati, cari i miei giovani (o diversamente giovani) virgulti. Quest’oggi una lunga puntata sui processi di sistema. Giusto un disclaimer iniziale: utilizzero’ systemd nell’analisi del log – abbiate pazienza, poi arriveremo alla puntata sui log. So bene che nella comunità linux c’e’ un grande dibattito aperto, e mai chiuso, su systemd. So che molti se ne lamentano, e a ragione, so che sysinit era in qualche modo migliore di systemd, che era più modulare etc etc. Che systemd è un modo maldestro per voler controllare tutto il sistema con un solo comando. Ma systemd è letteralmente il nuovo standard, e rimpiangere sysinit sarebbe come vivere nel sud Italia e rimpiangere i Borboni. Ah, mi dicono dalla regia che c’e’ qualcuno che lo fa per davvero?
I Processi e i Demoni
Un processo è letteralmente un qualcosa di attivo sul sistema. Non un file statico, ma qualcosa che nel sistema occupa memoria, fa operazioni, crea processi figli, o lavora in background. Senza processi il nostro sistema non funzionerebbe, e comprendere cosa siano è di fondamentale importanza per comprendere come lavori il sistema operativo.
Fase di Boot (intro)
Esploreremo il boot in seguito in maniera piu’ approfondita quando parleremo del single user mode, ma per comprendere la struttura dei processi, dobbiamo prima capire da dove arrivino.
fase 1
Si parte dal bios, che controlla l’hardware presente sulla macchina, fa le prime analisi, e, ad operazione eseguita, da avvio al boot loader
fase 2
Il boot loader, di norma posizionato nel mbr (master boot record) si occupa di accedere in una zona del disco dove e’ posizionato il kernel
fase 3
Il kernel a questo punto, cuore pensante del sistema, viene decompresso e si occupa di far partire systemd, il papa’ di tutti i processi che verranno fatti partire successivamente
fase 4
Parte il primo processo, e comincia effettivamente la fase che portera’ alla partenza del sistema operativo.
Dal Kernel in poi
Visualizziamo un attimo il boot sui log di sistema
bottega@bottegadelbarbieri / journalctl -b |more -- Logs begin at Sat 2021-02-27 09:10:23 GMT, end at Fri 2021-04-09 02:17:01 BST. -- Apr 09 01:38:39 bottegadelbarbieri kernel: Linux version 5.8.0-48-generic (buildd@lgw01-amd64-008) (gcc (Ubuntu 9.3.0-17ubuntu1~20.0 4) 9.3.0, GNU ld (GNU Binutils for Ubuntu) 2.34) #54~20.04.1-Ubuntu SMP Sat Mar 20 13:40:25 UTC 2021 (Ubuntu 5.8.0-48.54~20.04.1-gen eric 5.8.18) Apr 09 01:38:39 bottegadelbarbieri kernel: Command line: BOOT_IMAGE=/vmlinuz-5.8.0-48-generic root=/dev/mapper/vgxubuntu-root ro qui et splash Apr 09 01:38:39 bottegadelbarbieri kernel: KERNEL supported cpus: Apr 09 01:38:39 bottegadelbarbieri kernel: Intel GenuineIntel Apr 09 01:38:39 bottegadelbarbieri kernel: AMD AuthenticAMD Apr 09 01:38:39 bottegadelbarbieri kernel: Hygon HygonGenuine Apr 09 01:38:39 bottegadelbarbieri kernel: Centaur CentaurHauls Apr 09 01:38:39 bottegadelbarbieri kernel: zhaoxin Shanghai Apr 09 01:38:39 bottegadelbarbieri kernel: x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers' Apr 09 01:38:39 bottegadelbarbieri kernel: x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers' Apr 09 01:38:39 bottegadelbarbieri kernel: x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers' Apr 09 01:38:39 bottegadelbarbieri kernel: x86/fpu: xstate_offset[2]: 576, xstate_sizes[2]: 256 Apr 09 01:38:39 bottegadelbarbieri kernel: x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, using 'standard' format. Apr 09 01:38:39 bottegadelbarbieri kernel: BIOS-provided physical RAM map: [...]
[...] Apr 09 01:38:39 bottegadelbarbieri kernel: Run /init as init process Apr 09 01:38:39 bottegadelbarbieri kernel: with arguments: Apr 09 01:38:39 bottegadelbarbieri kernel: /init Apr 09 01:38:39 bottegadelbarbieri kernel: splash Apr 09 01:38:39 bottegadelbarbieri kernel: with environment: Apr 09 01:38:39 bottegadelbarbieri kernel: HOME=/ Apr 09 01:38:39 bottegadelbarbieri kernel: TERM=linux Apr 09 01:38:39 bottegadelbarbieri kernel: BOOT_IMAGE=/vmlinuz-5.8.0-48-generic [...] Apr 09 01:38:39 bottegadelbarbieri kernel: EXT4-fs (dm-1): mounted filesystem with ordered data mode. Opts: (null) Apr 09 01:38:39 bottegadelbarbieri systemd[1]: Inserted module 'autofs4' Apr 09 01:38:39 bottegadelbarbieri systemd[1]: systemd 245.4-4ubuntu3.4 running in system mode. (+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN2 -IDN +PCRE2 default-hiera rchy=hybrid)
In sostanza:
parte il kernel —> vmlinuz-5.8.0-48-generic
parte systemd —> systemd 245.4-4ubuntu3.4
il filesystem ext4 si ordina in maniera automatica —> autofs4
partono tutti gli altri processi
Elenco dei processi
Premettendo che pid – process id – di ogni processo è direttamente relazionato alla fase di start del sistema, proviamo a visualizzare i primi 10:
bottega@bottegadelbarbieri / ps -aux |head -n 10 USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 1 0.0 0.5 102268 11784 ? Ss 01:38 0:01 /sbin/init splash root 2 0.0 0.0 0 0 ? S 01:38 0:00 [kthreadd] root 3 0.0 0.0 0 0 ? I< 01:38 0:00 [rcu_gp] root 4 0.0 0.0 0 0 ? I< 01:38 0:00 [rcu_par_gp] root 6 0.0 0.0 0 0 ? I< 01:38 0:00 [kworker/0:0H-kblockd] root 9 0.0 0.0 0 0 ? I< 01:38 0:00 [mm_percpu_wq] root 10 0.0 0.0 0 0 ? S 01:38 0:00 [ksoftirqd/0] root 11 0.0 0.0 0 0 ? I 01:38 0:00 [rcu_sched] root 12 0.0 0.0 0 0 ? S 01:38 0:00 [migration/0]
Come si vede, /sbin/init è il primo a partire, ed effettivamente il suo pid è il numero1.
USER — > root —>> utente
PID —> 1 —>> numero processo
%CPU —> 0.0 —>> utilizzo cpu
%MEM —> 0.2 —>> utilizzo memoria
VSZ —> 169636 —>> utilizzo memoria viruale
RSS —> 11424 —>> utilizzo ram virtuale
TTY —> ? —>> presenza di una console [in questo caso nessuna]
STAT —> Ss >> stato del processo [in questo caso il leader]
START —> May12 >> partenza – giorno
TIME —> 0:05 >> partenza – ora
COMMAND —> /sbin/init splash >> comando
I Processi al lavoro
Per vedere come stanno lavorando i processi live, c’e’ un tool molto comodo, che esiste dall’alba dei sistemi ux*, e si chiama top. Proviamo a vedere le prime 20 linee del suo output:
bottega@bottegadelbarbieri / top | head -n 20 top - 02:36:45 up 58 min, 1 user, load average: 0.00, 0.00, 0.00 Tasks: 121 total, 1 running, 120 sleeping, 0 stopped, 0 zombie %Cpu(s): 0.0 us, 0.0 sy, 0.0 ni,100.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st MiB Mem : 1987.3 total, 1249.9 free, 197.2 used, 540.2 buff/cache MiB Swap: 980.0 total, 980.0 free, 0.0 used. 1613.2 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 1 root 20 0 102268 11784 8564 S 0.0 0.6 0:01.17 systemd 2 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kthreadd 3 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 rcu_gp 4 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 rcu_par_gp 6 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 kworker/0:0H-kblockd 9 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 mm_percpu_wq 10 root 20 0 0 0 0 S 0.0 0.0 0:00.05 ksoftirqd/0 11 root 20 0 0 0 0 I 0.0 0.0 0:00.08 rcu_sched 12 root rt 0 0 0 0 S 0.0 0.0 0:00.02 migration/0 13 root -51 0 0 0 0 S 0.0 0.0 0:00.00 idle_inject/0 14 root 20 0 0 0 0 S 0.0 0.0 0:00.00 cpuhp/0 15 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kdevtmpfs 16 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 netns bottega@bottegadelbarbieri /
Dunque nel nostro sistema ci sono:
121 —>> processi
1 —>> processo attivo
120 —>> processi dormienti
0 —>> processi inattivi
0 —>> processi attivi, ma interrotti dal sistema
Che ci siano 121 processi lo possiamo vedere anche dal comando ps. Infatti, facendo un word count, e omettendo la prima linea (l’header del comando) abbiamo:
bottega@bottegadelbarbieri / ps -aux |grep -v USER |wc -l 121
Ci siamo detti che i processi fanno operazioni nel sistema, dunque dovrebbe essere possibile visualizzare quanta cpu e memoria utilizzano, da dove arrivano, e altre informazioni. Prendiamo dunque ad esempio il processo xfwm4, parte del pacchetto xfce che provvede a creare il desktop sul quale stiamo lavorando.
bottega@bottegadelbarbieri ~ pidof xfwm4 2319
Da dove arriva?
bottega@bottegadelbarbieri ~ pstree -s 2319
systemd───lightdm───lightdm───xfce4-session───xfwm4───6*[{xfwm4}]
Quante risorse sta occupando?
bottega@bottegadelbarbieri ~ pidstat 4 2 -p 2319 Linux 5.8.0-48-generic (bottegadelbarbieri) 09/04/21 _x86_64_ (1 CPU) 02:48:34 UID PID %usr %system %guest %wait %CPU CPU Command 02:48:38 1000 2319 0.00 0.00 0.00 0.25 0.00 0 xfwm4 02:48:42 1000 2319 0.25 0.25 0.00 0.75 0.50 0 xfwm4 Average: 1000 2319 0.12 0.12 0.00 0.50 0.25 - xfwm4
Come possiamo vedere:
– e’ un processo
– proviene dall’esecuzione prima di systemd e poi lightdm
– occupa poche risorse
E’ interessante notare come il sistema conservi memoria di tutto. Muovendoci infatti in /proc/2319 – proc come processo e 2319 come numero del processo – possiamo trovare:
bottega@bottegadelbarbieri ~ cd /proc/2319 bottega@bottegadelbarbieri /proc/2319 ls -lha |head -n 20 total 0 dr-xr-xr-x 9 bottega bottega 0 Apr 9 02:43 . dr-xr-xr-x 217 root root 0 Apr 9 01:38 .. -r--r--r-- 1 bottega bottega 0 Apr 9 02:59 arch_status dr-xr-xr-x 2 bottega bottega 0 Apr 9 02:59 attr -rw-r--r-- 1 bottega bottega 0 Apr 9 02:59 autogroup -r-------- 1 bottega bottega 0 Apr 9 02:59 auxv -r--r--r-- 1 bottega bottega 0 Apr 9 02:59 cgroup --w------- 1 bottega bottega 0 Apr 9 02:59 clear_refs -r--r--r-- 1 bottega bottega 0 Apr 9 02:43 cmdline -rw-r--r-- 1 bottega bottega 0 Apr 9 02:59 comm -rw-r--r-- 1 bottega bottega 0 Apr 9 02:59 coredump_filter -r--r--r-- 1 bottega bottega 0 Apr 9 02:59 cpu_resctrl_groups -r--r--r-- 1 bottega bottega 0 Apr 9 02:59 cpuset lrwxrwxrwx 1 bottega bottega 0 Apr 9 02:43 cwd -> /home/bottega -r-------- 1 bottega bottega 0 Apr 9 02:59 environ lrwxrwxrwx 1 bottega bottega 0 Apr 9 02:43 exe -> /usr/bin/xfwm4 dr-x------ 2 bottega bottega 0 Apr 9 02:43 fd dr-x------ 2 bottega bottega 0 Apr 9 02:59 fdinfo -rw-r--r-- 1 bottega bottega 0 Apr 9 02:59 gid_map -r-------- 1 bottega bottega 0 Apr 9 02:59 io -r--r--r-- 1 bottega bottega 0 Apr 9 02:59 limits -rw-r--r-- 1 bottega bottega 0 Apr 9 02:59 loginuid dr-x------ 2 bottega bottega 0 Apr 9 02:59 map_files -r--r--r-- 1 bottega bottega 0 Apr 9 02:43 maps -rw------- 1 bottega bottega 0 Apr 9 02:59 mem -r--r--r-- 1 bottega bottega 0 Apr 9 02:59 mountinfo -r--r--r-- 1 bottega bottega 0 Apr 9 02:59 mounts [...]
Se ve lo state domandando, no, non ci sono errori. Su Linux tutto è considerato come un file, anche i processi. È una storia informatica che si tramanda dal papa’ di Linux. Quindi si, un processo su Linux è tecnicamente un file. Questa informazione ci sarà utile quando andremo a esplorare la struttura del filesystem. Tenetela a mente.
Alla prossima settimana!
jolek78
| >> | Indice | << |
| Puntata 6 | < > | Puntata 8 |
Il logo “Tux Linux” e’ stato realizzato e distribuito dall’artista deiby-ybied su Deviantart in licenza Creative Commons BY-NC-SA 3.0
