[prev in list] [next in list] [prev in thread] [next in thread] 

List:       debian-user
Subject:    Re: Juk hangs after launch
From:       <tomas () tuxteam ! de>
Date:       2020-09-27 10:06:01
Message-ID: 20200927100601.GB8726 () tuxteam ! de
[Download RAW message or body]


On Sun, Sep 27, 2020 at 11:36:02AM +0200, local10 wrote:
> Sep 26, 2020, 15:45 by tomas@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" (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]