The system bus works fine
(dbus-init-bus :system)
returns nil, as it should.
However, connection to the session bus
(dbus-init-bus :session)
raises
(dbus-error "No connection to bus" :session)
qdbus in the command line works just fine with both buses. It even
works from within eshell, if that is of any concern.
Neither emacs nor emacs --daemon connect.
Which version of Emacs are you using? One version (before 2012-05-25) only looks for the DBUS_SESSION_BUS_ADDRESS environment variable, while a more recent one uses a library function that also looks in ~/.dbus/session-bus I think.
Did you try this before running emacs:
eval $(dbus-launch)
export DBUS_SESSION_BUS_ADDRESS
Related
I'm setting up some new VNC servers. I already have this setup working with CentOS 6.3, although I'm not certain that this difference is the real problem.
One of the window managers I'm making available is fluxbox, but when I start it, I always get the following: Error: Couldn't connect to XServer. Here's my setup:
fluxbox: fluxbox-1.1.1-5.el6.x86_64
vnc : tigervnc-server-1.1.0-5.el6_4.1.x86_64
OS : CentOS 6.4
Note that I can start other window managers: Gnome, KDE, openbox, xfce4, etc.
I gutted my ~/.vnc/xstartup script so it only loads an xterm. Then, I tried running startfluxbox &, but still got the error. Obviously, VNC is working, since my xterm opened up OK. I can start firefox, another xterm or other app requiring X, and even fluxbox comes up, but it is worthless in its current state, since it is not connected to the X session.
What is fluxbox looking for? Are there some log files I can look at to give me some clues?
Thanks,
David
CentOS/RHEL 6.4 and up have upgraded libX11 and Xorg.
The $DISPLAY var handling has changed in libX11.
This one in particular is described in this git commit:
http://cgit.freedesktop.org/xorg/lib/libX11/commit/?id=f92e754297ec5fdb81068b56a4435026666224fa
we run our fluxbox with this script in our vnc configs now:
/usr/bin/fluxbox -display "$DISPLAY.0"
OK, I think I've figured out the problem, so I'm answering my own question.
In VNC, I usually specify a display number. (Note, however, that the problem occurs even if vncserver uses the first available display number.) So, I start the vncserver as:
vncserver :17
This should create an X session where my $DISPLAY is set to :17.0, but in CentOS 6.4, the $DISPLAY is set to :17 instead. Apparently, unlike other window managers, fluxbox is unable to handle this inaccuracy. The problem, then, was that fluxbox was trying to connect to :17 and was unable to do so.
My solution, as suggested by someone answering a different problem, was to set $DISPLAY as part of the invocation of fluxbox. So, in my ~/.vnc/xstartup file, I have:
DISPLAY=$DISPLAY.0 startfluxbox &
Note that this may not work for other releases of CentOS, so you might wish to test the release of the box you are using before adding the DISPLAY=... setting to the command.
I'm trying to access a remote davs server with emacs through tramp. I use the syntax
/davs:username#servername.fr: TAB
With ftp, this would ask for a password, connect to the server and open a completion list. But with davs Emacs gives the error Package tramp-gvfs' not supported`. Checking the messages buffer the error is linked to "completion--some" so I'm not sure it has to do with tramp itself. In the messages buffer I also see
Opening connection for davs using scpc... \
Tramp: Opening connection for davs using scpc...done
byte-code: Process died
I tried to specify the port number by adding #2078 after servername.fr but it didn't make any difference.
The connection works fine with my file managers (Nautilus and Thunar) so I suppose gvfs is set up properly on my system. Where else should I look?
You get this error message if Emacs is not compiled with DBus support, if it cannot connect to the session bus, or if neither gvfs-fuse-daemon nor gvfsd-fuse is running. (See the definition of tramp-gvfs-enabled.)
I seem to remember that I had to start gvfs-fuse-daemon manually, but I'm not sure exactly what I did to get it work; this was a long time ago on a different computer... Hopefully someone else can come up with a more complete answer.
I have a large repository of C++ code on a remote cluster (linux OS). When I need to work on this code from my home computer (Ubuntu OS), I try to access these codes through emacs on X windows. However the X window connection is very slow making the editing a painful process. So I sometimes move files manually between my local drive and remote cluster to edit the files. My question is: is there a way to configure my local emacs, such that when I edit the file in my local space, it would automatically be backed up in the cluster where it can then be compiled?
UPDATE:1
I installed TRAMP and it works well for servers that can be connected directly. However I also have servers which can be connected only when I activate VPN. How to provide the VPN information to TRAMP to connect to this server?
The other question I had was how to stop the TRAMP when it waits for prompts from remote shell without having to kill the whole emacs buffer.
This is typically a use case where TRAMP would be useful.
Instead of connecting to the server using SSH and opening Emacs there with X forwarding, run Emacs on your box and open your files remotely using TRAMP. For example:
C-xC-f/ssh:user#host:/remote/path/to/the/fileRET
This way, your Emacs process runs locally, but all file operations (e.g. save, revert, ...) are forwarded to the server, and all shell commands issued from TRAMP buffers also run on the remote server (this includes M-x compile)
UPDATE:1
When TRAMP hangs waiting for a remote shell prompt (which tends to happen frequently for reasons which are still obscure to me), I usually kill the underlying ssh process (htop with tree-like view is a good tool to do this) . TRAMP notices this and automatically respawns the killed process to resume operations.
Wouldn't it be easier to run Emacs in a console on the remote server? All Emacs functions can be access via the keyboard and once you get used to the key combinations it usually works out faster.
That way you will be running faster than forwarding an X session - running in a console is what Emacs was designed for.
As an added bonus - if you get used to using Gnu screen - http://www.gnu.org/software/screen/ you can pick up your sessions exactly as they were if the connection drops. In fact with screen you can shutdown your laptop at the end of the day - login over SSH the next day and pick up all your 'screens' exactly as they were the day before. This will include any open editors, debug sessions etc.
Gnu screen is available as a package on Debian and probably most Linux distributions.
I am trying to find a hook in Emacs, which should fire right before emacs server graceful shutdown.
I tried kill-emacs-query-functions, kill-emacs-hook, server-done-hook with elisp like :
(add-hook 'server-done-hook
'(lambda ()
(savehist-save)
)
)
... but none of them is called when OS shuts down, so history is not saved.
Maybe someone could give a hint?
P.S. I am on Gentoo Linux, emacs-vcs-23.2.9999 package, terminal only. For testing desired behaviour Emacs is stopped using start-stop-daemon utility.
Since Emacs 24.1, Emacs runs kill-emacs which runs the functions in kill-emacs-hook. So the question, and the rest of this answer, are only relevant to older versions.
The right place to run something before Emacs shuts down is either kill-emacs-query-function if you want to be able to cancel the shutdown or kill-emacs-hook if you don't. The problem you're facing is that your OS does not notify Emacs to shut down gracefully in a way that Emacs understands, or to look at it the other way, Emacs does not understand your OS's request to suht down gracefully.
A graceful way of shutting down Emacs 23 from the outside is to run emacsclient -n -e '(kill-emacs)'. That's obviously not a generic way of telling a program to shut down gracefully.
The normal way to shut down a process gracefully on unix is to send it a SIGHUP or SIGTERM signal. Unfortunately, Emacs treats almost all signals as fatal, and only runs an emergency auto save and no lisp code when it receives them. This is not configurable from lisp. A different behavior has been requested, but turned down.
A partial workaround (found here) is to run session saving hooks in delete-frame-functions. This hook is likely to be run before the system shutdown sequence, either when you close your last frame or when the X server dies (taking your terminals with them if you run Emacs in a terminal). Make sure you don't run the hook that kills the server in delete-frame-functions.
By the way, if you were going to use this exact hook, note that your code is a complicated way of writing (add-hook 'server-done-hook 'savehist-save), and that's not useful since there's already savehist-autosave in kill-emacs-hook.
I have seen a few suggestions on making emacs portable (on Windows). I have this in my site-start.el:
(defvar program-dir (substring data-directory 0 -4))
(setq inhibit-startup-message t)
(setenv "HOME" program-dir)
I changed the HOME variable so that not only my .emacs init files (and other init files) are read, but everything generated by emacs will stay in the program directory, not needing me to specify the path for everything one by one.
Well this works well but the emacs server is not working; I get error message "no connection could be made because target machine actively refused it." If I don't change my HOME var then emacs server works. Is there way to fix this?
Quoth the Emacs manual:
When you start the Emacs server (by calling server-start), Emacs creates a file with information about TCP connection to the server: the host where Emacs is running, the port where it is listening, and an authentication string. emacsclient uses this information if it needs to connect to the server via TCP. By default, the file goes in the ~/.emacs.d/server/ directory. You can specify the file name to use with the `-f file' or `--server-file=file' options, or by setting EMACS_SERVER_FILE environment variable to the file name.
In other words: wherever you're calling emacsclient from, you'll have to tell it to use the file in ${program-dir}/.emacs.d/server/, either with -f or setting the EMACS_SERVER_FILE environment variable. (In the environment in which you're starting emacsclient, not within Emacs.)
[You could also tell Emacsclient to look in the right place with -s for "socket", but that doesn't work on Windows. And on Unixes (at least on Mac OS X with Aquamacs) the socket would be somewhere like /tmp/emacs501/server (501 is my UID).]
[Oh, BTW, take a look at this question: How can I have a portable Emacs? Maybe something will help you, or maybe you have something to add to it :-)]
There is an initial packaging of a Portable Apps version of emacs 23.2 here. Initial test works here.