Re: [gentoo-user] meld - GConf Error: Client failed to connect to the D-BUS
On Sunday 01 Feb 2015 00:18:40 Adam Carter wrote: If you've su'd to root, try 'su -' instead. Thank you, that was it? What difference does it make and why on some boxes it has to be su - and on others simple su works. Read 'man su'. I dont really understand this stuff well enough, but a 'login shell', that is, one started by /bin/login, is setup with a different environment to a shell that's started by su (or by, say, cron). This is why a shell command or script may work for you when you're logged in, but not if you run it from cron. I'm sure other's can explain it more correctly and fully. When you follow su with - it will login into the pwd of /root. Without - you will find yourself in the same directorate you happened to be when you ran su. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] meld - GConf Error: Client failed to connect to the D-BUS
On 01/02/2015 02:18, Adam Carter wrote: If you've su'd to root, try 'su -' instead. Thank you, that was it? What difference does it make and why on some boxes it has to be su - and on others simple su works. Read 'man su'. I dont really understand this stuff well enough, but a 'login shell', that is, one started by /bin/login, is setup with a different environment to a shell that's started by su (or by, say, cron). This is why a shell command or script may work for you when you're logged in, but not if you run it from cron. I'm sure other's can explain it more correctly and fully. This stuff is complex the first time you run into it. There are three kinds of shell depending on how you start them: login shell, interactive shell, and non-interactive shell. When you get a login prompt on the console and type your username/password, you get a login shell. bash will have done it's full complete start-up routine, will have read all the .bashrc and.profile files, and will set up your default environment just the way you like it. If you then type say vi at the command line, bash will launch it. vi does not try and set up a complete new environment for you - what would be the point? the shell already did it for you. So if you are at a bash prompt, and type bash, the running bash will start a new bash but won't do the whole startup routine for you (exactly the same way vi also doesn't try do it). The kind of bash shell is called an interactive shell, and it's different from a login shell. It's called interactive because you get a prompt, you can type stuff at the keyboard and get a response on the screen. A non-interactive shell is what a daemon/service like cron gets when it starts bash to run some program in the background. Almost all programming languages have an exec() function where you can run shell commands - these shells are also non-interactive. Why non-interactive? Because a daemon can't type stuff the keyboard, doesn't have a screen, and doesn't need $PATH set. It's a program, it doesn't need cute shortcuts. When you run su you might want an interactive shell, or you might want a login shell. Maybe you want to quickly run a command as the effective ID of the apache user, but don't need to change your entire environment. You run that as su Maybe you want to run su and log in as root to do a whole lot of maintenance. You decide you need root's full setup with PATH and everything else for this, so you run su - (the - means start a login shell) Well, OK, that's how it SUPPOSED to work. Usually it doesn't because distros decide to be clever. The files bash reads when it starts follow a convoluted path (see INVOCATION in man bash) and your average user gets confused. So distros helpfully make it easy for the user and rig it so that when you start an interactive shell, it goes and reads all the startup files anyway. So you don't get an interactive shell, you get a full-blown login shell! So how do you get an interactive shell in a distro like that? Well, errr, you don't. This explains the different behaviours of su vs su - between distros. Some, like SuSE have rigged it so there's no difference. Gentoo doesn't do that because a) Gentoo sticks closely to upstream and b) Gentoo users are not morons and don't need helpful distros dicking around with their shells. The topic of cron came up. A common issue is you run myscript.sh at the command line and it works. Run it in a cron as you and it doesn't work. Cron gets a non-interactive shell and $PATH is not set. So in cron, you must call it like this: /path/to/bin/myscript.sh In cron, it's always best to use fully-qualified paths to all files everywhere and always. Don't rely on startup profiles - those have always been to make life easier for human users, and were never intended to be used by system daemons. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] meld - GConf Error: Client failed to connect to the D-BUS
On 01/02/2015 17:07, Peter Humphrey wrote: On Sunday 01 February 2015 14:17:04 Alan McKinnon wrote: On 01/02/2015 02:18, Adam Carter wrote: If you've su'd to root, try 'su -' instead. Thank you, that was it? What difference does it make and why on some boxes it has to be su - and on others simple su works. Read 'man su'. I dont really understand this stuff well enough, but a 'login shell', that is, one started by /bin/login, is setup with a different environment to a shell that's started by su (or by, say, cron). This is why a shell command or script may work for you when you're logged in, but not if you run it from cron. I'm sure other's can explain it more correctly and fully. This stuff is complex the first time you run into it. ---8 [Much good advice] I think of it simply like this: su switches user, and that's all; su - gives you the full environment of the user you switch to. Indeed, that is the heart of it. Your version above is perfect for the tl;dr people :-) -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] meld - GConf Error: Client failed to connect to the D-BUS
On Sunday 01 February 2015 14:17:04 Alan McKinnon wrote: On 01/02/2015 02:18, Adam Carter wrote: If you've su'd to root, try 'su -' instead. Thank you, that was it? What difference does it make and why on some boxes it has to be su - and on others simple su works. Read 'man su'. I dont really understand this stuff well enough, but a 'login shell', that is, one started by /bin/login, is setup with a different environment to a shell that's started by su (or by, say, cron). This is why a shell command or script may work for you when you're logged in, but not if you run it from cron. I'm sure other's can explain it more correctly and fully. This stuff is complex the first time you run into it. ---8 [Much good advice] I think of it simply like this: su switches user, and that's all; su - gives you the full environment of the user you switch to. -- Rgds Peter.
Re: [gentoo-user] meld - GConf Error: Client failed to connect to the D-BUS
On Sunday 01 February 2015 18:00:23 Alan McKinnon wrote: On 01/02/2015 17:07, Peter Humphrey wrote: I think of it simply like this: su switches user, and that's all; su - gives you the full environment of the user you switch to. Indeed, that is the heart of it. Your version above is perfect for the tl;dr people :-) Well, it would be - look who suggested it! -- Rgds Peter.
Re: [gentoo-user] meld - GConf Error: Client failed to connect to the D-BUS
On 01/31/2015 05:29 PM, Joseph wrote: When I run meld as root I get a strange errors: what happens when you don't run as root? GConf Error: Client failed to connect to the D-BUS daemon: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken. do you have DBus installed/running? I've been doing a fair amount of coding with the DBus API for bossman, but sadly I feel no wiser on the various errors that it throws. The other things I can think of are: * GConf isn't installed/running * meld is looking for the session bus of your user, which is not accessible when running as root (maybe??? Not 100% sure on how session busses work...) If you run systemd, DBus is definitely running and I would imagine this would be a GConf error of some sort. If you're using OpenRC, check to make sure you have dbus and gconf enabled and running. Alec
Re: [gentoo-user] meld - GConf Error: Client failed to connect to the D-BUS
On Sun, Feb 1, 2015 at 9:29 AM, Joseph syscon...@gmail.com wrote: When I run meld as root I get a strange errors: GConf Error: Client failed to connect to the D-BUS daemon: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken. If you've su'd to root, try 'su -' instead.
[gentoo-user] meld - GConf Error: Client failed to connect to the D-BUS
When I run meld as root I get a strange errors: GConf Error: Client failed to connect to the D-BUS daemon: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken. -- Joseph
Re: [gentoo-user] meld - GConf Error: Client failed to connect to the D-BUS
On 02/01/15 11:06, Adam Carter wrote: On Sun, Feb 1, 2015 at 9:29 AM, Joseph [1]syscon...@gmail.com wrote: When I run meld as root I get a strange errors: GConf Error: Client failed to connect to the D-BUS daemon: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken. If you've su'd to root, try 'su -' instead. Thank you, that was it? What difference does it make and why on some boxes it has to be su - and on others simple su works. -- Joseph
Re: [gentoo-user] meld - GConf Error: Client failed to connect to the D-BUS
If you've su'd to root, try 'su -' instead. Thank you, that was it? What difference does it make and why on some boxes it has to be su - and on others simple su works. Read 'man su'. I dont really understand this stuff well enough, but a 'login shell', that is, one started by /bin/login, is setup with a different environment to a shell that's started by su (or by, say, cron). This is why a shell command or script may work for you when you're logged in, but not if you run it from cron. I'm sure other's can explain it more correctly and fully.
Re: [gentoo-user] meld - GConf Error: Client failed to connect to the D-BUS
On 01/31/15 17:57, Alec Ten Harmsel wrote: On 01/31/2015 05:29 PM, Joseph wrote: When I run meld as root I get a strange errors: what happens when you don't run as root? GConf Error: Client failed to connect to the D-BUS daemon: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken. do you have DBus installed/running? I've been doing a fair amount of coding with the DBus API for bossman, but sadly I feel no wiser on the various errors that it throws. The other things I can think of are: * GConf isn't installed/running * meld is looking for the session bus of your user, which is not accessible when running as root (maybe??? Not 100% sure on how session busses work...) If you run systemd, DBus is definitely running and I would imagine this would be a GConf error of some sort. If you're using OpenRC, check to make sure you have dbus and gconf enabled and running. dbus status show it is running. I don't have gconf. I'm using Xfce and OpenRC -- Joseph
