SSH'nin çıkışta asılı kalmasını önlemek için D-Bus ve SSH X-Yönlendirme nasıl yapılandırılır?

X11 Yönlendirme ve SSH üzerinden çeşitli Gnome uygulamaları çalıştırmaya çalışıyorum. Bazı uygulamalar önce 'dbus-launch' uygulamasının doğmasına neden olur. Sorun, X uygulamasından çıkıldığında dbus-başlatmanın kapanmaması ve bu nedenle SSH oturumunun düzgün bir şekilde kapatılabilmesi için öldürülmesi gerektiğidir.

Sorunun X / Gnome uygulamalarının ana mesaj veri yolu arka plan programına bağlanamayacağını ve bu nedenle kendi kopyalarını başlatmaları gerektiğini varsayalım. Bunu nasıl düzeltebilirim? Yoksa neyi özlüyorum?

İşte bir örnek. X11 Yönlendirme etkin, tüm iyi çalışıyor gibi görünüyor.

[me@host ~]$ gnome-calculator &
[1] 4803

(burada gcalctool programı başlatılır ve kaldır X sunucumda görüntülenir (Xming))

[me@host ~]$ ps
  PID TTY          TIME CMD
 4706 pts/0    00:00:00 bash
 4803 pts/0    00:00:00 gnome-calculator
 4807 pts/0    00:00:00 dbus-launch
 4870 pts/0    00:00:00 ps

(şimdi, uzak oturumda gcalctool uygulamasını kapattıktan sonra)

[me@host ~]$ ps
  PID TTY          TIME CMD
 4706 pts/0    00:00:00 bash
 4807 pts/0    00:00:00 dbus-launch
 4898 pts/0    00:00:00 ps

Dbus-başlatmanın hala etkin olduğunu unutmayın. Ve en kötü yanı, SSH bağlantısının öldürülünceye kadar düzgün kapanmasını önler.

Burada görüldüğü gibi, sistem genelinde mesaj arka plan programının çalıştığını unutmayın:

[me@host ~]$ ps ax
 4696 ?     Ssl   0:00 dbus-daemon --system

Burada ne eksik? Bu davranışı daha önce hiç görmedim. Muhtemelen, sadece mesaj veri yolu arka plan programına engelsiz bağlanabilen uygulamalar gördüm mü? Cevaplar için / etc / dbus-1'e baktım, ama ne aradığımı bilmiyorum.

Yardımınız için şimdiden teşekkür ederiz.

[DÜZENLE]

Tamam, ortak bir sorun yaşadığımın farkındayım. Bu oldukça yaygın bir davranış gibi görünüyor, ancak iyi bir çözüm yok. SSH asmak yaşıyorum çünkü dbus-lansmanı hala tty aktif. Ama görünüşe göre dbus-lansmanının sessizce gerçekleşmesi için iyi bir yol yok.

/Etc/X11/xinit/xinitrc.d/00-start-message-bus.sh dosyasına bakmak, "normal" bir X oturumunda ne olması gerektiği hakkında bir ipucu verir. Bu, elbette bir X uygulamasını uzaktaki bir X Sunucusuna çağırırken işe yaramaz.

Geçici bir çözüm olarak, bunu .bash_logout'uma ekledim:

# ~/.bash_logout
pkill -u $USER -t `tty | cut -d '/' -f 3,4` dbus-launch

Bu SSH oturumunun kapanmasına izin verir, ancak kludgy hisseder. Orada daha iyi çözümler var mı? Dbus engellemeden uzak X11 uygulamalarını çalıştırmanın doğru yolu nedir?

Lansman başına (1):

DBUS_SESSION_BUS_ADDRESS, D-Bus kullanmaya çalışan bir işlem için ayarlanmamışsa, varsayılan olarak işlem yeni bir oturum veri yolu başlatmak veya X ekranında mevcut veri yolu adresini bulmak için --autolaunch seçeneğiyle dbus başlatmayı başlatmayı dener. veya ~ / .dbus / session-bus / dosyasındaki bir dosyada

Bir otomatik başlatma gerçekleştiğinde, yeni bir otobüse başlamak zorunda kalan uygulama kendi küçük dünyasında olacaktır; çok sayıda otobüs hizmeti kullanmaya çalışırsa, tamamen yeni bir oturum başlatmaya son verebilir. Bu, uygulamaya ve ne yapmaya çalıştığına bağlı olarak yetersiz veya hatta tamamen kırılmış olabilir.

Otomatik başlatmanın iki yaygın nedeni vardır. Biri uzak bir makineye ssh.

Görünüşe göre hile programa bulabilecek şekilde dbus-daemon'u önceden başlatmaktır. Kullanırım:

[me@host ~]$ dbus-launch --exit-with-session gnome-terminal

gnome terminali dışında dbus-daemon'u başlatır ve gnome terminali içinde $ DBUS_SESSION_BUS_ADDRESS ayarlar .

Gnome terminalinden çalışan tüm X programları daha sonra güzel davranır ve gnome terminali çıktığında dbus-launch kendini temizler.

Sorunun bilinmeyen veya devam eden bir dbus oturumu nedeniyle gelip gelmediğini merak ediyorum.

Gerçekten de bir SSH oturumu açıkken bir dbus oturumu başlatmaz. Bazı programlar başlatabilir, ancak daha sonra oturum bunu bilmez (bu nedenle kapatamaz).

Dbus oturumu hakkında bilgi sahibi olmamanız, bu programların dbus kullandığını ancak kendi başlarına başlatmadığı programların da sorun yaşayacağı anlamına gelir.

dbus bölümleri makine başına ve X11 ekranı içindir. Bilgileri $ HOME / .dbus / session-bus / dizininde saklanır - ancak burada başvurulan işlem kapatılabilir, bu nedenle dbus başlatma gerekip gerekmediğini belirlemek için ekstra bir kontrol gereklidir. Daha sonra, orada değişkenler oturuma ihraç edilir.

Sonra bir cazibe gibi çalışır :)

Aşağıdakileri .bash_profile dosyama koydum:

# set dbus for remote SSH connections
if [ -n "$SSH_CLIENT" -a -n "$DISPLAY" ]; then
    machine_id=$(LANGUAGE=C hostnamectl|grep 'Machine ID:'| sed 's/^.*: //')
    x_display=$(echo $DISPLAY|sed 's/^.*:\([0-9]\+\)\(\.[0-9]\+\)*$/\1/')
    dbus_session_file="$HOME/.dbus/session-bus/${machine_id}-${x_display}"
    if [ -r "$dbus_session_file" ]; then
            export $(grep '^DBUS.*=' "$dbus_session_file")
            # check if PID still running, if not launch dbus
            ps $DBUS_SESSION_BUS_PID | tail -1 | grep dbus-daemon >& /dev/null
            [ "$?" != "0" ] && export $(dbus-launch) >& /dev/null
    else
            export $(dbus-launch) >& /dev/null
    fi
fi

notlar: hostnamectl, systemd'nin bir parçasıdır ve makine kimliğini almayı sağlar dbus-launch istediğimiz değişkenleri görüntüler; kullanarak export $(dbus-launch)dbus-launch çıktısını alır ve değişkenleri dışa aktarabiliriz

etkileşimli olmayan oturumlarda yapılmasını istiyorsanız (örn. ssh'den bir komut çalıştırırken) .bashrc içine koymayı deneyin (ancak bashrc'nin EVEERY açık kabuğunda yürütüldüğüne dikkat edin)

Uzak bir X komutunu çalıştırmaya ve X aracı çıktıktan sonra oturumdan çıkmaya çalışırken aynı sorunu yaşadım.

Bu yüzden koşmak istedim

ssh -X user@remotehost "firefox -no-remote"

Ama kullanmak zorunda kaldı:

ssh -X user@remotehost 'export \`dbus-launch\`; dbus-launch firefox -no-remote; kill -TERM $DBUS_SESSION_BUS_PID'

Firefox'u kapattıktan sonra bu ssh oturumunu da kapatır.

Güncelleme :

Bu, sunucuda bir sürü dbus-daemon işlemi bırakıyor gibi görünüyor, bu yüzden bu en uygun değil, her iki hesapta --ex---session eklenmesi yardımcı olmuyor, çünkü bu orijinal davranışı geri döndürüyor

Güncelleştirme 2 : Bu ben, tek tırnak (@lobo tarafından önerilen) ve eklerken çalışır kill -TERM $DBUS_SESSION_BUS_PIDönerdiği gibi, artık dbus-cini süreçleri öldürmek için Holgr Joukl dan https://blog.dhampir.no/content/how- dbus kullanıldığında çıkışta asılı kalmasını önlemek için ssh-x )