Sorry to get back to you so lately, compiling the stuff on the NSLU2 took some
time…
Seems that your patch worked for me, however I don't understand the patched
part in amstatus.pl… :-(
Thank you very much for your help
Benjamin
Am 08.12.2009 um 16:32 schrieb Jean-Louis Martineau:
> The first patch was not correct. Try this new one.
>
> Jean-Louis
>
> Jean-Louis Martineau wrote:
>> Benjamin,
>>
>> It's a bug, try the attached patch.
>>
>> Jean-Louis
>>
>> Benjamin Boksa wrote:
>>>> I'd hate to see too much work go into hacking *around* the script API
>>>> -- it's brand new! The best outcome would be to fix/improve the script
>>>> API as appropriate, but at the very least, let's make sure that the
>>>> limitations of the API are well-documented. From what I can tell from
>>>> this thread:
>>>>
>>>> * per-host scripts can only run on the server
>>>> * per-host scripts run for *every* DLE to which they are attached,
>>>> which can result in them running several times for a single host; even
>>>> in this case, all scripts are run before any hosts are dumped
>>>>
>>>
>>> Regarding fixing the Script API I think I might have found a bug (using
>>> Amanda 2.6.1p1): POST-HOST-BACKUP only seems to get executed once per
>>> amdump.
>>>
>>>
>>> To reproduce this bug I use the following disklist:
>>>
>>> mail01.oelstrasse.boksa.de /var/mail {
>>> default
>>> script {
>>> plugin "amlog-script"
>>> execute-where server
>>> execute_on pre-host-backup, post-host-backup
>>> property "logfile" "/tmp/test"
>>> }
>>> }
>>> www01.oelstrasse.boksa.de /var/www {
>>> default
>>> script {
>>> plugin "amlog-script"
>>> execute-where server
>>> execute_on pre-host-backup, post-host-backup
>>> property "logfile" "/tmp/test"
>>> }
>>> }
>>>
>>>
>>> The result (found in /tmp/test) is:
>>>
>>> DailySet1 pre-host-backup server www01.oelstrasse.boksa.de /var/www
>>> DailySet1 pre-host-backup server mail01.oelstrasse.boksa.de /var/mail
>>> DailySet1 post-host-backup server mail01.oelstrasse.boksa.de /var/mail
>>> Obviously there is something wrong.
>>>
>>> Is this a known bug? If not: Where should I file it? Are there any known
>>> workarounds for this bug?
>>>
>>> Looking forward to your comments!
>>>
>>> Regards
>>>
>>> Benjamin
>>
>
> diff --git a/server-src/amstatus.pl b/server-src/amstatus.pl
> index 684b747..b1f4ad9 100644
> --- a/server-src/amstatus.pl
> +++ b/server-src/amstatus.pl
> @@ -716,7 +716,7 @@ while($lineX = <AMDUMP>) {
> }
> $state_time_prev=$current_time;
> $dumpers_active_prev=$dumpers_active;
> - $status_driver=$line[16];
> + $status_driver=$line[23];
> if(!
> defined($dumpers_held[$dumpers_active]{$status_driver})) {
>
> $dumpers_held[$dumpers_active]{$status_driver}=0;
> }
> diff --git a/server-src/driver.c b/server-src/driver.c
> index c96d0be..ba896cd 100644
> --- a/server-src/driver.c
> +++ b/server-src/driver.c
> @@ -1949,10 +1949,25 @@ handle_dumper_result(
>
> if (cmd != BOGUS) {
> int last_dump = 1;
> + dumper_t *dumper;
> +
> run_server_scripts(EXECUTE_ON_POST_DLE_BACKUP,
> get_config_name(), dp, sched(dp)->level);
> + /* check dump not yet started */
> for (dp1=runq.head; dp1 != NULL; dp1 = dp1->next) {
> - if (dp1 != dp) last_dump = 0;
> + if (dp1->host == dp->host)
> + last_dump = 0;
> + }
> + /* check direct to tape dump */
> + for (dp1=directq.head; dp1 != NULL; dp1 = dp1->next) {
> + if (dp1->host == dp->host)
> + last_dump = 0;
> + }
> + /* check dumping dle */
> + for (dumper = dmptable; dumper < dmptable + inparallel; dumper++) {
> + if (dumper->busy && dumper->dp != dp &&
> + dumper->dp->host == dp->host)
> + last_dump = 0;
> }
> if (last_dump && dp->host->post_script == 0) {
> if (dp->host->post_script == 0) {
