On Sun, Sep 27, 2020 at 11:36:02AM +0200, local10 wrote: > Sep 26, 2020, 15:45 by to...@tuxteam.de: > > > Possibly the application has left behind a lock file. This might > > live somewhere in /run. > > > > Didn't find anything related to juk in /run, /var/run or /var/lock > directories. > > > > You might try to start the application from the command line, > > perhaps there are error messages giving you some hints. > > > > Starting (and then killing) juk from the command line produces the following > output, regretfully it doesn't give much clues as to what I need to do to fix > it: > > $ juk > org.kde.juk: Unable to setup to load cache... perhaps it doesn't exist? > Killed
Ugh. It could tell us where it looks for its cache, couldn't it? OK. If you don't fear some text output, you could run it under strace (in Debian package strace), like so: strace -f -o /tmp/trace <your-program-here> You'll find a text file /tmp/trace (or whatever path you chose for the -o ooption) with all the system calls your program tries. Of interest are those failing (especially things like open or stat returning an ENOENT or similar) near the trace's bottom. Option -f is to "follow" your program when it forks -- trace file entries will be prepended by the process ID. You may share snippets of that trace here when in doubt (look out for possibly sensitive information -- in this case the risk seems pretty low, though). There should be a special hell for app developers issuing error messages like the above. Grrr. Cheers - t
signature.asc
Description: Digital signature
