Quando ci sono problemi, potrebbe essere utile capire cosa succede sotto le copertine per firmare un utente in una sessione della GUI e ottenere un Unity (o un altro gestore di finestre) per far apparire un desktop.
Quando ci sono problemi, potrebbe essere utile capire cosa succede sotto le copertine per firmare un utente in una sessione della GUI e ottenere un Unity (o un altro gestore di finestre) per far apparire un desktop.
Ecco la catena di eventi:
Il kernel avvia il processo di init come processo numero 1. Questo è upstart per Ubuntu 12.04.
I lavori di Upstart sono in /etc/init/
Pagina man: man init
Log: log del kernel ( dmesg ; copiato in /var/log/syslog ), /var/log/upstart/jobname.log , altri registri determinati dai lavori avviati.
Fonte: /etc/init/lightdm.conf
Il lavoro di upstart esegue /usr/sbin/lightdm . Probabilmente possiamo aspettarci che questo venga convertito in un'unità di servizio systemd nel tempo.
Pagina man: man lightdm
, Inoltre: Wiki di Ubuntu: LightDM
Registri:
/var/log/syslog
/var/log/lightdm/lightdm.log
/var/log/lightdm/*
## for PAM:
/var/log/auth.log
## for the Xorg X server:
/var/log/Xorg.0.log
Fonte: man lightdm e /var/log/lightdm/lightdm.log
lightdm get è iniziato abbastanza tardi nel processo di init; Ad esempio, il sistema dbus deve essere già avviato, il filesystem deve essere pronto e il sistema di visualizzazione grafica deve essere pronto.
lightdm crea un file xauthority e quindi avvia X, avviandolo su VT 7, il terminale virtuale che si ottiene premendo Alt + Ctrl + F7 . Quando X viene avviato, i segnali lightdm per il programma splash screen di Plymouth vengono chiusi. È essenziale che ciò avvenga dopo che tutti i tty (1-6) sono iniziati.
Dal luglio 2013 gli elementi di supporto di Mir sono stati aggiunti a lightdm, ma quelli non sono utilizzati di default per i sistemi desktop dal 14.04.
X tenta di utilizzare i driver più avanzati possibili. I suoi driver sono caricati da /usr/lib/xorg/modules/ . Si noti che esistono sia i driver del kernel che i driver xorg per molti dispositivi, con i driver xorg che usano quasi certamente quelli del kernel. dri e glx sono caratteristiche importanti, in particolare, per la grafica avanzata ad alte prestazioni. I log sono memorizzati per X in /var/log/Xorg.0.log .
Su questo "sedile" ci sono comunicazioni sul sistema dbus e vengono acquisiti eventuali nomi utente. lightdm usa X per disegnare lo schermo. unity-greeter è usato per aiutare nel processo.
Mentre selezioni i vari possibili ID utente, viene utilizzata l'immagine del backgound dell'utente.
lightdm prende il nome di potenziali window-manager / sistemi da /usr/share/xsessions/*.desktop .
Le informazioni sull'account vengono acquisite tramite il demone degli account accountsservice su dbus.
lightdm e il greeter usano PAM per autenticare l'utente. Una volta autenticato, PAM avvierà un demone gnome-keyring-daemon con il
- l'opzione login e la si nutre della password dell'utente in modo che possa sbloccare il portachiavi di accesso dell'utente, se presente. Vedi link e man 8 pam_unix per maggiori informazioni. PAM memorizza le informazioni del registro in /var/log/auth.log ed è controllato da /etc/pam.conf (quasi vuoto) e /etc/pam.d/* . In particolare, vedi /etc/pam.d/lightdm e /etc/pam.d/lightdm-autologin .
Una volta che l'utente è autenticato, i privilegi vengono eliminati e un file viene scritto in ~user/.dmrc che descrive la sessione. Ad esempio:
[Desktop]
Session=ubuntu
o
[Desktop]
Session=awesome
I file .desktop di /usr/share/xsessions/*.desktop ora determinano il resto della sequenza di avvio.
Ad esempio, ecco quello per Unity:
[Desktop Entry]
Name=Ubuntu
Comment=This session logs you into Ubuntu
Exec=gnome-session --session=ubuntu
TryExec=unity
Icon=
Type=Application
X-Ubuntu-Gettext-Domain=gnome-session-3.0
Lo script di shell /usr/sbin/lightdm-session viene eseguito con gli argomenti g nome-session --session=ubuntu
(sic .-- 'ubuntu', non 'unity')
Log:?
Registri errori: ~/.xsession-errors
Registri di processo avviati: ~/.cache/upstart/*
Fonte: /usr/sbin/lightdm-session
/usr/sbin/lightdm-session quindi procede come segue:
Esegui:
/etc/profile, $HOME/.profile /etc/xprofile $HOME/.xprofile e /etc/X11/Xresources , se esistono, carica la mappa tastiera con setxbmap usando il contenuto di
$HOME/.Xresources e /etc/X11/Xkbmap ; $HOME/.Xkbmap esistente e /etc/X11/Xmodmap $HOME/.Xmodmap ; esegue gli script Xsession in /etc/X11/xinit/xinitrc.d , utilizzando le opzioni in /etc/X11/Xsession.d/* .
Uno di questi avvia ssh-agent (ridondante), un altro esegue /etc/X11/Xsession.options . Un altro avvia sessione-dbus (sia ssh-agent che session-dbus come consentito nel file $HOME/.xsessionrc sopra). Questa sessione dbus è utile per le comunicazioni tra i processi relativi a questa sessione utente singola.
ssh-agent può tenere le chiavi ssh per la sessione se sono ssh-add 'aggiunte un po' di tempo durante la sessione, ma gnome-keyring-daemon fa la stessa cosa.
Xsession.options esegue /etc/X11/Xsession.d/50_check_unity_support e se non riesce esporta /usr/lib/nux/unity_support_test nell'ambiente in modo che LIBGL_ALWAYS_SOFTWARE=1 venga utilizzato per il rendering software del desktop.
A partire da Ubunu 13.10:
llvmpipe imposta la variabile /etc/X11/Xsession.d/00upstart su UPSTART .
1 controlla quella variabile e se imposta sostituti /etc/X11/Xsession.d/99upstart
agli altri elementi impostati su init --user . Pertanto, l'upstart in modalità utente avvia quei lavori avviati in $STARTUP . Uno di questi è /usr/share/upstart/sessions che avvia gnome-session.
A meno che non sia già stato fatto, finalmente lightdm-session avvia un gestore di finestre, o per unità, quanto sopra avvia il gestore di sessione di gnome session.
Sembra che la sessione lightdm assuma il tradizionale ruolo di xsession. La sua pagina man è al link . lightdm lo considera un session-wrapper.
Manpage: link
Registri:?
Sorgente: pagina man
gnome-session è usato per Unity, ma non per awesome di default, per esempio. Vedi i precedenti file .desktop.
gnome-session avvia il programma specificato da / usr / share / gnome-session / sessions / e avvia le applicazioni da ~ / .config / autostart / e / etc / xdg / autostart.
Ecco un esempio di / etc / xdg / avvio automatico:
$cat /etc/xdg/autostart/nm-applet.desktop
[Desktop Entry]
Name=Network
Comment=Manage your network connections
Icon=nm-device-wireless
Exec=nm-applet
Terminal=false
Type=Application
NoDisplay=true
NotShowIn=KDE;
X-GNOME-Bugzilla-Bugzilla=GNOME
X-GNOME-Bugzilla-Component=general
X-GNOME-Autostart-enabled=true
X-Ubuntu-Gettext-Domain=nm-applet
Un altro, /etc/xdg/autostart/gnome-keyring-ssh.desktop, avvia gnome-keyring-daemon con l'opzione --start, completando l'avvio di quel processo demone e memorizzando informazioni importanti su di esso nell'ambiente per potenziale utilizzo di ssh.
Da una ps aux list sembra che gnome-session avvii i window manager con dbus-launch.
Pagina man: link
Registri:?
Fonte: pagina man, esame file di configurazione
Ecco il file awesome.desktop in / usr / share / xsessions / utilizzato da lightdm-session:
[Desktop Entry]
Encoding=UTF-8
Name=awesome
Comment=Highly configurable framework window manager
TryExec=awesome
Exec=awesome
Come puoi vedere, la voce fa semplicemente funzionare l'impressionante window manager. Legge i propri file di configurazione, incluso /etc/xdg/awesome/rc.lua dal fantastico pacchetto. Può essere configurato con $ HOME / .config / awesome / rc.lua.
Fonte: esame del file di configurazione
Ecco il file ubuntu.desktop in / usr / share / xsessions /:
[Desktop Entry]
Name=Ubuntu
Comment=This session logs you into Ubuntu
Exec=gnome-session --session=ubuntu
TryExec=unity
Icon=
Type=Application
X-Ubuntu-Gettext-Domain=gnome-session-3.0
Questo avvia la sessione di gnome descritta in /usr/share/gnome-session/sessions/ubuntu.session
Questo è il file:
[GNOME Session]
Name=Ubuntu
RequiredComponents=gnome-settings-daemon;
RequiredProviders=windowmanager;panel;
DefaultProvider-windowmanager=compiz
DefaultProvider-panel=compiz
IsRunnableHelper=/usr/lib/nux/unity_support_test
FallbackSession=ubuntu-2d
DesktopName=Unity
Il programma IsRunnableHelper eseguito da gnome-session in 12.04 determina se è possibile eseguire l'unità o se verrà eseguito ubuntu-2d. Se commette un errore e dice che l'unità può funzionare e non può, ci sono problemi. Scegli ubuntu-2d manualmente in lightdm se ti capita. Mentre restituisce un codice di ritorno, possiamo vedere cosa sta facendo eseguendolo con l'opzione -p.
$ /usr/lib/nux/unity_support_test -p
OpenGL vendor string: X.Org R300 Project
OpenGL renderer string: Gallium 0.4 on ATI RS690
OpenGL version string: 2.1 Mesa 8.0.2
Not software rendered: yes
Not blacklisted: yes
GLX fbconfig: yes
GLX texture from pixmap: yes
GL npot or rect textures: yes
GL vertex program: yes
GL fragment program: yes
GL vertex buffer object: yes
GL framebuffer object: yes
GL version is 1.4+: yes
Unity 3D supported: yes
Per 12.10 e versioni successive l'hardware non supportato utilizza il software llvmpipe per rendere ciò che l'hardware non può. Il suo file di configurazione è più semplice di quanto sopra. Vedi sopra per come è abilitato.
Possiamo vedere dai file sopra che gnome-session deve avviare il demone delle impostazioni e avviare compiz per l'esecuzione di un gestore di finestre e di eventuali pannelli.
Pagina man: link
Registri:?
Fonte: link , esame del file system
Una volta avviato il compiz, vengono eseguiti vari plugin. Prima delle 12.10 vengono utilizzate le impostazioni di gnome per definirle. Possono essere modificati con ccsm (compiz config settings manager) o con gconf-editor. Le impostazioni del plugin sono memorizzate in app / compiz-1 / general / screen0 / options in active_plugins. I duplicati mi hanno indotto ad avere segfaults con compiz. Questi sono memorizzati nella directory home dell'utente nella directory ~ / .gconf / organizzata come sopra. I valori effettivi sono memorizzati in% file gconf.xml lì.
Dal 12.10 questi plugin sono memorizzati in binario nel tuo file ~ / .config / dconf / user. Il metodo dconf o gsettings di memorizzazione delle impostazioni è più recente. Puoi visualizzare tutte queste impostazioni con gnome-session.conf .
Unityshell è uno di questi plugin. Usa il progetto nux come toolkit incorporato. Le immagini vengono tratte su trame nello spazio tridimensionale con valori di trasparenza specificati. Questi vengono elaborati da Compiz e inviati a llvm oa driver di grafica avanzati per avere i componenti grafici dell'hardware grafico del computer in composito e renderli. In genere, questo è diverso dal rendering delle immagini direttamente su un framebuffer come è stato fatto più tradizionalmente. Questa complicata catena di eventi è ciò che richiede driver più avanzati e, a volte, richiede l'uso di driver grafici proprietari in Ubuntu.
Leggi altre domande sui tag unity lightdm gnome-session