Re: full dumps not getting timestamp
It took some time to figure out, but it wasn't a configuration issue. At least, not on my part - it turns out that the j printf/etc length is used in 40 places in the code. This is a fairly recent introduction to the c library, and is not supported under Solaris 8 (it is under Solaris 10). gcc 4.4.0 recognizes it, though, so doesn't complain. Unfortunately, the library specifies If a length modifier appears with any conversion specifier other than as specified above, the behavior is undefined. In this case, writing with it resulted in 0 being written, and reading with it failed. So it was very annoying to track down. Changing all the j lengths to ll (and recompiling) solved the problem. This is likely an issue for any machine whose libc does not support the j length.
Re: full dumps not getting timestamp
On Thu, Dec 3, 2009 at 12:07 PM, flow...@hagsc.org wrote: This is likely an issue for any machine whose libc does not support the j length. We use the formatting functionality provided by glib, which promises to support 'j'. It does this by testing the implementation in the C library, and replacing it with a bundled implementation if the C library falls short. However, especially older versions of glib seem to have trouble with these tests, and incorrectly use the C library's functions. The trouble with %ll is, of course, that long long does not mean anything in particular across multiple platforms. What version of glib are you using? Can you verify whether it's using the bundled formatting library (basically, whether HAVE_GOOD_PRINTF is defined - see gprintfint.h) Dustin -- Open Source Storage Engineer http://www.zmanda.com
Re: full dumps not getting timestamp
Ah, I'd wondered if glib did that (it looked like it passed through to libc for all the printf functions when I checked the code). I'm using 2.8.1, and config.h in the source directory has /* #undef HAVE_GOOD_PRINTF */ which would seem to imply it's using the system printf, as you'd suggested. I suppose I could toggle that and recompile glib to fix the problem as well. As for the ll substitutions, I wasn't saying they should be generally used, merely that they fixed the problem for me.
Re: full dumps not getting timestamp
On Thu, Dec 3, 2009 at 1:01 PM, flow...@hagsc.org wrote:
/* #undef HAVE_GOOD_PRINTF */
which would seem to imply it's using the system printf, as you'd
suggested. I suppose I could toggle that and recompile glib to fix the
problem as well.
No, that means it's using the bundled printf. That doesn't make a lot of sense.
(I referred back to a conversation I had with John Hein about a
similar problem on FreeBSD)
glib specifically provides a C99-compliant printf implementation, via
gnulib. However, in glib/gnulib/printf-parse.c, I see:
#ifdef HAVE_INTMAX_T
else if (*cp == 'j')
{ /* ... */
}
#endif
so perhaps that conditional is at fault? Can you check the same
config.h for HAVE_INTMAX_T? Do the references to the intmax_t type in
Amanda cause build errors?
Dustin
--
Open Source Storage Engineer
http://www.zmanda.com
Re: full dumps not getting timestamp
No, HAVE_INTMAX_T is defined, and caused no issues while building amanda.
Re: full dumps not getting timestamp
Ah, mistake on my part - this is indeed an old library, and was compiled on an earlier machine running Solaris 7, which I no longer have access to. It's quite possible the config.h created at that point was different from what I'm seeing now. Is there any way to pry configuration information out of the installed library? It's certainly not obvious to me.
Re: full dumps not getting timestamp
On Thu, Dec 3, 2009 at 2:29 PM, flow...@hagsc.org wrote: Ah, mistake on my part - this is indeed an old library, and was compiled on an earlier machine running Solaris 7, which I no longer have access to. It's quite possible the config.h created at that point was different from what I'm seeing now. Is there any way to pry configuration information out of the installed library? It's certainly not obvious to me. I don't think so - the gprintfint.h header isn't installed - the g_*printf functions are real library functions, not macros. It sounds like you have a working solution, but the more, ahem, recommended solution would be to rebuild glib for the current architecture :) Thanks for chasing this down! Dustin -- Open Source Storage Engineer http://www.zmanda.com
Re: full dumps not getting timestamp
And, having tested with a recompiled 2.8.1, and with 2.22.3, this was exactly the problem. Thanks for the help in tracking it down!
Re: full dumps not getting timestamp
Do the backup succeeded? It looks it failed. flow...@hagsc.org wrote: I'm running a fresh install of amanda 2.6.1pl1 (I recently upgraded to p2 and experienced the same problem). When performing full dumps, the curinfo/machine/disk/info files are getting updated (they have proper ownership), but the stats: line for level 0 is mostly filled with 0's. version: 0 command: 0 full-rate: 13929.010897 13776.895360 full-comp: incr-rate: incr-comp: stats: 0 0 0 0 -1 31 GSC_FULL12 last_level: -1 -1 // This is after amanda has finished its run. As you can see, it was dumped to tape, and has the proper tape label and file number on the tape. But it's missing the timestamp and size of dump information. I'm kind of at a loss as to what I've done wrong. Previously, I've been using a modified version of 2.4.1, which has worked fine. For the new install, I replaced both clients and servers with the new software, and decided not to copy over the old database, instead starting fresh (I needed to do a full set of dumps anyway). It appears to work in all other ways, but the lack of proper info in the info files prevents the usual cycle (I can't do incrementals, since the full doesn't have a time). Any ideas?
Re: full dumps not getting timestamp
full dumps not getting timestamp
I'm running a fresh install of amanda 2.6.1pl1 (I recently upgraded to p2 and experienced the same problem). When performing full dumps, the curinfo/machine/disk/info files are getting updated (they have proper ownership), but the stats: line for level 0 is mostly filled with 0's. version: 0 command: 0 full-rate: 13929.010897 13776.895360 full-comp: incr-rate: incr-comp: stats: 0 0 0 0 -1 31 GSC_FULL12 last_level: -1 -1 // This is after amanda has finished its run. As you can see, it was dumped to tape, and has the proper tape label and file number on the tape. But it's missing the timestamp and size of dump information. I'm kind of at a loss as to what I've done wrong. Previously, I've been using a modified version of 2.4.1, which has worked fine. For the new install, I replaced both clients and servers with the new software, and decided not to copy over the old database, instead starting fresh (I needed to do a full set of dumps anyway). It appears to work in all other ways, but the lack of proper info in the info files prevents the usual cycle (I can't do incrementals, since the full doesn't have a time). Any ideas?
