tridactyl/tridactyl

xclip processes piling up

Opened this issue · 6 comments

allanwind commented
  • Brief description of the problem:

I have an issue with a large number of xclip processes piling up (and eventually I run out of file descriptors which cause pipewire to break:-)). The parent process (only checked one) of the xclip calls:

 /home/allan/.local/share/tridactyl/native_main /home
/allan/.mozilla/native-messaging-hosts/tridactyl.json tridactyl.vim@cmcaine.co.uk

  • Steps to reproduce:

    Not sure. :nativeinstall does leave a xclip instance around but I don't think that is the mechanism that triggered it for me.

    The issue appears to be that xclip, specifically, leaves stdin open, and I read a work-around is call with with xclip -o >& /dev/null. Meanwhile my work-around is to switch to xsel. Apparently the leaving stdn open is desirable, and I prefer the usage of xclip.

  • Tridactyl version (:version): 1.23.0; native 0.3.6

  • Firefox version (Top right menu > Help > About Firefox): 115.4.0.esr

  • URL of the website the bug happens on: n/a

  • Config (in a new tab, run :viewconfig --user, copy the url and paste it somewhere like gist.github.com): n/a

  • Contents of ~/.tridactylrc or ~/.config/tridactyl/tridactylrc (if they exist):

colors dark

" The filter is almost the same as for vimperator, but it chooses new names for
" each hint after every non-hintchar character in the filterstring. This
" essentially "reflows" hints as the user filters them down.
set hintfiltermode vimperator-reflow
set putfrom selection
set searchurls.allmusic https://www.allmusic.com/search/artists/
setnull searchurls.amazonuk
setnull searchurls.googleuk
set searchurls.imdb https://www.imdb.com/find?q=
set searchurls.rfc https://www.rfc-editor.org/rfc/rfc
set yankto both
command discardall jsb browser.tabs.query({}).then(ts => browser.tabs.discard(ts.map(t=>t.id)))
  • Operating system: Debian 12
  • Result of running :! echo $PATH, or ! echo %PATH% on Windows, in Tridactyl:
/home/allan/.cargo/bin:/home/allan/bin:/usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin
  • Unix-like only:
    • :native at least version 0.2.0: result of running printf '%c\0\0\0{"cmd": "run", "command": "echo $PATH"}' 39 | ~/.local/share/tridactyl/native_main in a terminal:
{"cmd":"run","content":"/home/allan/.cargo/bin:/home/allan/bin:/usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin\n","command":"echo $PATH","code":0}
bovine3dom commented

Does setting externalclipboardcmd to killall xclip; xclip work?

allanwind commented

killall does work as that I how I manually recovered along with restarting firefox to restore audio in my browser. I added the setting and will keep an eye out of a bit.

allanwind commented

I have seen at most 1 xclip process hanging around since implementing this configuration change. Happy to try this for debugging purposes, but I don't think it's a suitable permanent solution as it may kill off an unrelated xclip process.

allanwind commented

I selected "tridactyl rocks" then P which result in the search "xclip: no process found tridactyl rocks". Reverting to xsel as a work-around for now. Let me know if there is anything else I can help with.

bovine3dom commented

killall xclip >/dev/null 2>&1; xclip should fix that, sorry.

as it may kill off an unrelated xclip process

I don't think that's possible, I think you only ever need one xclip running. But maybe I'm wrong

allanwind commented

Changed the setting and I will continue to test and report back. xclip man page says:

The default action is to silently wait in the background for X selection requests (pastes) until another X application places data in the clipboard, at which point xclip exits silently. You can use the -verbose option to see if and when xclip actually receives selection requests from other X applications.

I don't know why tridactyl's usage would cause processes to pile up and not exit (as reported initially).

  • 👀1