I've been trying to troubleshoot a friend's newly-installed AntiX setup. For some reason gksu insists on running in su rather than sudo mode which means she can't use the AntiX control centre (I haven't given her the root password because we both agree that she isn't confident enough to use it safely).

We have tried using gksu-properties to reset gksu to sudo and this changes the properties file under .gconf, but it keeps setting itself back again. Running gksu from the terminal gives error messages that suggest an absent dbus. There is a system dbus running of course, but I expect what it's looking for is a session dbus. And I don't know enough about dbus to find out where that comes from.

I've just looked at my own AntiX system, which runs on a laptop. Running "ps ax|grep dbus" shows five different dbus processes running in addition to the system daemon. She has none of those in her ps list.

When answering, please bear in mind that I only have occasional access to this machine so I can't carry out any investigatory commands immediately.

Are you sure that's what you want? If I remember correctly gksu will need the root password, but gksudo will ask for the user's password. In other words gksu is akin to running 'su -c "some command"' and gksudo like 'sudo "some command"'.

That's how it used to be, but they combined the two programs some time ago. I have AntiX running on my laptop and the AntiX-specific menus use gksu in their scripts, but it runs as gksudo. That's what I'm trying to restore for my friend.

That sounds a bit distribution-specific and complicated. It might not be ideal, but if there are only a few commands needed to be run with privilege, would using /etc/sudoers be an option?

I was just trying to read some on gksu and it looks as though it's no longer maintained upstream. If it's not working as it should, you should probably file a bug with your distribution. On my BLFS system I've built it from source and it works fine, but then again I don't use systemd either (or much dbus for that matter, apart from desktop environments).

It's very much distribution-specific! The AntiX desktops are based on icewm or fluxbox with slim as display manager and menus constructed from a mixture of python-gtk and bash scripts. Normally they work pretty seamlessly.

At the moment, my friend is doing precisely what you suggested: she opens a terminal and uses sudo to do her updates. But obviously that's a sticking plaster solution and I would prefer to get the menus working again.

I'm aware that Debian has dropped gksu. slim is an orphan too, I believe. But this is AntiX; it's designed for old computers so why shouldn't it maintain and use old software?

In any case, I don't believe this is really a gksu problem; it's a dbus problem. gksu is gnome software after all, so it has the gnome proclivity for introducing unnecessary complications. Apparently it needs a session dbus to function properly and we don't have one.

After googling, I have come across two possible things to try. We may be lacking the X-bindings for dbus (dbus-x11). This was a messed-up partial install and we had to add a lot of things post-facto. So I have given her instructions on how to install this package if it isn't already there. We may also need to check the ownership of her .dbus directory. I was doing a lot of work as root in her home directory and there may have been a change of ownership. In which case dbus-launch won't be able to find the correct dbus address.

Postscript: I just got an email from my friend. Apparently it works now. So the absence of dbus-x11 was the problem.