Re: [Vchanger-users] bacula requesting nonexistent slots

[Josh F. <jf...@ja...>]

On 8/10/23 09:51, Steven A. Falco wrote:
> I've had a working setup for years, but suddenly I'm getting errors:
>
> Fatal error: 3992 Bad autochanger "load Volume v1_0005_0197 Slot 412, 
> Drive 0": ERR=Child exited with code 1.
> Results=cannot load drive 0 from invalid slot 412
>
> bacula indeed thinks the volume is in slot 412, according to the "list 
> media" command:
>
>  1,501 | v1_0005_0197 | Append    |       1 | 23,539,407,831 |        
> 5 |    3,628,800 |       1 |  412 |         1 | File |       1 
> |        0 | 2023-08-09 00:54:13 | 3,511,018 |
>
> I tried doing "vchanger /etc/vchanger/v1.conf REFRESH" which I thought 
> would update bacula's inventory of the slots, but that doesn't seem 
> effective.
>
> If I ask vchanger what it has, using "vchanger /etc/vchanger/v1.conf 
> LIST", I get:
>
> 198:v1_0005_0197
>
> so vchanger thinks the volume is in slot 198.
>
> I was able to get bacula to correct its slots via "update slots", and 
> things are working again, but I'd like to understand how the 
> slots/volumes might have gotten out of sync.  Any thoughts on that 
> would be appreciated.
>
> Also, is the "update slots" command the right way to recover?


Yes, 'update slots' is the right way. It gets out of sync every time a 
filesystem (virtual magazine), say a removable drive, is attached or 
detached from the system. Vchanger assigns that filesystem's volume 
files to slots in the order that they are attached. Once a filesystem is 
detached, the slots it occupied may be reused. Regardless, when it is 
again attached, it is likely to be assigned different to a different set 
of slots.

Ordinarily, vchanger calls out to Bacula via its bconsole command when 
it detects a change in occupied slots. The REFRESH command simply 
triggers vchanger to check for slot changes and initiate a sync if 
needed. The sync is simply a call to bconsole to issue an 'update slots' 
command.

So, you need to somehow initiate an 'update slots' command whenever a 
filesystem is attached or detached. You can call vchanger with the 
REFRESH command, you can go into bconsole and issue it directly, or you 
can use udev rules to cause udev to automatically launch vchanger with 
the REFRESH command whenever a filesystem assigned to vchanger is 
physically attached or detached.

To use udev, there is a script (usually) installed at 
/usr/bin/vchanger-genudevrules that can be used to generate the udev 
rules by scanning the magazine= lines in the vchanger config file. 
Whenever a new filesystem is added or removed from the vchanger config 
file, those udev rules need to be regenerated  It should be used to 
update a udev rules file, usually in /etc/udev/rules.d. I have mine in 
/etc/udev/rules.d/96-vchanger.rules.

If the REFRESH command does not seem to actually change the slot number 
in Bacula, then something is preventing vchanger from launching the 
bconsole command. Check the vchanger config file. There is a bconsole= 
parameter that defaults to "bconsole". If the bconsole parameter is 
empty/blank, then vchanger will log that the update slots is needed, but 
will not actually call bconsole. Otherwise, if bconsole is not installed 
in a directory in the PATH environment variable, then it won't find the 
bconsole binary. Otherwise, there could be a permissions problem. Set 
log_level = LOG_DEBUG in the vchanger config to get very detailed 
logging of the process, which should show where it is failing.