That might be the issue. Somebody does something in the web interface that takes the changer offline, clicks OK at the warning message. Then later when it’s back online FreeBSD doesn’t figure that out and needs a reboot.
Probably an issue that should be addressed with FreeBSD rather than Bacula. > On 6Feb 2018, at 6:50 PM, Alan Brown <a.br...@ucl.ac.uk> wrote: > > On 07/02/18 02:01, Kenneth Garges wrote: >> Permissions and ownership are ok. I think I figured out the problem. >> >> Both mtx and chio would work for a while, then stop working returning only >> “Inappropriate ioctl for device” or other errors. The culprit I think is a >> library management tool by Quantum. The library provides a web interface >> that allows you to check status, move tapes around, and various utilities. >> >> Problem is if you use that web interface it gets the server (both Bacula SD >> and Director on the same FreeBSD box) wedged such that mtx and chio always >> fail. > > Yes - and if it's about to do anything which takes the changer offline > the web ui gives a warning message and asked if you want to continue. > >> Unknown to me, the operations staff had been using that web interface while >> I was testing. After I asked them to stop my system seems to work reliably. > > I hope you changed the password and put the changer in its own IP subnet > after that. > > I wrote some kludgy shell scripts (originally for Neo4000, then Neo 8000 > and now Quantum i500 - portable as far as I know) which automate loading > and unloading of the changer (imported tapes are scattered randomly > around available slots to ensure even wear and tear) - these mean that > all operations staff have to do is open the magazine to load/unload > tapes when emailed to do so by Bacula. > > Dan can probably improve them considerably. > > As an adjunct to that another script works out which tapes are oldest > (if in the scratch pool) or about to expire (if none are in the scratch > pool) and asks staff to pull them out of the safe. > > I also submitted some chages to the mtx-changer script a while ago which > check that the changer's actually ready before attempting to send it > commands. Kern's been sitting on them for a couple of years. > > > There are some pretty whizzy things you can do to monitor tape health > when a tape is in the changer using the sg_attr and sg_logs commands > that go _far _ beyond Tapealart or smartmontools capabilities. > > I've submitted a number of updates to sg_utils and am in the process of > (slowly) reverse engineering what I can from the MAMs that's not well > documented using text output provided by veritape (proprietary, windows > tool from mptapes.com which reads MAMs). > > Selfish motivation is (of course) to reduce the amount of time I have to > spend manually scanning tapes with the windows program/standalone > scanner then interpreting output. All of that information is available > when the tape is in the drive and with appropriate MAM reads at > load/unload it's possible to have the bacula server tell me when a tape > is approaching end of life (this is far more accurate than the metrics > bacula uses of simple load cycles.) - and more importantly, when tape > drives are going bad. > > Having spent several man-years dealing with the fallout of bad LTO tapes > damaging drives and then those drives damaging tapes, I want to minimize > the pain if it ever happens again. > > (LTO drives even return detailed information about the condition of each > of the heads if queried the right way. This data is interpreted by IBM > or HP's proprietary tools to give reports but they use the same queries > as sg_logs does to get it) > ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
