Re: [Bacula-users] director fails to find usable volume to append or recycle: behavior of db_find_next_volume in sql_find.c

[Martin S. <ma...@li...>]

>>>>> On Wed, 21 Mar 2012 23:01:02 +0100, Lucas B Cohen said:
> 
> Dear list,
> 
> I'm struggling to finish my last round of backups with Bacula 2.4.4,
> which I care to do before migrating to the latest version. My problem is
> simple to describe: with one of my (multiple, and otherwise working)
> media pools, the director fails to find a usable volume for use with a
> backup job (thus prompting for the labeling of a new one, which I really
> want to avoid).
> 
> I've spent the evening going through debug output and part of the source
> in src/dird/next_vol.c and src/cats/sql_find.c. Here is what seems like
> the part relevant to the problem of what I'm witnessing in the director
> debug output when I ask to run a job:
> 
> Washington-dir: sql_find.c:323-0 fnextvol=SELECT
> MediaId,VolumeName,<snip> FROM Media WHERE PoolId=5 AND MediaType='LTO2
> Ultrium' AND Enabled=1 AND VolStatus='Append'  ORDER BY LastWritten IS
> NULL,LastWritten DESC,MediaId LIMIT 1
> Washington-dir: sql_find.c:331-0 item=1 got=0
> 
> 'got=0' means the query returned 0 rows. But copying and pasting the
> exact same query in fact returns the expected result of the tape I'm
> expecting. I can only wildly speculate about what could cause numrows or
> sql_num_rows(mdb)'s return value to not reflect the fact that there is
> in fact a result returned by the query.

Seems very strange.  Is it repeatable, i.e. does the backup still fail to find
a volume after your manual query has returned that volume?

__Martin