important technical questions related to DBUS support

[JanuszChmiel]

I Am wondering. If there is no build in limitation in proot or in Android 8.0 and newer how many Unix sockets can be created at a time? Or how many files can be opened at The same time? Because I have a notion, that in some cases, some app can not connect to Dbus socket, because some file handling software routines are overloaded in some cases. And this is making Dbus The notion, that some Dbus socket files can not be accessed so it is causing Dbus socket connection errors. Would somebody of us try to analyse, fi there is some Proot code, which would work faster or better to handle sockets?

[michalbednarski]

One thing you might run into is that when uid faking is enabled in proot, in order to connect to dbus both dbus-deamon and client must be running under same proot instance. (Otherwise you'd get error similar to one described in #36)

Unfortunately without details I can only guess what can be problem; I'd need at least exact error message. (Also, on more generic note, I'd suggest reading How to Report Bugs Effectively essay by Simon Tatham)

Usual Linux resource limits apply, but I doubt you'd run into them while using normal GUI apps

[JanuszChmiel]

The situation related to Dbus support vari among distros. The best situation have existed when I have used Ubuntu 19.04 ARM64 Bit edition. Newer Dbus have very probably some difference.

Thanks to some software magic, Fedora can not work with Dbus. dbus-launch appname & do not work at all. I Am still getting error message. Can not connect to The szstem Bus socket. The very similar situation exist when using Arch Linux. With difference, that dbus-launch appname & work. I think that The only issue is, that because Proot Linux distros can not use system services that in some cases, some apps want to communicate with Dbus system daemon not only on its user level.

To be more specific. dbus-launch mate-session & produces The error with mate-settings-daemon. I Am running original ArchLinux setup script from MR Rausty. I have latest updates installed. Mate-settings-daemon can not connected to systemd and it can not connect to Dbus socket. Socket file really exist. May be, that all those strange problems are also caused by The fact, that Dbus C code have been originally designed to to run perfectly on standard Linux environment.

[JanuszChmiel]

Here is model situation. I have started mate-session as non root user by typing xinit & dbus-launch mate-session & I have pressed left CTRL+m. I have redefined hot key to recall Mate desktop environment main manu from default ALT+F1 to CTRL+m

I have chosen logout. When I have pressed Enter key on my Bluetooth external keyboard I have got The following error

mate-session[27262]: WARNING: Could not connect to Systemd: Failed to connect to socket /run/dbus/system_bus_socket: Connection refused The similar problem is being reported by The mate-settings-daemon. As A results some settings can not be applied just after I change them. I must logout or terminate mate-session to get those settings to be reloaded.

I know, that I must be glad, that Dbus work much more better than on Fedora distro. Because on Fedora Dbus-launch do not help and apps which need Dbus simply refuse to work at all.

I have added regular user by typing addusr janusz

I have also root user acoount and Alarm account which is being created by ArchLinux setup shell script from Mr Rausty.

Any help would be very welcomed. Does somebody of you know if there is some technique which would force Dbus binary to produce detailed debug output log? Thank you very much for yours advices.

[michalbednarski]

Could not connect to Systemd: Failed to connect to socket /run/dbus/system_bus_socket: Connection refused means that system dbus is not running (dbus-launch launches only session bus)

Chances are you won't do anything useful with system bus, if you really want to launch it:

1. You'd need to bind mount file with value 0 onto /proc/sys/kernel/cap_last_cap (otherwise dbus-daemon will get error while dropping capabilities and refuse to start)
2. Create /run/dbus directory in guest
3. Launch dbus-daemon --system

Anyway, after doing so if you still won't be able to connect to systemd (logind) instead of getting connection error, you'll get error that logind object is not available on bus (mate-session[22299]: WARNING: Could not connect to Systemd: Could not get owner of name 'org.freedesktop.login1': no such name)

[JanuszChmiel]

So if I understand you well, The best that I can do is to cimply ignore those error messages, because even if I would repair their causes I could get other errors.

To be honest, The most annoing issue is, that Firefox and Seamonkey do not cooperate with Orca screen reader. I only know, that this problem always become active when I install all dependencies which are needed by Gradio. To find The dependencies list I had to use community repo and WEB page with dependencies list table. So first what I had to do is to totally remove Arch Linux and I must say good bye my favourite Gradio. Since finding The cause why Seamonkey and Firefox can not work after installing Gradio dependencies list would be too complex to track it down. By The way, thank you very much for yours analysis and for yours advices.

[JanuszChmiel]

I have last advanced question to you, since you are one of The most advanced developers among Termux programmers. Why do you think, that Arch Linux can support DBUS atleast partially. And when somebody install Fedora 30 or 31 by using Proot, that dbus-launch can not initialize Dbus. And there is still issue with Dbus connection. In Arch Linux, Dbus-launch app really start session Dbus. But no in Fedora. Is it possible to setup Fedora so it would run similarly like Arch Linux, or there is deep problem directly inside Dbus compiled binary for Fedora which prevent Dbus from functioning?

I AM wondering, if it would be possible to make safe decision. PUtting Dbus binary from /usr/bin to /usr/bin of Fedora installation. So Dbus binary from Arch Linux would be used from Fedora. I know that my idea is not very good idea, because packaging managers will upgrade to The original Dbus version. I only need to find out The cause, Why Fedora is The only one distro, which can not support Dbus from Termux when running Proot.