Closed Filip62 closed 4 years ago
That's not a bug, -$$
means "terminate all pids with PGID $$
". Which processes are still running after the SIGTERM?
With unmodified clipmenud. Right after boot and login:
Right after I send SIGTERM to bash /usr/bin/clipmenud: And it stays like that until I send another SIGTERM to bash /usr/bin/clipmenud, which then terminates but the two clipnotify processes stay.
Log:
/usr/bin/clipmenud: line 1: kill: (-680) - No such process
It looks like the dash just gets prepended.
Just to be clear, I do not know bash scripting. I am sorry I assumed it was a bug.
I autostart clipmenud with clipmenud &>/home/filip/cm-log.txt &
.
"&>" is fish shell syntax. I use fish, but I do not think it is causing the problem since clipmenud is executed in bash right?
Experiencing the same issue in my Arch Linux installation + clipmenu 6.1.0-2. Had to do a little bit of investigation to find out in the end that the process causing the shutdown/reboot delays was clipmenud. In my case though I'm starting clipmenud using the autostart patch from DWM.
I tried to troubleshoot the error by creating my own systemd service unit, and although systemd is then able to kill clipmenud normally, it seems that clipnotify never starts and thus clipmenu cannot copy any text...
@marc1984 There is a systemd unit written by the author. Clipmenud service file 6.1.0
With our arch package it gets installed in usr/lib/systemd/user/clipmenud.service
Try systemctl --user status clipmenud
I'm moderately confused that this pid isn't the same as the pgrp, but what's actually at pid 628?
Either way, we can manually check the pgrp when shutting down, instead, but I'm somewhat concerned that this might result in killing more than we intended. It would help a lot to know what's actually at the pid indicated by your pgrp.
And wait, why are there two clipnotify daemons? That doesn't make much sense. clipnotify is explicitly awaited with waitpid, so it shouldn't be possible for two to run at once.
Thanks @Filip62, I was looking under /etc/systemd/system and not in the user space. So turns out that using systemd to start up the service and it gets properly killed with SIGTERM on shutdown (no delays). The issue though is that when starting clipmenud using the packaged user service unit clipmenu does not work, cannot copy text selections. Am I missing something or is it a bug?
This looks like a totally separate issue, but what does sed -nz /DISPLAY/p /proc/1108/environ
say? Is that right value?
I'm still not entirely sure how this comes to be, but it's true that if there's a wrapper script or something else in the way, it might not work out.
@Filip62, can you please try 8d29b2aaf841d5346dbcc2c5e18cde4f662807f1 and let me know if it fixes your problem?
@cdown Sorry I did not reply sooner, got caught up. If I use the provided systemd clipmenud service, everything works just as expected. Only clipmenud and clipnotify have the same PGRP and SIGTERM terminates both, no shutdown problems.
If I change to 8d29b2a, then also everything works as expected. Here is the tree. Definitely not the same PGRP, but handled correctly with the new commit. PID 626 is qtile. I autostart clipmenud in qtile's config script.
Okay then, I think we can close this if you agree go ahead. Will you do a quick issue-fix release?
Yeah. 6.2.0 is now out, although this shouldn't affect many people hopefully. Let me know if there are any problems :-)
This looks like a totally separate issue, but what does sed -nz /DISPLAY/p /proc/1108/environ say? Is that right value?
DISPLAY=:0%
Hmm, looks like a different issue then. Feel free to file if it's still happening for you, there are a couple of fixes for stuff which went out in 6.2.0 :-)
OS: Arch Linux Clipmenu: 6.1.0
My system started taking a long time to shutdown because systemd was running a stop job for 1m30s for a program of my user session. After quite a bit of debugging I found that clipmenud was not exiting on the SIGTERM that systemd sent.
After I changed it to this: (removed the dash in front of $$)
My system shut down properly.
Though while I was debugging this I noticed that while it does terminate the clipmenud process, the clipnotify process clipmenud spawned does not get terminated, so if I run clipmenud again, it complains that another clipmenud is running, but it is not, just the clipnotify process that was spawned by the first clipmenud and did not get terminated.