FS#28364 - [synergy] synergys cannot open display when run with rc.d

Attached to Project: Community Packages
Opened by Kerrick Staley (KerrickStaley) - Saturday, 11 February 2012, 18:53 GMT
Last edited by Sven-Hendrik Haase (Svenstaro) - Monday, 20 May 2013, 19:56 GMT
Task Type Bug Report
Category Packages
Status Closed
Assigned To Sven-Hendrik Haase (Svenstaro)
Architecture x86_64
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:
"/etc/rc.d/synergys {start|stop|restart}" behaves differently from "rc.d {start|stop|restart} synergys". With the first command, synergys runs as expected. With the second command, synergys fails to open the display.

Steps to reproduce:
There are actually two issues. The first is that DISPLAY isn't set when rc.d runs the script (again, it works perfectly with /etc/rc.d/). This can be fixed by putting
export DISPLAY=':0'
at the top of /etc/rc.d/synergys.

The other issue is that even if DISPLAY is set correctly, synergys still cannot connect to the display with rc.d. To see this, change the line
[ -z "$PID" ] && /usr/bin/synergys --config /etc/synergy.conf &> /dev/null
to
[ -z "$PID" ] && /usr/bin/synergys --config /etc/synergy.conf -f

After performing these modifications on my own computer, I got the following output:
========Result of running "rc.d start synergys"========
2012-02-11T12:42:08 INFO: Synergy 1.4.6 Server on Linux 3.2.5-1-ARCH #1 SMP PREEMPT Tue Feb 7 08:34:36 CET 2012 x86_64
/build/src/synergy-1.4.6-Source/src/lib/synergy/CServerApp.cpp,142
2012-02-11T12:42:08 DEBUG: opening configuration "/etc/synergy.conf"
/build/src/synergy-1.4.6-Source/src/lib/synergy/CServerApp.cpp,267
2012-02-11T12:42:08 DEBUG: configuration read successfully
/build/src/synergy-1.4.6-Source/src/lib/synergy/CServerApp.cpp,278
2012-02-11T12:42:08 DEBUG: XOpenDisplay(":0")
/build/src/synergy-1.4.6-Source/src/lib/platform/CXWindowsScreen.cpp,908
No protocol specified
2012-02-11T12:42:08 WARNING: cannot open primary screen: unable to open screen
/build/src/synergy-1.4.6-Source/src/lib/synergy/CServerApp.cpp,523
2012-02-11T12:42:08 DEBUG: retry in 60 seconds
/build/src/synergy-1.4.6-Source/src/lib/synergy/CServerApp.cpp,545
========End========
========Result of running "/etc/rc.d/synergys start"========
2012-02-11T12:40:47 INFO: Synergy 1.4.6 Server on Linux 3.2.5-1-ARCH #1 SMP PREEMPT Tue Feb 7 08:34:36 CET 2012 x86_64
/build/src/synergy-1.4.6-Source/src/lib/synergy/CServerApp.cpp,142
2012-02-11T12:40:47 DEBUG: opening configuration "/etc/synergy.conf"
/build/src/synergy-1.4.6-Source/src/lib/synergy/CServerApp.cpp,267
2012-02-11T12:40:47 DEBUG: configuration read successfully
/build/src/synergy-1.4.6-Source/src/lib/synergy/CServerApp.cpp,278
2012-02-11T12:40:47 DEBUG: XOpenDisplay(":0")
/build/src/synergy-1.4.6-Source/src/lib/platform/CXWindowsScreen.cpp,908
2012-02-11T12:40:47 DEBUG: xscreensaver window: 0x00000000
/build/src/synergy-1.4.6-Source/src/lib/platform/CXWindowsScreenSaver.cpp,343
2012-02-11T12:40:47 DEBUG: screen shape: 0,0 3840x1080 (xinerama)
/build/src/synergy-1.4.6-Source/src/lib/platform/CXWindowsScreen.cpp,141
2012-02-11T12:40:47 DEBUG: window is 0x00400004
/build/src/synergy-1.4.6-Source/src/lib/platform/CXWindowsScreen.cpp,142
2012-02-11T12:40:47 DEBUG: opened display
/build/src/synergy-1.4.6-Source/src/lib/synergy/CScreen.cpp,43
2012-02-11T12:40:47 DEBUG: registered hotkey ScrollLock (id=ef14 mask=0000) as id=1
/build/src/synergy-1.4.6-Source/src/lib/platform/CXWindowsScreen.cpp,736
2012-02-11T12:40:47 NOTE: started server
/build/src/synergy-1.4.6-Source/src/lib/synergy/CServerApp.cpp,606
2012-02-11T12:40:47 INFO: screen "kerrick-Gazelle" shape changed
/build/src/synergy-1.4.6-Source/src/lib/server/CServer.cpp,1225
2012-02-11T12:40:47 NOTE: accepted client connection
/build/src/synergy-1.4.6-Source/src/lib/server/CClientListener.cpp,138
2012-02-11T12:40:47 DEBUG: received client "kerrick-ThinkPad" info shape=0,0 2960x1050 at 345,644
/build/src/synergy-1.4.6-Source/src/lib/server/CClientProxy1_0.cpp,435
2012-02-11T12:40:47 NOTE: client "kerrick-ThinkPad" has connected
/build/src/synergy-1.4.6-Source/src/lib/server/CServer.cpp,318
========End========
This task depends upon

Closed by  Sven-Hendrik Haase (Svenstaro)
Monday, 20 May 2013, 19:56 GMT
Reason for closing:  Won't fix
Additional comments about closing:  Can't sensibly be fixed with systemd on a package level.
Comment by Jon Janzen (JonJanzen) - Friday, 21 September 2012, 03:18 GMT
I have the same issue. What I've discovered is that I can start synergy with
sudo synergys -f
and that will run fine. When I start synergy with
sudo rc.d start synergy
I get the same behavior as Kerrick. From a bit of reading it looks like synergy must be started by the user using it in order for it to be able to connect to the xsession. So I tried starting synergy with no sudo
rc.d start synergy // no sudo
I get the error
/etc/rc.d/functions: line 221: /run/daemons/synergys: Permission denied
which is in the add_daemon function.

the wiki, https://wiki.archlinux.org/index.php/Writing_rc.d_scripts, mentions that you can look in /etc/rc.d/functions to see how to run a rc.d script as non root. I could not see anything in their related to that. I wasn't sure if it was a good idea to change /run/daemons to allow my user to insert into it. On my system I created a folder owned by my user with the group users called udaemons and added /etc/rc.d/ufunctions like so

add_udaemon() {
[[ -d /run/udaemons ]] || mkdir -p /run/udaemons
>| /run/udaemons/"$1"
}

rm_udaemon() {
rm -f /run/udaemons/"$1"
}

then modified the included /etc/rc.d/synergys script to use add_udaemon and rm_udaemon instead of add_daemon and rm_daemon. This gets wiped out on system start though, which makes it pretty clear that this isn't the way to do it.

This isn't really ideal but I'm not sure of another way to get this running as a user.
Comment by Lennon Cook (lvc) - Thursday, 17 January 2013, 02:12 GMT
Bug still occurs with 'systemctl start synergys'.
Comment by Jon Janzen (JonJanzen) - Thursday, 17 January 2013, 16:09 GMT
I've stopped using my above method, as I mentioned it was pretty bad, I now start it in my .xinitrc

(synergys -f > /dev/null 2>&1) &

I'm sure it isn't quite the ideal way to start it but it is running when I need it.
Comment by Peng Zhang (pczhang) - Thursday, 17 January 2013, 16:29 GMT
/etc/rc.d/synergys start or restart is still working. That is the reason that I still keep it after converting to systemd.
Comment by kei (kei) - Wednesday, 23 January 2013, 16:07 GMT
after fresh install:

root ~ # /etc/rc.d/synergys start
/etc/rc.d/synergys: line 5: /etc/rc.conf: No such file or directory
/etc/rc.d/synergys: line 6: /etc/rc.d/functions: No such file or directory
/etc/rc.d/synergys: line 11: stat_busy: command not found
/etc/rc.d/synergys: line 16: add_daemon: command not found
/etc/rc.d/synergys: line 17: stat_done: command not found
root ~ # systemctl start synergys
root ~ # systemctl status synergys
synergys.service - Synergy Server Daemon
Loaded: loaded (/usr/lib/systemd/system/synergys.service; disabled)
Active: failed (Result: core-dump) since Wed 2013-01-23 17:07:22 CET; 5s ago
Process: 5250 ExecStart=/usr/bin/synergys --config /etc/synergy.conf (code=exited, status=0/SUCCESS)
Main PID: 5251 (code=dumped, signal=SEGV)
CGroup: name=systemd:/system/synergys.service

Jan 23 17:07:22 chuck synergys[5250]: /build/src/synergy-1.4.10-Source/src/lib/synergy/CServerApp.cpp,270
Jan 23 17:07:22 chuck synergys[5250]: 2013-01-23T17:07:22 DEBUG: configuration read successfully
Jan 23 17:07:22 chuck synergys[5250]: /build/src/synergy-1.4.10-Source/src/lib/synergy/CServerApp.cpp,281
Jan 23 17:07:22 chuck synergys[5251]: Synergy 1.4.10: 2013-01-23T17:07:22 DEBUG: XOpenDisplay(":0.0")
Jan 23 17:07:22 chuck synergys[5251]: Synergy 1.4.10: 2013-01-23T17:07:22 WARNING: primary screen unavailable: unable to open screen
Jan 23 17:07:22 chuck synergys[5251]: Synergy 1.4.10: 2013-01-23T17:07:22 DEBUG: retry in 60 seconds
Jan 23 17:07:22 chuck systemd[1]: Started Synergy Server Daemon.
Jan 23 17:07:22 chuck systemd[1]: synergys.service: main process exited, code=dumped, status=11/SEGV
Jan 23 17:07:22 chuck systemd-coredump[5257]: Process 5251 (synergys) dumped core.
Jan 23 17:07:22 chuck systemd[1]: Unit synergys.service entered failed state

Please don't yell at me if that display thing is some kind of a noob error...
Comment by Peng Zhang (pczhang) - Wednesday, 23 January 2013, 16:28 GMT
rc.d became obsolete, and you need to install it yourself. (pacman -S initscripts)

I still kept it for "/etc/rc.d/synergys start" and "/etc/rc.d/alsa force-restart".
Comment by kei (kei) - Wednesday, 23 January 2013, 17:12 GMT
Thanks, but I don't think that now that I finally have a fully systemd-based system I wanna switch back to a hybrid again :-) I guess I'll wait until the systemd-way works and start synergys as a user in the meantime.
Comment by Brian Steere (Dianoga) - Wednesday, 13 February 2013, 15:16 GMT
As a quick fix, I added

User=username

to the [Service] section of synergys.service
Comment by Lennon Cook (lvc) - Monday, 15 April 2013, 01:55 GMT
  • Field changed: Percent Complete (100% → 0%)
Bug is still present using systemd synergys unit instead of initscripts
Comment by Sven-Hendrik Haase (Svenstaro) - Monday, 22 April 2013, 19:58 GMT
Does something like systemctl start your-user@synergys.service not work for you guys? I'd consider that the best solution. Please test that.
Comment by kei (kei) - Thursday, 25 April 2013, 12:23 GMT
I don't know what I'm doing wrong here but:

root /home/kevin # systemctl start kevin@synergys.service
Failed to issue method call: Unit kevin@synergys.service failed to load: No such file or directory. See system logs and 'systemctl status kevin@synergys.service' for details.
root /home/kevin # systemctl status kevin@synergys.service
kevin@synergys.service
Loaded: error (Reason: No such file or directory)
Active: inactive (dead)
Comment by Sven-Hendrik Haase (Svenstaro) - Friday, 26 April 2013, 00:23 GMT
Sorry, I totally misunderstood how this systemd feature was supposed to work.

The way you do it is this:

systemctl start user@kevin.service
Then you can put a customized tmux file into .config/systemd/user/ and have your own personal systemd run your user daemons.

I think this is the best way to solve this bug. synergys doesn't seem like it should be run as a system-wide service because it needs to attach to a specific user's X session.
Comment by kei (kei) - Friday, 26 April 2013, 09:43 GMT
hm I wonder how to package this...
Comment by Sven-Hendrik Haase (Svenstaro) - Monday, 20 May 2013, 19:56 GMT
I'm gonna close this for now. There is no sensible way to add global user management into the package. With systemd, you should enable user services and run this as a service for your own user if you want to start it using systemd. This info is not transparent to most users and should probably be added to the wiki.

Loading...