Bug ID 1169669
Summary barrier / synergy: pointless systemd unit files shipped
Classification openSUSE
Product openSUSE Tumbleweed
Version Current
Hardware Other
OS Other
Status NEW
Severity Normal
Priority P5 - None
Component X11 Applications
Assignee screening-team-bugs@suse.de
Reporter martin.wilck@suse.com
QA Contact qa-bugs@suse.de
Found By ---
Blocker ---

The systemd unit files for barrier and synergy, as shipped by openSUSE,  are
bogus. 

 1. The system service fails:

> Apr 16 16:01:06 artemis.mittagstun.de systemd[1]: Started Barrier Server Daemon.
> Apr 16 16:01:06 artemis.mittagstun.de barriers[27817]: No protocol specified
> Apr 16 16:01:06 artemis.mittagstun.de barriers[27817]: [2020-04-16T16:01:06] WARNING: primary screen unavailable: unable to open>

 2. Running barrier/synergy as root in a system service seems to be a dangerous
thing to do, and it makes no sense unless the root user is logged in via GUI
and wants to use synergy/barrier.

 3. On the contrary, starting synergys as a *user* service in the UI session
makes a lot of sense. But it needs a a user unit file, which needs some changes
wrt the system unit. Also, I guess this would work properly only with desktops
that use systemd-user for initialization (aka GNOME). For other UIs, an XDG
.desktop file that could be copied to the autostart folder would do the job.

 4. Synergy doesn't seem to be designed for multi-seat systems. For systems
with multiple graphical terminals, separate daemon instances would need to be
started on separate ports. So, the services are really not system-wide, but
bound to the (one) user logged in on the main graphical console of the system.

 5. Socket activation doesn't work at all for synergys/barriers. For that, the
daemon would need to support sd_listen_fds() or the xinetd method of using
stdin, and both is obviously not implemented in either code base. Or what am I
missing here?


You are receiving this mail because: