12

Maybe this is answered somewhere else, but I didn't see it.

I am running Ubuntu 14.04. When I SSH into my machine, for example:

ssh <user>@<machineip> notify-send "Hello"

I don't see anything on the monitor where I am logged into the machine. If I prefix notify-send with DISPLAY=:0.0 or DISPLAY=:0 nothing different happens. I just never see any notification on the current session.

Is there some trick/switch to getting this working?

In case this isn't clear, allow me to reiterate: From Computer A, I SSH into Computer B. Within the SSH session, I wish to execute notify-send to run on Computer B. I expect a growl-type notification to appear on the monitor of Computer B.

GAD3R
  • 66,769
aikeru
  • 245
  • For other people who find this as top result through Google, DISPLAY=:0 notify-send 'hello' worked for me (not for aikeru), try that before more complicated steps. – Mark Aug 03 '15 at 08:16

3 Answers3

11

I think you're confusing the various technologies and how they work. I wouldn't expect that the notification daemon from one system could send messages via SSH. Setting the $DISPLAY is how X11 sends the output from an application to another for displaying purposes, but the notify-send is sending an actual message to the notification daemon. This message is send using the libnotify library.

excerpt

libnotify is a library that sends desktop notifications to a notification daemon, as defined in the Desktop Notifications spec. These notifications can be used to inform the user about an event or display some form of information without getting in the user's way.

Source: https://developer.gnome.org/libnotify/

Per app approach

One method for joining the notify-send messages to your local system's notifier is to use a approach as outlined by this blog post titled: IRC notifications via SSH and libnotify. This approach would need to be customized per each type of notification that you'd want to tunnel back to your local notifier.

Tunneling libnotify over SSH

For a more general solution libnotify-over-ssh may be more what you're looking for.

excerpt

This is a client server perl script I wrote so that my server could essentially send libnotify messages to my local machine. I use this mainly with weechat but has a feature to make it more general. When calling the client with the weechat tag the server checks the name of the current focused window. If it starts with weechat, notifications are suppressed if not notify-send is called.

Displaying on the remote server

If on the otherhand you're simply trying to use notify-send to display messages on a remote server that you've used ssh to connect to, you'll likely need to follow one of the suggestions that was made in this Q&A titled: Using notify-send with cron. Even though several of the answers suggested that this was unnecessary, I had to do the following as others mentioned in comments on my Fedora 20 system using Cinnamon as my desktop to get things working.

To get notify-send working I had to set this variable with the appropriate value from the remote system's desktop environment.

$ export DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-wzrbFpDUZQ,guid=82e5bffe1f819506faecc77a53d3ba73

On my system I was able to make use of a file that's maintained for this exact purpose.

$ ssh me@remote
$ source ~/.dbus/session-bus/6a34f24f9c504e3f813bc094ed0b67af-0
$ notify-send "hi"

NOTE: The name of the DBUS file will change from session to session.

slm
  • 369,824
  • Hmmm.. I added some clarification. I don't want to send messages over SSH, I think. I think of notify-send as a terminal app that I can run interactively to the host (not client) PC. I think I understand - notify-send is a client per se on the host machine in its own way - is what you're saying. Does that somehow mean this is not possible to do while in an SSH session? Mind you, I am not trying to get this to appear on the SSH client, only the SSH host/server. – aikeru Jul 28 '14 at 17:50
  • @aikeru - notify-send can send messages to the listening notifier daemon. When you login via SSH this environment does not have the info necessary to communicate w/ this notifier, is the underlying issue. – slm Jul 28 '14 at 18:02
  • So is there any way to attach to the current environment or something like that, such that it has the info needed? – aikeru Jul 28 '14 at 18:15
  • @aikeru - much of what I've found shows that setting $DISPLAY=:0 would work, but this does not work for me as well. I'm on Fedora 20 using Cinnamon as my desktop. Using strace to debug this shows that there is a connection that doesn't get done when going through SSH, still investigating what is blocking this. – slm Jul 28 '14 at 18:50
  • @aikeru - see updates. – slm Jul 29 '14 at 11:37
  • The instructions involving setting the DBUS_SESSION_BUS_ADDRESS, etc. variable worked! In the long term, it may be more practical to setup a quick node.js script or something to facilitate this stuff, I suppose. Thanks again! :) – aikeru Jul 29 '14 at 14:57
  • I followed the suggestions here Using notify-send with cron Wouldn't this be a security risk? http://security.stackexchange.com/questions/71019 – rubo77 Oct 18 '14 at 07:30
  • @rubo77 - I don't think so, only the user that owns that file has access to it, or should be, if the permissions on that file are controlled properly. – slm Oct 18 '14 at 13:04
  • @slm I still don't understand what u did. .dbus folder on my remote machine(Ubuntu 14.04) is owned by root...is this normal?. Also did you export dbus session on remote or local machine? can you please tell me step by step? – Khurshid Alam Dec 27 '14 at 14:13
  • @KhurshidAlam - all the steps that I did were showed above. – slm Dec 27 '14 at 21:31
  • @sim Yes. now I got that. But sourcing doesn't work for me. I have to explicitly export dbus address taken from a file. I made bashrc to echo it out during login. – Khurshid Alam Dec 28 '14 at 05:51
1

IMO, may be you could use:

ssh user@host 'export DISPLAY=:0 && notify-send "test message"'

This of course assuming ":0" is the real value of the DISPLAY variable, if it is the only user currently logged in. I think we have to use the "export" special word here because we are sending two commands and if we export the variable it will be available to use for the second command "notify-send". The characters "&&" simply allow us to launch the two commands in one line.

0
  1. Forward local port :7272 to dbus abstract socket
@local $ echo $DBUS_SESSION_BUS_ADDRESS
unix:abstract=/tmp/dbus-pH1JnDeLNA,guid=5fe0907d81e722390f1ce02d6033ad76
@local $ socat TCP-LISTEN:7272,reuseaddr,fork ABSTRACT-CONNECT:/tmp/dbus-pH1JnDeLNA
  1. Revert forward port 7272 from remote host
@local $ ssh -R localhost:7272:localhost:7272 remotehostname
  1. Forward abstract socket to localhost:7272
@remote $ socat ABSTRACT-LISTEN:/tmp/custom_dbus_name,fork TCP:localhost:7272
  1. Launch notify-send
@remote $ export DBUS_SESSION_BUS_ADDRESS='unix:abstract=/tmp/custom_dbus_name,guid=5fe0907d81e722390f1ce02d6033ad76'
@remote $ notify-send "Hello, World"
lugu
  • 1