http://bugzilla.suse.com/show_bug.cgi?id=1169669 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: You are on the CC list for the bug.