Re: [Pan-users] .nzb download seems to be going to /dev/null

[Duncan]

Graham Lawrence posted on Sat, 24 Sep 2011 11:45:53 -0700 as excerpted:

> Downloading files via .nzb file, but although Pan seems to be behaving
> normally, the files are not appearing anywhere on my system.  Its as if
> they are going to /dev/null.
> I've had this problem before if I opened the download directory before
> clicking Save, and solved it by selecting, but not opening the download
> directory.
> But that device is no longer working.

Pan version?  You're apparently not using pan to post your message (for 
instance on gmane, where the list is presented as a newsgroup), so I 
can't get your pan version from the headers.

Meanwhile, while I haven't used pan for binaries (other than a couple 
showing up on the lists, and a couple attachments posted myself using 
hmueller's git version code) in quite some years and have never used it 
for nzbs, there's a couple debugging tricks that may be of help.

First, run pan from a terminal window and see if it spits out anything 
useful there.  If not, add the --debug option to the pan command line.  
(This used to be documented in --help, but it doesn't seem to be so any 
longer, for whatever reason, at least not in the hmueller git version I'm 
running.)

You can also use strace to see what system calls pan's making.  Be warned 
that the output will likely be way bigger than is practical to sift thru, 
without some filtering.  I'm usually after information on what files it's 
opening, not non-file system calls being made, and file-opens gives me 
enough info so I don't need the other file syscalls, so I start with 
that.  The -f traces thru forks, which may not be necessary there but is 
here, since I use a wrapper script to start pan.  The -eopen tells strace 
to only trace file-open calls:

strace -feopen pan

But that'll still overload you with all the system libraries it tries to 
load, generally trying in several places before it finds the correct 
location for that library on your system, and it'll load icons and fonts 
and the like too.  You can filter that down with a grep that limits it to 
locations in your home dir.  Note that strace outputs to STDERR not 
STDOUT, so you have to redirect it so the grep will work on STDERR too. 
Here, I simply use /home, which should work too, assuming that you're 
saving somewhere under /home:

strace -feopen pan 2>&1 | grep /home

You can narrow that down further if necessary, say ignoring anything with 
icons or cursors in the path, like so:

strace -feopen pan 2>&1 | grep -v 'icons\|cursors' | grep /home

Once you get it narrowed down about as far as seems reasonable, you can 
if desired redirect the output to a file, which you can then open in an 
editor and get search functionality, etc (one line, tho it's two here due 
to wrapping):

strace -feopen pan 2>&1 | grep -v 'icons\|cursors' | grep /home > 
pan.debug

That drops pan.debug in whatever directory you were currently in, 
probably your home dir if you didn't cd elsewhere, since that's where 
terminal windows normally open to.  You can of course add a path to drop 
it elsewhere, if desired.

Interpreting the output:

If the file is opened successfully, the result will be a filehandle, 
showing up as '= 6' or whatever, at the right end.  If there was an error 
(see below), the result will normally be -1.

O_* shows the options used to open the file.  For example, O_WRONLY|
O_CREAT|O_TRUNC means write/read-only (no execute or the like), create if 
it doesn't exist, truncate to zero and start with an empty file if it 
does exist. 0666 (or similar) is the (octal) permissions mode to create 
the file with, if it's created.  (Obviously, create-mode should only 
appear if O_CREAT is given.) O_RDONLY, read-only, O_DIRECTORY, it's a 
directory not a file (this usually comes with O_CLOEXEC), O_NOBLOCK means 
use a non-blocking call -- it won't wait for the result, the result will 
be returned later.

ENOENT is the most common error.  No directory entry for that file exists 
(and it wasn't accessed with O_CREAT so it's not created), further 
explained with the "(No such file or directory)" comment.  This isn't 
unusual at all, as config files may not exist in which case defaults are 
used, the system looks for libraries in multiple locations before it 
finds them, etc.

REMINDER: If you dump the output to a debug file, remember to remove it 
when you're done. =:^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman