move libusb from /usr/lib to /lib

Simo Sorce ssorce at redhat.com
Fri Jun 25 13:23:52 UTC 2010


----- "Chuck Anderson" <cra at WPI.EDU> wrote:

> On Thu, Jun 24, 2010 at 08:38:27PM +0200, Roberto Ragusa wrote:
> > Rob Crittenden wrote:
> > > Richard Hughes wrote:
> > >> On 23 June 2010 09:50, Tomasz Torcz <tomek at pipebreaker.pl> wrote:
> > >>> “/sbin/upsdrvctl is used as the near final step in
> /etc/init.d/halt to command
> > >> That's completely bogus. You really don't want to just power down
> the
> > >> machine like that -- it might lead to disk corruption and is
> certainly
> > >> not a good idea for a server with a huge power load.
> > >>
> > >> I really don't think we want this feature in Fedora.
> > >>
> > >> Richard.
> > >
> > > You're misunderstanding what this does. It doesn't cut power to
> the
> > > computer while its on. The process looks something like:
> > >
> > > - nut signals the UPS to shut down in x seconds (default 120)
> > > - nut halts the machine
> > > - after x seconds the UPS shuts down
> >
> > If the timeout is configurable, wouldn't be a reasonable option to
> > move the command away from the final seconds and use a larger
> timeout?
> >
> > I mean, if the timeout is 5 minutes, the system has 5 minutes to
> > shut down everything. It will probably do everything in 1 minute
> > and poweroff. After additional 4 minutes the UPS will power down.
> > I suppose these 4 minutes of "no-load" are not an issue.
> 
> It is conceivable that unmounting or other shutdown processes could
> take a long time, especially if network filesystems hang because an
> upstream network device lost power already.
> 
> Also, the closer to actual system halt you can turn off the actual
> load, the better.  You won't have to worry that something didn't
> shutdown yet and still maximize the remaining battery life of the UPS.

Ideally your UPS is smart enough to sense when the load drops to 0, and do whatever it needs to do w/o system intervention of any sort. If your UPS can't do that, maybe it is time to look for alternatives :)

Simo.



More information about the devel mailing list