Debian Bug report logs - #47454
powstatd: won't reboot if power restored after halt initiated

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Philippe Troin <phil@fifi.org>

To: submit@bugs.debian.org

Subject: Powstatd: packaging problems

Date: 14 Oct 1999 14:48:41 -0700

[Message part 1 (text/plain, inline)]

Package: powstatd
Version: 1.3-1

1. Powstatd should be installed in /sbin, or the
   /etc/init.d/{reboot,halt} won't find it while doing the final
   poweroff after power failure since the disks were unmounted.

2. /etc/init.d/ups-monitor should start reboots not halts. Rationale:
   if the power is failing and a reboot is engaged by powstatd, and
   the power comes back while the reboot is in progress, most UPSes
   will not kill the power supply when running powstatd -k and the
   computer will remain stuck in Halt. Then using reboot, it doesn't
   happen.

This enclosed patch takes care of both problems.

Phil.

[powstatd.packaging.diffs (application/octet-stream, attachment)]

Message #10 received at 47454@bugs.debian.org (full text, mbox, reply):

From: Peter S Galbraith <GalbraithP@dfo-mpo.gc.ca>

To: Philippe Troin <phil@fifi.org>, 47454@bugs.debian.org

Cc: Peter S Galbraith <GalbraithP@dfo-mpo.gc.ca>

Subject: Re: Bug#47454: Powstatd: packaging problems

Date: Thu, 14 Oct 1999 20:07:01 -0400

Philippe Troin wrote:

> 1. Powstatd should be installed in /sbin, or the
>    /etc/init.d/{reboot,halt} won't find it while doing the final
>    poweroff after power failure since the disks were unmounted.

I didn't think of that (my /usr is in the root partition).
 
> 2. /etc/init.d/ups-monitor should start reboots not halts. Rationale:
>    if the power is failing and a reboot is engaged by powstatd, and
>    the power comes back while the reboot is in progress, most UPSes
>    will not kill the power supply when running powstatd -k and the
>    computer will remain stuck in Halt. Then using reboot, it doesn't
>    happen.

I have yet to try this.  Isn't the timing of where we happen to
be during the reboot cycle critical when the power is cut by the
UPS critical? (That's a long sentence, can you parse that?)  What
if we've already rebooted and mounted the disks again?  (My work
machine with the UPS is SCSI, so the boot process is long.  But I
have an IDE mchine at home I could test this on).
 
What's your experience with this?

> This enclosed patch takes care of both problems.

Thanks Phil.

Peter Galbraith <psgdebian.org>

Message #15 received at 47454@bugs.debian.org (full text, mbox, reply):

From: Philippe Troin <phil@fifi.org>

To: Peter S Galbraith <GalbraithP@dfo-mpo.gc.ca>

Cc: 47454@bugs.debian.org

Subject: Re: Bug#47454: Powstatd: packaging problems

Date: 14 Oct 1999 17:23:33 -0700

Peter S Galbraith <GalbraithP@dfo-mpo.gc.ca> writes:

> Philippe Troin wrote:
> 
> > 2. /etc/init.d/ups-monitor should start reboots not halts. Rationale:
> >    if the power is failing and a reboot is engaged by powstatd, and
> >    the power comes back while the reboot is in progress, most UPSes
> >    will not kill the power supply when running powstatd -k and the
> >    computer will remain stuck in Halt. Then using reboot, it doesn't
> >    happen.
> 
> I have yet to try this.  Isn't the timing of where we happen to
> be during the reboot cycle critical when the power is cut by the
> UPS critical? (That's a long sentence, can you parse that?)  What
> if we've already rebooted and mounted the disks again?  (My work
> machine with the UPS is SCSI, so the boot process is long.  But I
> have an IDE mchine at home I could test this on).
>  
> What's your experience with this?

I'm not sure I parsed your sentence correctly.
This is what might happen with "shutdown -h":

                SYSTEM                              POWER
                Normal                                Up
                                                 No more power
        Shutdown -r 3 starts
            3 minutes pass 
  Shutdown starts killing all processes         
                                               Power comes back.
   Shutdown has killed all processes.
     Shutdown invokes powstatd -k              
                                            UPS refuses to shut down
                                               while power is on
          Powstatd -k timeouts.
            System is halted.
             We're stuck !

Whereas using reboots, if the above scenario happens, the machine will
reboot cleanly...

Am I clear ? :-)

Phil.

Message #20 received at 47454@bugs.debian.org (full text, mbox, reply):

From: Peter S Galbraith <GalbraithP@dfo-mpo.gc.ca>

To: Philippe Troin <phil@fifi.org>

Cc: 47454@bugs.debian.org, Peter S Galbraith <GalbraithP@dfo-mpo.gc.ca>

Subject: Re: Bug#47454: Powstatd: packaging problems

Date: Thu, 14 Oct 1999 21:53:01 -0400

Philippe Troin wrote:

> I'm not sure I parsed your sentence correctly.
> This is what might happen with "shutdown -h":
> 
>                 SYSTEM                              POWER
>                 Normal                                Up
>                                                  No more power
>         Shutdown -r 3 starts
>             3 minutes pass 
>   Shutdown starts killing all processes         
>                                                Power comes back.
>    Shutdown has killed all processes.
>      Shutdown invokes powstatd -k              
>                                             UPS refuses to shut down
>                                                while power is on
>           Powstatd -k timeouts.
>             System is halted.
>              We're stuck !

Yes, I understand the problem.

> Whereas using reboots, if the above scenario happens, the machine will
> reboot cleanly...

hen I said:

> >                          Isn't the timing of where we happen to
> > be during the reboot cycle critical when the power is cut by the
> > UPS critical? (That's a long sentence, can you parse that?)  What
> > if we've already rebooted and mounted the disks again?

I was wondering whether the following might happen with a reboot:

                 SYSTEM                              POWER
                 Normal                                Up
                                                  No more power
         Shutdown -h 3 starts
             3 minutes pass 
   Shutdown starts killing all processes         
    Shutdown has killed all processes.
      Shutdown invokes powstatd -k              
        UPS timer started for shut down 
         |    System is rebooted
         |     disks are mounted
         `-->   UPS shuts down
           We have disk corruption

But, thinking it through, the above can't happen because of
another problem.  The default Debian rc configuration doesn't
call /etc/init.d/halt on reboot, but only on halt.  The default
Debian rc configuration doesn't call ups-monitor in
/etc/init.d/reboot. Thus ups-monitor is not called to kill the
UPS on a power failure event with your change.

I could do one of two things (after making sure the above race
condition is not a problem):

 1- change (divert) /etc/init.d/reboot such that it also calls
    ups-monitor.

or

 2- forget about halt calling for the UPS shutdown (even though
 this is supposed to be how Debian works) and do like the
 upstream Powstatd setup does and call `powstatd -k` when the
 powstatd server is stopped (from `/etc/init.d/powstatd stop`
 which is done both by a halt and by a reboot).  This also
 introduces a race condition by which you hope the system will in
 fact shutdown correctly before the UPS actually cuts off power.
 I suppose that period of time could be minimized by moving back
 the shutdown of the powstatd server from K20powstatd to
 K89powstatd (we'd still have syslog, and a filesystem).

Comments?

Thanks for your input on this...

Peter

Message #25 received at 47454@bugs.debian.org (full text, mbox, reply):

From: Philippe Troin <phil@fifi.org>

To: Peter S Galbraith <GalbraithP@dfo-mpo.gc.ca>

Cc: 47454@bugs.debian.org

Subject: Re: Bug#47454: Powstatd: packaging problems

Date: 14 Oct 1999 19:51:44 -0700

Peter S Galbraith <GalbraithP@dfo-mpo.gc.ca> writes:

> Philippe Troin wrote:
> 
> > I'm not sure I parsed your sentence correctly.
> > This is what might happen with "shutdown -h":
> > 
> >                 SYSTEM                              POWER
> >                 Normal                                Up
> >                                                  No more power
> >         Shutdown -r 3 starts
> >             3 minutes pass 
> >   Shutdown starts killing all processes         
> >                                                Power comes back.
> >    Shutdown has killed all processes.
> >      Shutdown invokes powstatd -k              
> >                                             UPS refuses to shut down
> >                                                while power is on
> >           Powstatd -k timeouts.
> >             System is halted.
> >              We're stuck !
> 
> Yes, I understand the problem.
> 
> > Whereas using reboots, if the above scenario happens, the machine will
> > reboot cleanly...
> 
> hen I said:
> 
> > >                          Isn't the timing of where we happen to
> > > be during the reboot cycle critical when the power is cut by the
> > > UPS critical? (That's a long sentence, can you parse that?)  What
> > > if we've already rebooted and mounted the disks again?
> 
> I was wondering whether the following might happen with a reboot:
> 
>                  SYSTEM                              POWER
>                  Normal                                Up
>                                                   No more power
>          Shutdown -h 3 starts
>              3 minutes pass 
>    Shutdown starts killing all processes         
>     Shutdown has killed all processes.
>       Shutdown invokes powstatd -k              
>         UPS timer started for shut down 
>          |    System is rebooted
>          |     disks are mounted
>          `-->   UPS shuts down
>            We have disk corruption

Now I get it !
Form my experience, all UPSes I've seen shutdown within 2 seconds of
the shutoff signal (but only and only if there is no
power). 
Furthermore, the reset will reset the serial port states, before linux
even boots...

The above scenario looks very unlikely to me...

> But, thinking it through, the above can't happen because of
> another problem.  The default Debian rc configuration doesn't
> call /etc/init.d/halt on reboot, but only on halt.  The default
> Debian rc configuration doesn't call ups-monitor in
> /etc/init.d/reboot. Thus ups-monitor is not called to kill the
> UPS on a power failure event with your change.

Damn, must be my local changes...

> I could do one of two things (after making sure the above race
> condition is not a problem):
> 
>  1- change (divert) /etc/init.d/reboot such that it also calls
>     ups-monitor.

I wouldn't divert shuch an important file...

> or
> 
>  2- forget about halt calling for the UPS shutdown (even though
>  this is supposed to be how Debian works) and do like the
>  upstream Powstatd setup does and call `powstatd -k` when the
>  powstatd server is stopped (from `/etc/init.d/powstatd stop`
>  which is done both by a halt and by a reboot).  This also
>  introduces a race condition by which you hope the system will in
>  fact shutdown correctly before the UPS actually cuts off power.
>  I suppose that period of time could be minimized by moving back
>  the shutdown of the powstatd server from K20powstatd to
>  K89powstatd (we'd still have syslog, and a filesystem).

That's a no-no, the power might go off in the middle of the unmount
while disks are being synced... possibly a lot of damage.

I'd say that the best way is to alter the policy and the sysvinit
package so that the reboot includes the check for ups-monitor.

IMHO, all UPS packages ought to do the "shutdown -r" instead of
"shutdown -h".

Phil.

Message #30 received at 47454@bugs.debian.org (full text, mbox, reply):

From: Peter S Galbraith <GalbraithP@dfo-mpo.gc.ca>

To: Philippe Troin <phil@fifi.org>

Cc: 47454@bugs.debian.org, Peter S Galbraith <GalbraithP@dfo-mpo.gc.ca>

Subject: Re: Bug#47454: Powstatd: packaging problems

Date: Thu, 14 Oct 1999 23:50:10 -0400

Philippe Troin wrote:

> Peter S Galbraith <GalbraithP@dfo-mpo.gc.ca> writes:
> > I was wondering whether the following might happen with a reboot:
> > 
> >                  SYSTEM                              POWER
> >                  Normal                                Up
> >                                                   No more power
> >          Shutdown -h 3 starts
> >              3 minutes pass 
> >    Shutdown starts killing all processes         
> >     Shutdown has killed all processes.
> >       Shutdown invokes powstatd -k              
> >         UPS timer started for shut down 
> >          |    System is rebooted
> >          |     disks are mounted
> >          `-->   UPS shuts down
> >            We have disk corruption
> 
> Now I get it !
> Form my experience, all UPSes I've seen shutdown within 2 seconds of
> the shutoff signal (but only and only if there is no power). 

What UPS do you have?  I have two CyberPower units (different
models) and they cut power about 30 seconds after the kill
signal.

> Furthermore, the reset will reset the serial port states, before linux
> even boots...
> 
> The above scenario looks very unlikely to me...

> > I could do
> >  2- forget about halt calling for the UPS shutdown (even though
> >  this is supposed to be how Debian works) and do like the
> >  upstream Powstatd setup does and call `powstatd -k` when the
> >  powstatd server is stopped (from `/etc/init.d/powstatd stop`
> >  which is done both by a halt and by a reboot).  This also
> >  introduces a race condition by which you hope the system will in
> >  fact shutdown correctly before the UPS actually cuts off power.
> >  I suppose that period of time could be minimized by moving back
> >  the shutdown of the powstatd server from K20powstatd to
> >  K89powstatd (we'd still have syslog, and a filesystem).
> 
> That's a no-no, the power might go off in the middle of the unmount
> while disks are being synced... possibly a lot of damage.

You see, with the 30 seconds delay, that's unlikely on my system.
 
> I'd say that the best way is to alter the policy and the sysvinit
> package so that the reboot includes the check for ups-monitor.
> 
> IMHO, all UPS packages ought to do the "shutdown -r" instead of
> "shutdown -h".

I'll test to see if the 30 second delay makes this a non-starter
for me.  I agree that the case you brought up is real, and should
be dealt with in all UPS package, and not just powstatd.

(BTW, I sent your `other' bug report/enhancements upstream and
will wait a little for a response before I reply to the BTS.
You're an active hacker, aren't you!)

Peter - who's going to bed now...

Message #35 received at 47454@bugs.debian.org (full text, mbox, reply):

From: Philippe Troin <phil@fifi.org>

To: Peter S Galbraith <GalbraithP@dfo-mpo.gc.ca>

Cc: 47454@bugs.debian.org

Subject: Re: Bug#47454: Powstatd: packaging problems

Date: 14 Oct 1999 21:12:53 -0700

Peter S Galbraith <GalbraithP@dfo-mpo.gc.ca> writes:

> Philippe Troin wrote:
>
> You see, with the 30 seconds delay, that's unlikely on my system.
>  
> > I'd say that the best way is to alter the policy and the sysvinit
> > package so that the reboot includes the check for ups-monitor.
> > 
> > IMHO, all UPS packages ought to do the "shutdown -r" instead of
> > "shutdown -h".
> 
> I'll test to see if the 30 second delay makes this a non-starter
> for me.  I agree that the case you brought up is real, and should
> be dealt with in all UPS package, and not just powstatd.

Mmmh, 30 seconds ? Gosh. I've seen all APC and TrippLite UPS shutdown
really quickly... That breaks the theory...
Is it 30 seconds of applying the powerdown signal or 30 seconds after
the signal has been applied ?


> (BTW, I sent your `other' bug report/enhancements upstream and
> will wait a little for a response before I reply to the BTS.
> You're an active hacker, aren't you!)

Thanks.
It's a pretty big patch...
Hacking too much these days...

Phil.

Message #40 received at 47454@bugs.debian.org (full text, mbox, reply):

From: Peter S Galbraith <GalbraithP@dfo-mpo.gc.ca>

To: Philippe Troin <phil@fifi.org>

Cc: 47454@bugs.debian.org, Peter S Galbraith <GalbraithP@dfo-mpo.gc.ca>

Subject: Re: Bug#47454: Powstatd: packaging problems

Date: Fri, 15 Oct 1999 10:15:06 -0400

Philippe Troin wrote:

> Peter S Galbraith <GalbraithP@dfo-mpo.gc.ca> writes:
> 
> > I'll test to see if the 30 second delay makes this a non-starter
> > for me.  I agree that the case you brought up is real, and should
> > be dealt with in all UPS package, and not just powstatd.
> 
> Mmmh, 30 seconds ? Gosh. I've seen all APC and TrippLite UPS shutdown
> really quickly... That breaks the theory...
> Is it 30 seconds of applying the powerdown signal or 30 seconds after
> the signal has been applied ?

After the signal has been applied and the shutdown continues.
I'll run proper tests this weekend to make sure it really is 30
seconds. 

Apart from that, I realised this morning that there's no need to
modify /etc/init.d/reboot.  All we need is to _add_ another rc
script /etc/rc6.d/S89ups-reboot -> /etc/init.d/ups-reboot or
something.  But first I'll investigate this timing issue.  Maybe
it can be part of the package configuration whether you want to
reboot at one stage or halt at another, depending on the delay
your UPS has before killing power.

I'll be away this weekend, but I'll be in touch next week after
some tests.  Let me know when you get tired of this discussion! ;-)

Thanks,
Peter

Message #45 received at 47454@bugs.debian.org (full text, mbox, reply):

From: Philippe Troin <phil@fifi.org>

To: Peter S Galbraith <GalbraithP@dfo-mpo.gc.ca>

Cc: 47454@bugs.debian.org

Subject: Re: Bug#47454: Powstatd: packaging problems

Date: 15 Oct 1999 16:41:33 -0700

Peter S Galbraith <GalbraithP@dfo-mpo.gc.ca> writes:

> Philippe Troin wrote:
> 
> > Peter S Galbraith <GalbraithP@dfo-mpo.gc.ca> writes:
> > 
> > > I'll test to see if the 30 second delay makes this a non-starter
> > > for me.  I agree that the case you brought up is real, and should
> > > be dealt with in all UPS package, and not just powstatd.
> > 
> > Mmmh, 30 seconds ? Gosh. I've seen all APC and TrippLite UPS shutdown
> > really quickly... That breaks the theory...
> > Is it 30 seconds of applying the powerdown signal or 30 seconds after
> > the signal has been applied ?
> 
> After the signal has been applied and the shutdown continues.
> I'll run proper tests this weekend to make sure it really is 30
> seconds. 
> 
> Apart from that, I realised this morning that there's no need to
> modify /etc/init.d/reboot.  All we need is to _add_ another rc
> script /etc/rc6.d/S89ups-reboot -> /etc/init.d/ups-reboot or
> something.  But first I'll investigate this timing issue.  Maybe
> it can be part of the package configuration whether you want to
> reboot at one stage or halt at another, depending on the delay
> your UPS has before killing power.

Mmmh, that's a good idea until sysvinit incorporates the ups-monitor
test. Actually I was thinking that your problems might be resolved by
sleep by a configurable about of time after the ups shutdown...
Something like this S99reboot (or your temporary S98upsshutdown)

       #! /bin/sh
       #
       # reboot	Execute the reboot command.
       #
       # Version:      @(#)reboot  2.75  22-Jun-1998  miquels@cistron.nl
       #
       
       PATH=/sbin:/bin:/usr/sbin:/usr/bin
       ups_shutdown_delay=30
       
       # See if we need to cut the power.
       if [ -x /etc/init.d/ups-monitor ]
       then
	       if /etc/init.d/ups-monitor poweroff
	       then
                   sleep $ups_shutdown_delay
	       fi
       fi
       
       # Include this if we're talking about S99reboot, not if S98upsshutdown
       echo -n "Rebooting... "
       reboot -d -f -i

This way, we'll wait for the ups to shutdown only if the kill was
succesful. Powstatd -k returns non-zero exit status if the power is on
AFAIK, and /etc/init.d/ups-monitor has just to propagate the exit code
to S99reboot. This way we don't sleep when we're doing a regular
reboot...

I still think the policy should be updated to do this...

> I'll be away this weekend, but I'll be in touch next week after
> some tests.  Let me know when you get tired of this discussion! ;-)

Not tired yet...

Phil.

Message #50 received at 47454@bugs.debian.org (full text, mbox, reply):

From: Peter S Galbraith <psg@debian.org>

To: control@bugs.debian.org, 47454@bugs.debian.org

Cc: Philippe Troin <phil@fifi.org>, Peter S Galbraith <GalbraithP@dfo-mpo.gc.ca>

Subject: Re: Powstatd: packaging problems

Date: Tue, 26 Oct 1999 23:37:41 -0400

severity 47454 wishlist
thanks

> 1. Powstatd should be installed in /sbin, or the
>    /etc/init.d/{reboot,halt} won't find it while doing the final
>    poweroff after power failure since the disks were unmounted.

Powstatd version 1.3-2 now has the /sbin/powstatd instead of
/usr/sbin/powstatd.  Thanks, that was indeed a packaging error.
That fixes that part of the bug report. 

> 2. /etc/init.d/ups-monitor should start reboots not halts. Rationale:
>    if the power is failing and a reboot is engaged by powstatd, and
>    the power comes back while the reboot is in progress, most UPSes
>    will not kill the power supply when running powstatd -k and the
>    computer will remain stuck in Halt. Then using reboot, it doesn't
>    happen.

We don't have a consensus here. As my UPS has a 30 second delay
before it cuts power after a kill signal, a reboot instead of
halt could have it fsck'ing disks after a reboot by the time the
power is cut, and that would be bad.

I'll save this as a wishlist item to let the user decide whether
(s)he wants a halt or a reboot to occur, depending on their own
setup and UPS type.

Thanks.

Peter

Message #57 received at 47454@bugs.debian.org (full text, mbox, reply):

From: Peter S Galbraith <psg@debian.org>

To: 47454@bugs.debian.org, Philippe Troin <phil@fifi.org>

Cc: Peter S Galbraith <GalbraithP@dfo-mpo.gc.ca>

Subject: Forgot about your sleep suggestion!

Date: Wed, 27 Oct 1999 09:43:26 -0400

Hi Phil,

I was re-reading the BTS log today and saw your `sleep'
suggestion.  I wonder how I managed to forget about that.

The wishlist item is therefore to implement this `sleep and
reboot' feature in such a way that makes it optional (as opposed
to halt, which is easier for the user to configure since the UPS
kill delay does not enter the equation).

Thanks
Peter

Message #62 received at 47454@bugs.debian.org (full text, mbox, reply):

From: Peter S Galbraith <psg@debian.org>

To: control@bugs.debian.org, 47454@bugs.debian.org

Cc: Philippe Troin <phil@fifi.org>, Peter S Galbraith <GalbraithP@dfo-mpo.gc.ca>

Subject: Re: Powstatd: packaging problems

Date: Thu, 28 Oct 1999 09:39:59 -0400

severity 47454 normal
thanks

Changed my mind again.  I had in mind that the critical time span
during which power being restored would result in a hung system
was between sending the UPS a kill signal and the UPS actually
killing power.

Of course, the time span is longer than that.  As soon as we have
initiated the halt sequence we have effectively lost control
should the power come back.  This is bad for far-away unattended
systems, so I'm upgrading the status to normal.  I should add an
optional setup to reboot instead of halting the system (optional
because he `sleep' time you suggested is a critical parameter
that can cause more damage than good if improperly set).

Crazy thought, we can call `reboot -d -f -i' from
/etc/init.d/halt if it's detected that the power has been
restored (Actually, the reboot would be called from
`/etc/init.d/ups-monitor poweroff' which is called by
/etc/init.d/halt just before actually halting the system).  That
would reduce that critical time span.  I'd need to add a state
file to be sure of when /etc/init.d/halt was called for cases of
power failure, but those hooks are already in the package.
Still, if the power came back after sending the UPS a kill signal
but before the UPS actually killed power, the system would hang
in halted state.  But it still leads to a shorter time periode of
being vulnerable to the power being restored for users not using
the above reboot option.

Peter

Message #69 received at 47454@bugs.debian.org (full text, mbox, reply):

From: Peter S Galbraith <psg@debian.org>

To: 47454@bugs.debian.org, Philippe Troin <phil@fifi.org>

Subject: Bug 47454: Powstatd: packaging problems

Date: Tue, 28 Oct 2003 13:49:19 -0500

My last correspondence with this bug report was exactly 4 years ago.
This is by far my oldest bug now.

So here's the holdup... the proposed fix was submitted for inclusion in
the sysvinit package a long time ago (3 years and 287 days) in 

 http://bugs.debian.org/55123

I don't know if it will ever happen.  Maybe I should implement my own
solution entirely within the powstatd package of a new `halt' script
which would run prior to sysvinit's halt script.

Peter

Message #76 received at 47454-done@bugs.debian.org (full text, mbox, reply):

From: Debian FTP Masters <ftpmaster@ftp-master.debian.org>

To: 47454-done@bugs.debian.org,603535-done@bugs.debian.org,831301-done@bugs.debian.org,

Cc: powstatd@packages.debian.org, powstatd@packages.qa.debian.org

Subject: Bug#843489: Removed package(s) from unstable

Date: Fri, 25 Nov 2016 19:10:10 +0000

Version: 1.5.1-9.1+rm

Dear submitter,

as the package powstatd has just been removed from the Debian archive
unstable we hereby close the associated bug reports.  We are sorry
that we couldn't deal with your issue properly.

For details on the removal, please see https://bugs.debian.org/843489

The version of this package that was in Debian prior to this removal
can still be found using http://snapshot.debian.org/.

This message was generated automatically; if you believe that there is
a problem with it please contact the archive administrators by mailing
ftpmaster@ftp-master.debian.org.

Debian distribution maintenance software
pp.
Scott Kitterman (the ftpmaster behind the curtain)

Send a report that this bug log contains spam.