You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!

Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.

If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.

Having a problem logging in? Please visit this page to clear all LQ-related cookies.

Introduction to Linux - A Hands on Guide

This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.

Following is probably well-known by many, but it took me some time to figure it out, so I'll write it here for reference:

I wanted to disable D-Bus on my laptop, and all the stuff that it pulls in (ConsoleKit, PolicyKit, gconfd), however I found that "chmod ugo-x" on /etc/rc.d/rc.messagebus and /etc/rc.d/rc.consolekit has no effect, as D-Bus daemon would get started somehow anyway. So after some searching, I found it's possible to disable its launching by setting DBUS_SESSION_BUS_ADDRESS environment variable to some string that is not valid filesystem path (or something similar, as I tried with /dev/null and it worked too). Alternatively, one could of course just "chmod ugo-x /usr/bin/dbus-daemon".

I found that PulseAudio is not working afterwards, however here D-Bus seems just to be used by some PulseAudio modules, so I commented out loading Bluetooth and ConsoleKit modules in /etc/pulse/default.pa, and if works fine now.

If someone has alternate suggestions on how to achieve this, I'd like to hear.

I'm still somewhat confused how it get started in my case. Namely, I'm using Openbox. My machine boots into runlevel 3, and then I have .bash_login set up so that if I login at tty1, it would run xinit, that in turn would find in my ~/.xinitrc that it should exec openbox-session. The Openbox scripts don't mention dbus-launch, and according to pstree output, it doesn't seem to be active after X started. However, as soon as I start any GTK program (I'm using Emacs, Firefox and Xpdf - I think all of these are GTK3 by now), dbus-daemon would appear in the pstree output, accompanied by all the other fellas: ConsoleKit and PolicyKit daemons, gconfd daemon, and even some accessibility daemons in case Emacs launched.

I didn't dig but assume that these apps do use some mechanism to do so, like dbus-glib.

Yeah, probably. It seems to me that GTK is more "problematic" toolkit than Qt in the sense that the separation between the toolkit and the desktop environment that is based on the toolkit is more blurred, so applications written using the toolkit often inadvertently end up depending on corresponding desktop environment technologies.

In any case, it's early to tell but it seems that apps that I use work fine (admittedly, it's also rather small sample, as I actually spend most of my day in xterm) with the setup described above, so there is no need to recompile anything. Still, it would be nice if the whole thing was designed to be fully optional.

On Debian SID, I have dbus disabled by not installing dbus-user-session (it is recommended by the pulseaudio package), or dbus-x11, which automatically brings up dbus on X startup.

EDIT: Oops just realized this is a Slackware forum. Anyway, dbus-x11 is Debians' package containing dbus-launch, which is what programs use to automatically launch dbus. Just removing it ought to solve your unwanted dbus problems. If you still have problems with it on the (non-X) console, consider switching your init system (on Debian switch from using systemd-sysv to sysvinit-core).

Don't understand what the purpose to set 'i' attribute for executable. I mean what kind of process can change this file again to be executable? If there is such process I consider this as serious security gap. I mean say something is trying to run dbus-lunch - but can't - it should possible send signal - go sleep - or terminate with information in syslog - or its own log file - that something is missing. Such kind of things.