FS#68288 - [clipmenu] Breaks with 6.2.0.1

Attached to Project: Community Packages
Opened by Karl Hernandez (SirMars) - Friday, 16 October 2020, 22:45 GMT
Last edited by Morten Linderud (Foxboron) - Monday, 16 November 2020, 17:59 GMT
Task Type Bug Report
Category Packages
Status Closed
Assigned To Thore Bödecker (foxxx0)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 2
Private No

Details

Description: Clipmenu gives me an error of `/usr/bin/clipmenu: line 42: /run/user/1000/clipmenu.6.karl/line_cache: No such file or directory` and clipmenud.serivce no longer starts. I have downgraded to multiple versions and the issues seems to be only with 6.2.0.1.


Additional info:
* package version(s): 6.2.0.1
* config and/or log files etc. No logs since the service doesn't start.
* link to upstream bug report, if any: Might have to do with issue? https://github.com/cdown/clipmenu/issues/141

Steps to reproduce:
upgrade to 6.2.0.1 and `$ clipmenu` will result in /usr/bin/clipmenu: line 42: /run/user/1000/clipmenu.6.karl/line_cache: No such file or directory

fixed by downgrading to 6.1.0.2 or below.
This task depends upon

Closed by  Morten Linderud (Foxboron)
Monday, 16 November 2020, 17:59 GMT
Reason for closing:  Not a bug
Additional comments about closing:  Reason for request: The issue is a user one caused by a lack of DISPLAY environmental variable since the service no longer provides a fixed setting.
Comment by Karl Hernandez (SirMars) - Saturday, 17 October 2020, 15:35 GMT
Alright it seems that the reason for this is that the included clipmenud.service in 6.2.0.1 no longer forces DISPLAY=:0 in it's configuration. The way to fix this is edit the configuration file to include it or add DISPLAY=:0 to your environment variables. Be warned that you need to start clipmenu after you load start x otherwise clipmenu.service doesn't have a display to start with.
Comment by Ferenc Szabo (frncmx) - Saturday, 17 October 2020, 19:24 GMT
That's an OK workaround. However, `/usr/lib/systemd/user/clipmenud.service` comes with the `clipmenu` package. So I would expect `systemctl --user start clipmenud.service` just work. That was the case, now it's broken. I just realised clipmenu was not running when I wanted to use my clipboard history and that was empty. I would be happier, if the issue would be just fixed (in the package).
Comment by Karl Hernandez (SirMars) - Saturday, 17 October 2020, 22:22 GMT
I understand your frustration, however, the issue is upstream not the package itself. The package correctly packages the master branch of clipmenu which is why I closed the issue. However, what I did to resolve the problem was to make a new systemd unit `clipd.service` in `~/.config/systemd/user/` with the following (the old unit configuration):
```
[Unit]
Description=Clipmenu daemon

[Service]
ExecStart=/usr/bin/clipmenud
Restart=always
RestartSec=500ms
Environment=DISPLAY=:0

MemoryDenyWriteExecute=yes
NoNewPrivileges=yes
ProtectControlGroups=yes
ProtectKernelTunables=yes
RestrictAddressFamilies=
RestrictRealtime=yes

[Install]
WantedBy=default.target
```

I started the service with systemctl --user enable clipd.service and disable the old service. Hope that helps!
Comment by Thore Bödecker (foxxx0) - Monday, 16 November 2020, 09:21 GMT
Have you tried something like:

systemctl --user --import-environment DISPLAY

in your ~/.xinitrc or within the X startup script of your WM/DE?
Theoretically that sould import the DISPLAY env var into your current systemd-logind session and make it available to all user units that want to output something to $DISPLAY.

And I highly dislike the suggested workaround by re-adding the hardcoded "DISPLAY=:0" because it is not necessarily guaranteed that your X is running at :0.

Loading...