Attachments: novosirj.vcf
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Ryan Novosielski wrote:
Andreas Helmcke wrote:
On 08.06.2007 16:20, Ryan Novosielski wrote:
Marc Levy wrote:
Ryan Novosielski <novosirj <at> umdnj.edu> writes:
Ralf Gross wrote:
Ryan Novosielski schrieb:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Ralf Gross wrote:
Ryan Novosielski schrieb:
Could someone tell me where I'm going wrong here? Here is my line that
I've added to the config files, stolen directly from those who know what
they're doing:
Alert Command = "sh -c '/opt/csw/sbin/smartctl -H -l error %c'"
Try something like this:
Alert Command = "sh -c 'smartctl -H -d scsi -l error %c'"
I'll certainly give it a shot, but doesn't it look like the %c is never
getting expanded to anything? Does anyone know where in the manual these
% variables are discussed?
It's in 'CHAPTER 28. AUTOCHANGER SUPPORT'
...
%c = changer device name
...
Of course you can use the device path instead of %c.
I don't have an autochanger. Would that mean I'd have to type the path
in manually, or use a different variable?
You've got to solutions:
1/ The answer is in the manual too:
'Chapter 14: Alert Command' (bottom of page 228 of bacula.pdf v2.0.3):
"you will need to specify a Changer Device directive in your Device resource
(...) so that the generic SCSI device name can be edited into the command (with
the %c)."
2/ The second one, more elegant, as you do not have to define a ChangerDevice=
directive for a device that is not an autochanger, is to modify the
AlertCommand= and replace the '%c' with '%a' that is the subtitution for the
archive device name (as stated in the manual (chapter 28.5 bottom of page 409
and other places as well). This way Bacula will substitute '%a' with the actual
value of the ArchiveDevice= directive in your SD.conf file before it is sent to
the OS for execution.
I dare say - without having checked this version, but fought with Alert
Command for a while - that this wont work.
When bacula is executing the Alert Command the storage daemon is using
the tape and thus preventing the smartcl to access the tape device.
So you are either back to solution number 1 (having to add a changer
device when not having an autochanger) or you have to replace the %c
with the name of the generic scsi-device of the tape drive (using linux
the name is something like /dev/sg4)
I'm not 100% sure on this, but I do not believe Solaris uses companion
generic device names in addition to the standard tape drive names. If it
does, I've never come across them (unless we're talking about those
crazy pci < at > 1000,4, etc. device names that hang out under /dev someplace).
I suppose I will find out soon enough whether Solaris' handling of
drives allows for this sort of thing or not.
Well, it looks like we were both right. Unfortunately, I don't know
where that takes me. If you look at the following manpage for scsitape:
The first argument, given following -f , is the SCSI generic device
corresponding to your tape drive. Consult your operating system's
documentation for more information (for example, under Linux these are
generally /dev/sg0 through /dev/sg15, under FreeBSD these are /dev/pass0
through /dev/passX. Under Solaris this is usually the same as your tape
drive (Solaris has a SCSI passthrough ioctl). You can set the STAPE or
TAPE environment variable rather than use -f.
...however, if I do try to use %a for the archive device, I do get a
busy error:
09-Jun 20:52 helios-sd: Alert: smartctl version 5.36
[sparc-sun-solaris2.8] Copyright (C) 2002-6 Bruce Allen
09-Jun 20:52 helios-sd: Alert: Home page is
http://smartmontools.sourceforge.net/
09-Jun 20:52 helios-sd: Alert:
09-Jun 20:52 helios-sd: Alert: Smartctl open device: /dev/rmt/0cbn
failed: Device busy
09-Jun 20:52 helios-sd: 3997 Bad alert command: sh -c
'/opt/csw/sbin/smartctl -H -l error /dev/rmt/0cbn': ERR=Child exited
with code 2.
...I tried /dev/rmt/0 too for good measure. No dice. I wonder if this is
also a problem caused by this process running at an odd place in the
job. It appears as if Blastwave has upgraded to 2.0.3 -- I guess I can
find out.
Incidentally, the out-of-place running of RunAfterJob (before
despooling) -- which part would I upgrade to test the effects? The
director? The storage?
By the way:
I would recommend to use this form *especially* when using multidrive
autochangers or you will only ask the changer for its status while
asking the tape gives more and more useful information.
Not 100% sure what you mean in this case. I don't have an autochanger,
so this doesn't much matter to me, but I'm curious how this alleviates
the problem you were talking about, as it seems to me you can only
specify one Changer Device, so you'd still only be able to ask about one
drive (or the changer itself).
Thanks for the ideas -- I should have looked there in the manual, but I
didn't expect the "Alert Command" to have such an elaborate description
in the manual -- I suppose that will teach me to underestimate it. ;)
Thanks to all of those that responded -- hopefully this will make things
a little easier, too, for those that search the list archives for an answer.
- --
---- _ _ _ _ ___ _ _ _
|Y#| | | |\/| | \ |\ | | |Ryan Novosielski - Systems Programmer III
|$&| |__| | | |__/ | \| _| |novosirj < at > um... - 973/972.0922 (2-0922)
\__/ Univ. of Med. and Dent.|IST/AST - NJMS Medical Science Bldg - C630
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla -
http://enigmail.mozdev.org
iD8DBQFGa09ymb+gadEcsb4RAtfiAKCDJdKuamGKLlzIb4Kq7/F1EiH0DACfc/kX
FSf2nui5zJZ2KZJiidYLdts=
=NeDb
-----END PGP SIGNATURE-----
