Re: [Nut-upsuser] ordered shutdown
Arjen de Korte ha scritto: You can configure NUT to shutdown at a certain battery.charge too, with the UPS you're using, that's what I have been telling you a couple of times already. But I already know it! I was just wondering why NUT works differently and lacks those features. I said I could/should even care whether the battery charge is low or not, the only thing I know is that at _event_ [battery_charge | runtime | elapsed_time] (like PSP natively and in an intuitive way does) I want to start shutdown procedure. I'd like the same freedom of choice, why only low battery is that relevant in NUT? That's the juice. However, never mind... Moreover I'd like to choose, in this low_battery - full battery range, when to powerdown different systems, still on different basis. This won't work with MGE PSP either, so the comparison doesn't hold here. Well, right, but PSP it's not intended for network use, while NUT indeed it is. I took it as example for showing the above reason and how easy is to choose from different criteria in a standalone environment: http://i39.tinypic.com/2mpy9s6.png If I'm not wrong it should be pretty easy to set up ordered shutdown with different criteria in apcupsd too. Me and some other people reported that actually NUT can't easily cope with similar requests. Is there something more to comment on that? However, the solution you wrote about is fine, so let's wait for implementation. Which is for a totally different thing we're talking about. Ok, it is for the whole features we were talking about. Never mind, please step over. Thank you again, but I have read every single piece of documentation aviable, I'm just waiting for the features I need ;-) I beg to differ here... :-( As you like, but again there's nothing that the man pages can do for the lack of ordered shutdown or different criteria and maybe powershare. So, I'll keep waiting for the features. :-) Regards, Marco Chiappero ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] ordered shutdown
Citeren Marco Chiappero ma...@absence.it: Well, right, but PSP it's not intended for network use, while NUT indeed it is. I took it as example for showing the above reason and how easy is to choose from different criteria in a standalone environment: http://i39.tinypic.com/2mpy9s6.png You hit the nail on the head. While it is fairly easy to change shutdown parameters in a standalone application, this is not so easy in a networked environment. In a standalone application, you can rest assured that once the shutdown condition has been reached, the system *will* go down and recovering from that is fairly straightforward too (since this will be dealt with by the UPS itself). No need to deal with transient conditions. In a networked environment with multiple shutdown levels, you'll also have to deal with transient conditions and also with the situation where the power returns between two levels (and how to recover from that) and making this system fail safe too. This is vastly more difficult to handle. If I'm not wrong it should be pretty easy to set up ordered shutdown with different criteria in apcupsd too. Me and some other people reported that actually NUT can't easily cope with similar requests. Is there something more to comment on that? Yes, there is. If extending runtime by shutting down loads is essential to you, chances are that what you really need is a generator. Most of the power outages you'll experience in everyday life will be short lived (in the order of seconds, mainly due to switching operation in the grid), which are corrected automatically. This is something that can dealt with easily with the runtime of basically any UPS in existance. Longer outages are usually mean that something is broken that can't be corrected automatically and/or requiring human intervention/replacement of systems. This means that the outage will be much longer than the runtime of UPS batteries. No matter how much load you're shedding. Even at no load, most UPS systems won't hold up longer than about 45 to 60 minutes. If you've already used up part of the juice, it will be even less. So you're systems *are* going down in that situation. If losing (some) systems is really a big deal to you, having a UPS is only part of the solution. Personally, I feel the option to shutdown part of the loads depending on battery charge or runtime remaining is largely a waste of effort. You'll still have to deal with the situation where the battery state triggers shutdown on all systems at the same time (after recovering from an outage, followed by another outage for instance). [...] So, I'll keep waiting for the features. :-) ...instead of working toward a solution. You see where the root of this problem lies? The active developers don't have this high on their list of features and the people that want this, don't provide any help in adding them. Don't hold your breath waiting. ;-) Best regards, Arjen -- Please keep list traffic on the list ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] ordered shutdown
Arjen de Korte ha scritto: Citeren Marco Chiappero ma...@absence.it: It's funny that you mention MGE PSP here, since except for the shutdown timer (reason explained in the FAQ), NUT already provides *all* functionality it has (including shutdown based on charge and runtime). What you may be missing is the fact that this requires setting values on the UPS through the 'upsrw' command to control the level when the UPS will decide the battery is low. As far as I remember in PSP there are two different regulations, battery charge level that triggers system shutdown and battery charge level that set the low battery state. I suppose it uses the first one that occurs. If I'm not wrong. You're wrong. :-) I don't think so :-) Yesterday I had a try with my windows laptop. Here you can see how it works: http://i43.tinypic.com/2n20778.png You can set the low battery level as a lower bound, so you have a low_battery - full_battery interval where you can freely place a time point, on different basis, which start the shutdown procedure. That's what I'd call freedom of choice, I can choose what event should trigger the shutdown and when (without recurring to external utilities), you just have not to be in low battery yet. It is something important that many software already have. Moreover I'd like to choose, in this low_battery - full battery range, when to powerdown different systems, still on different basis. However, the solution you wrote about is fine, so let's wait for implementation. [...] Yes, I know. Thank you again, but I have read every single piece of documentation aviable, I'm just waiting for the features I need ;-) Regards Marco Chiappero ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] ordered shutdown
Citeren Marco Chiappero ma...@absence.it: You're wrong. :-) I don't think so :-) Yes you are. :-) Yesterday I had a try with my windows laptop. Here you can see how it works: http://i43.tinypic.com/2n20778.png You can configure NUT to shutdown at a certain battery.charge too, with the UPS you're using, that's what I have been telling you a couple of times already. Go read 'man upsrw' and fire it up for your UPS. You'll find that you can freely configure the 'battery.charge.low' on it. You can set the low battery level as a lower bound, so you have a low_battery - full_battery interval where you can freely place a time point, on different basis, which start the shutdown procedure. That's what I'd call freedom of choice, I can choose what event should trigger the shutdown and when (without recurring to external utilities), you just have not to be in low battery yet. It is something important that many software already have. NUT has it too for devices (including yours) that support setting this. Moreover I'd like to choose, in this low_battery - full battery range, when to powerdown different systems, still on different basis. This won't work with MGE PSP either, so the comparison doesn't hold here. However, the solution you wrote about is fine, so let's wait for implementation. Which is for a totally different thing we're talking about. Please don't mix up configuration of battery.charge.low (which is already supported) and multiple shutdown levels for different outputs (which currently isn't supported). The example you're giving here, has nothing to do with ordered shutdowns. Thank you again, but I have read every single piece of documentation aviable, I'm just waiting for the features I need ;-) I beg to differ here... :-( Best regards, Arjen -- Please keep list traffic on the list ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] ordered shutdown
Citeren Marco Chiappero ma...@absence.it: It's funny that you mention MGE PSP here, since except for the shutdown timer (reason explained in the FAQ), NUT already provides *all* functionality it has (including shutdown based on charge and runtime). What you may be missing is the fact that this requires setting values on the UPS through the 'upsrw' command to control the level when the UPS will decide the battery is low. As far as I remember in PSP there are two different regulations, battery charge level that triggers system shutdown and battery charge level that set the low battery state. I suppose it uses the first one that occurs. If I'm not wrong. You're wrong. :-) In MGE PSP you can set the equivalent what we call in NUT 'battery.charge.low' and 'battery.charge.restart'. The first will determine the level that triggers the 'battery low' warning (and system shutdown), but the second does something completely different. You don't want to restart your systems if there isn't sufficient battery charge left to cleanly shut them down. Imaging that the power returns, but fails after one or two minutes again (maybe the fuse that was replaced, blew again). In that time, the server will probably have restarted, but the UPS batteries will still be almost empty and there may not be enough time to shutdown cleanly. This is where the 'battery.charge.restart' level comes into play. It will make the UPS not power up the outputs again until the battery has been recharged to a certain level again (which of course should be enough to do a full restart/power down cycle). In that case, no matter how often the mains fails, there will always be enough juice in the battery to shut your systems down cleanly. See also what is written about this at the bottom of 'docs/shutdown.txt'. Generally speaking, the 'battery.charge.restart' level should be *higher* than 'battery.charge.low' (if you understood the problem, you'll know why). Best regards, Arjen -- Please keep list traffic on the list ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] ordered shutdown
Arjen de Korte ha scritto: [waking up from shutdown before battery exhaustion] With whatever strategy you use, you need to be able to send some kind of command (power on, WOL magic, whatever) at the right time. Yeah, but I can't see any real difficulty. What does NOTIFTCMD stand for? Maybe the server (if client aware) could let the user choose some more options or predefined actions, shouldn't be difficult to implement. I can't see why this solution is worse than having to deal with upssched and its script, which I consider much a dirty hack. Shutting down is 'easy' when there is one point in time where you can decide to shutdown whatever is connected (what we have now) possibly with some kind of sequencing and then power cycle the UPS. What people are asking now, is to have multiple decision moments Exactely and for each one you must guarantee that you're able to return to the normal state with as little impact on other systems. This would be useful too, but I would be happy enough just having different shutdown moments based on timer|charge|runtime as apcupsd and MGE's psp[1] do natively (and as it should be)! Maybe there is a person in front of the computer you powered down, that can switch it on. Why not to let the people choose the strategy they prefer? In that case, put these scripts on a network drive. They don't have to live in /etc/ups (or whatever is compiled in). Obviously you can do it, but it's not a much better solution. Having to set up a file server to accomplish what, in my opinion, NUT should do natively it's certainly not a solution. To sum up, in priority order: 1) different shutdown criteria 2) different shutdown time points 3) automatic restart management / automatic programmable outlet power on The third is not required for implementing points 1 and 2. The first one is absolutely the most important and already present in any UPS tool I've seen. Beyond these requests, I believe a better design is required to address some other needs, discussed in the previous mails, but I know that it is something that, first of all, you should feel it's right, and it's not always possible to modify a project. However I like to discuss about these ideas. Just my opinion. Regards, Marco Chiappero [1] Yes, a normal user can choose pointing and clicking, while upssched is considered a complicated option for nerds. ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] ordered shutdown
Arjen de Korte ha scritto: Citeren Marco Chiappero ma...@absence.it: And centralized is a very important keyword here; having to modify upssched scripts on dozens of machines when the plan changes is a real PITA. I agree, and that's the reason why I said there is a need for a director. It takes care about settings and actions, clients should only obey and possibly show UPS informations. It's also a metter of role: the system managing the UPS is the only one that should decide and control who can keep running and for how long, not the server administrator (and maybe you're not even the server owner or admin)! This should also make the powershare feature easier to implement since the computer controlling the UPS knows everything. Please elaborate here, because as far as I know we already have this (the 'upsd' server). Please read the last mail from Gabor, his idea it's really close to mine. To me clients have to be as stupid as possible (requiring almost no configuration) and simply obey to commands issued by the server. This means that clients shutdown configuration has to be done on the machine controlling the UPS(es). This way it is the server (connected to the UPS) that allows someone to use the UPS it owns for the time it considers fine, it is not a client that tells the server how much it wants to stay up (a slave upsmon works this way, right?). Ok, how to achive this? Writing two different programs, client and server, is an idea, but we can think of something more modular: an hardware layer (eg. nutupsdrv), a communication and action maker/execution layer, and a decision layer managing shutdown orders. So, on the client side just the second layer is needed, it takes care of speaking with the server (for UPS readings too [1]) and executing shutdown and/or notify commands received by the server. Note that on this side you have to configure just a few settings. On the server side we need all the stack of components, the decision maker on top of the communication and execution layer, in turn on top of the hardware layer. The decision layer reads the configuration file(s) containing shutdown policies for all the machines (or group of machines) it can assume to control, and then, when needed, it passes orders to the lower layer. Again on the server side, the communication and execution layer dispatches informations between the hardware, the brainless clients and the brain itself. Note that this layer can be the same on both clients and server. Let's suppose we already powered down some clients and power is back, the mean layer (which is on top of the hardware) notify the event to the upper decision layer, this one orders to start an action such as executing script or restoring power on a specific programmable outlet, maybe after some time or when enough charge is reached. If low battery level is reached, then we trigger shutdown for everyone is still up. Well, I'm not experienced and maybe it's not a good approach, but I like it. You can think it's better to have clever clients as it is now, but at this moment upsmon is lacking the features already discussed. However, just considerations and comments are welcome. Regards, Marco Chiappero [1] The server can offer some services or information to the clients. ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] ordered shutdown
Citeren Gabor Gombas gomb...@sztaki.hu: The first step would be to have a _central_ way to manage when to shut a specific class of clients down. Having to muck with upssched scripts on every client just does not scale. IMHO the clients should just say hello, I'm of class X when logging into the UPS, and it should be upsd's job to say clients of class X start to shut down NOW, everyone else wait. This would still require configuration on the part of the clients to set the class. But I agree with the fact that this should be managed in a centralized way. I intend to do this by adding 'virtual' UPS devices that clients can connect to in the usual manner. By doing so, the interface to existing client applications (not only the ones we provide) remains intact. So something like big-...@example.com (actual UPS) whatever@example.com (virtual UPS) In this case, clients can connect to either of the above (or more than one), which will look to them as a 'real' UPS. All the power sequencing would be handled on the server, including the decision to shutdown a certain virtual UPS. Doing so effectively means that from the moment this is added, all existing clients can start using this. Being able to turn clients that were logged in to the UPS when their shutdown was ordered back on is the next logical step after the above, but for a start I'd be happy with the shutdown part. Noted. If you're not already subscribed to the nut-upsdev mailinglist, please do so, since usually changes like the above will be announced there first. Best regards, Arjen -- Please keep list traffic on the list ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] ordered shutdown
Citeren Marco Chiappero ma...@absence.it: This would be useful too, but I would be happy enough just having different shutdown moments based on timer|charge|runtime as apcupsd and MGE's psp[1] do natively (and as it should be)! It's funny that you mention MGE PSP here, since except for the shutdown timer (reason explained in the FAQ), NUT already provides *all* functionality it has (including shutdown based on charge and runtime). What you may be missing is the fact that this requires setting values on the UPS through the 'upsrw' command to control the level when the UPS will decide the battery is low. What we currently don't have, is multiple decision levels, but this is something that will be dealt with through the use of virtual UPS devices that are accessible through the regular interface. In that case, put these scripts on a network drive. They don't have to live in /etc/ups (or whatever is compiled in). Obviously you can do it, but it's not a much better solution. Having to set up a file server to accomplish what, in my opinion, NUT should do natively it's certainly not a solution. That depends a lot on your configuration. If you already have many more or less identical clients on your system, chances are that this file server will already source the configuration for these systems. I know of quite a couple of large installations where NUT is used where this is the case and this is quite a workable setup. [...] 1) different shutdown criteria We already have that if the UPS supports it. If it doesn't support it, we don't and won't do that. There is far too much crappy UPS hardware around to add this for units that don't support this natively. 2) different shutdown time points This will be added but is currently lacking development time and attention. 3) automatic restart management / automatic programmable outlet power on We won't add #2 without #3. The third is not required for implementing points 1 and 2. Not at all. Without this, unattended shutdowns are just not an option, which is the base of NUT. The first one is absolutely the most important and already present in any UPS tool I've seen. See above. For devices that support this, NUT already has this. If I remember correctly you have a MGE Evolution 650 and I know that this is supported (for a couple of releases already). What is much more important than the issues you raise, is the fact that configuration of NUT is much too complicated at the moment. Many people simply give up because of the overwhelming amount of configuration required to setup simple monitoring of their UPS. Best regards, Arjen -- Please keep list traffic on the list ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] ordered shutdown
Citeren Marco Chiappero ma...@absence.it: Please elaborate here, because as far as I know we already have this (the 'upsd' server). Please read the last mail from Gabor, his idea it's really close to mine. To me clients have to be as stupid as possible (requiring almost no configuration) and simply obey to commands issued by the server. This means that clients shutdown configuration has to be done on the machine controlling the UPS(es). This way it is the server (connected to the UPS) that allows someone to use the UPS it owns for the time it considers fine, it is not a client that tells the server how much it wants to stay up (a slave upsmon works this way, right?). If you run the upsmon master on the same box as the upsd server, all upsmon slaves connected to the same UPS will shutdown at the same time as the upsmon master. So effectively, you already have a centralized setup if you configure things properly. There is absolutely no need to run 'upssched' on every client if they should all go down at the same time, just run it on the master and you'll be fine. The only thing that remains is that we need different 'virtual' UPSes that can be shutdown at different battery.(charge|runtime) levels and you have pretty much exactly what Gabor describes. Best regards, Arjen -- Please keep list traffic on the list ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] ordered shutdown
Arjen de Korte ha scritto: It's funny that you mention MGE PSP here, since except for the shutdown timer (reason explained in the FAQ), NUT already provides *all* functionality it has (including shutdown based on charge and runtime). What you may be missing is the fact that this requires setting values on the UPS through the 'upsrw' command to control the level when the UPS will decide the battery is low. As far as I remember in PSP there are two different regulations, battery charge level that triggers system shutdown and battery charge level that set the low battery state. I suppose it uses the first one that occurs. If I'm not wrong. What we currently don't have, is multiple decision levels, but this is something that will be dealt with through the use of virtual UPS devices that are accessible through the regular interface. Ok, I've understood now, sorry for not understanding before. It's definitely a good idea, the best one, that solves all these aspects. I think you answered all my questions, thank you. And sorry for being boring. Regards, Marco Chiappero ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] ordered shutdown
Hallo Arjen, Arjen de Korte nut+us...@de-korte.org schrieb: Citeren Lars Täuber taeu...@bbaw.de: [...] The above values would be an extremely bad idea and this is also not how NUT works. See the FAQ. [...] What you describe is not how NUT works. Until the UPS signals that the battery is low, it is business as usual (see the FAQ for the reasons behind this). Once the UPS signals battery low, all timers are started at the same time and there is no way to stop the following sequence of events. The systems *will* go down. If the power returns during the shutdown sequence, the shutdown sequence will be completed and NUT will power-cycle the UPS to make sure the connected systems are restarted. it seems I understood how NUT works now. But then it is not the solution for us. The reason simply is we have one big ups for so many servers. And it's a bad idea to have one point in time to shutdown all servers. So one »battery low« signal for all servers is not what we need. There are some servers that should work as long as possible and shut down shortly (2 minutes) before the ups shuts off. But these server also should try to shut down and that's why they need the connection to the ups too. Is it possible with NUT to tell upsd to initiate a shutdown by the means of upssched? As long as I understood upssched doesn't run as root. So it can't be used to initiate a shutdown directly. Thanks Lars ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] ordered shutdown
Citeren Lars Täuber taeu...@bbaw.de: it seems I understood how NUT works now. But then it is not the solution for us. The reason simply is we have one big ups for so many servers. And it's a bad idea to have one point in time to shutdown all servers. So one »battery low« signal for all servers is not what we need. In that case, I probably don't understand what you're trying to do. There are some servers that should work as long as possible and shut down shortly (2 minutes) before the ups shuts off. But these server also should try to shut down and that's why they need the connection to the ups too. So you want the servers to keep running as long as possible and the clients should go down after a power outage of (say) five minutes? That's possible too. Is it possible with NUT to tell upsd to initiate a shutdown by the means of upssched? As long as I understood upssched doesn't run as root. So it can't be used to initiate a shutdown directly. Sure. But if you can describe more clearly what you're trying to do, we might come up with other alternatives as well, as I don't think this is what you want to do. Best regards, Arjen -- Please keep list traffic on the list ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] ordered shutdown
Hi Arjen, Arjen de Korte nut+us...@de-korte.org schrieb: Citeren Lars Täuber taeu...@bbaw.de: In that case, I probably don't understand what you're trying to do. sorry for my english. So you want the servers to keep running as long as possible and the clients should go down after a power outage of (say) five minutes? That's possible too. Let's assume we have a lot of servers and each should start it's shutdown sequence at a different level of time left of the ups running on batteries. Could you give an example of a configuration for two different servers then? Thanks Lars ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] ordered shutdown
Arjen de Korte ha scritto: Citeren Lars Täuber taeu...@bbaw.de: it seems I understood how NUT works now. But then it is not the solution for us. The reason simply is we have one big ups for so many servers. And it's a bad idea to have one point in time to shutdown all servers. So one »battery low« signal for all servers is not what we need. In that case, I probably don't understand what you're trying to do. I think I know what he meant, because my needs are similar. I already explained them some time ago, when I discovered that NUT comes with no features at all about programmable outlets (right now I still have no shutdown sequence settled yet). When you have one ups and many computers with different needs the low battery signal starts having no use (well, it can be useful but just for the last computers you want to shut down). Let's assume I have one big UPS, some clients and a couple of servers. Now suppose that we want some clients to shut down immediately, as they are not important, but some not, maybe when it's clear that it's a serious outage (and we prefer to save power for the servers). So I would trigger shutdown for the first clients when battery charge is 95% (just to be sure it's not a realy short and temporary outage) and when charge is 50-60% for the second ones. Finally I'd like to start the powerdown sequence for the two servers when 15-20% charge is reached. That's the problem, and in the problem description there's no need to indicate a low battery value. We can use it for the servers but who cares, it's not important the name you attribute to the 20% charge level. About the clients, upssched it's not the right way for doing this, in my opinion. From my standpoint, the computer owning and controlling the UPS should be a director/conductor, should order who have to shutdown and when. In case of programmable outlets it should also manage them considering who is connected to which port. Clients should just accept orders, ack them and report the start of the sequence. Is it wrong? Am I missing something? So you want the servers to keep running as long as possible and the clients should go down after a power outage of (say) five minutes? That's possible too. In my opinion that's a limitation and, again in my humble opinion, poor design. It sounds like refuelling a car on a $TIME schedule rather than an avaiability basis: I use to refuel when the *real* remaining fuel is below a certain value/charge, do you use to refuel on a *supposed* fuel consumption over $TIME? In a complex senario it can help much in both having easy configuration and successful shutdown sequence. At the moment my MGE UPS is powering on programmable outlets after some time, while it should consider battery charge (to be enought for another power outage). About NUT: no powershare support, no different shutdown based on battery charge. Many good ideas, nothing really useful to me till now. :( My 2 cents. Regards, Marco Chiappero ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] ordered shutdown
Citeren Marco Chiappero ma...@absence.it: I think I know what he meant, because my needs are similar. I already explained them some time ago, when I discovered that NUT comes with no features at all about programmable outlets (right now I still have no shutdown sequence settled yet). When you have one ups and many computers with different needs the low battery signal starts having no use (well, it can be useful but just for the last computers you want to shut down). If you want to conserve power on your UPS, you should simply send a client a command to shutdown. While it is shutting down, it makes no point to cut the power and after that, the remaining power it draws is so small, that cutting power is moot. You *will* need programmable outlets if you need to restart/reboot part of loads attached to a UPS. That comes in handy if you want to shutdown some servers earlier than others, to prevent that your only option is to power cycle *all* loads to make them start again if the power returns before the battery is empty. We're currently working on implementing this and already have made some progress in that direction (see the latest nut-2.4.0 release where a repeater mode was added) so you can have 'virtual' UPS devices. Basically what is lacking right now, is tying these virtual devices to UPS outlets and a way to configure the shutdown/restart levels for these outlets. We have some ideas on how to do that, but it is currently lacking development time to implement this. [...] In my opinion that's a limitation and, again in my humble opinion, poor design. It sounds like refuelling a car on a $TIME schedule rather than an avaiability basis: I use to refuel when the *real* remaining fuel is below a certain value/charge, do you use to refuel on a *supposed* fuel consumption over $TIME? This is actually how battery charge calculation works on a UPS, strange as it may seem. Most (if not all) batteries don't come with fuel gauges like your car, so all but the cheapest UPS systems will constantly keep track on how much charge is going in an out of the battery to calculate the charge in the battery. Having said that, you should *always* take into account that the battery capacity may be less than expected (calculated) due to aging batteries, so you can never fully rely on the reported battery.charge and battery.runtime. If you search the archives, you'll find plenty of examples where people found this out the hard way. This is one reason why one should periodically run battery tests to find hidden battery problems that only surface under load. Best regards, Arjen -- Please keep list traffic on the list ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] ordered shutdown
Arjen de Korte ha scritto: If you want to conserve power on your UPS, you should simply send a client a command to shutdown. How can I do that? How can I shutdown different systems at different battery charge levels (or expected runtime)? I thought the only option aviable was using upssched. You *will* need programmable outlets if you need to restart/reboot part of loads attached to a UPS. That comes in handy if you want to shutdown some servers earlier than others, to prevent that your only option is to power cycle *all* loads to make them start again if the power returns before the battery is empty. Right. We're currently working on implementing this and already have made some progress in that direction (see the latest nut-2.4.0 release where a repeater mode was added) so you can have 'virtual' UPS devices. Basically what is lacking right now, is tying these virtual devices to UPS outlets and a way to configure the shutdown/restart levels for these outlets. We have some ideas on how to do that, but it is currently lacking development time to implement this. Ok, thanks, I missed these news! Hoping for some other soon :) In my opinion that's a limitation and, again in my humble opinion, poor design. It sounds like refuelling a car on a $TIME schedule rather than an avaiability basis: I use to refuel when the *real* remaining fuel is below a certain value/charge, do you use to refuel on a *supposed* fuel consumption over $TIME? This is actually how battery charge calculation works on a UPS, strange as it may seem. Most (if not all) batteries don't come with fuel gauges like your car, so all but the cheapest UPS systems will constantly keep track on how much charge is going in an out of the battery to calculate the charge in the battery. I'm sorry, I didn't state explicitly I was talking about upssched. I prefer to choose when to shutdown the computers looking at the battery charge or the remaining runtime rather than after X time. In the same way I use to refuel looking at the remaining fuel or expected range rather than, let's say, once a week because I suppose it's necessary not to suddenly stop the car. This is what I was trying to say, referring to the scenario described above. Having said that, you should *always* take into account that the battery capacity may be less than expected (calculated) due to aging batteries, so you can never fully rely on the reported battery.charge and battery.runtime. If you search the archives, you'll find plenty of examples where people found this out the hard way. This is one reason why one should periodically run battery tests to find hidden battery problems that only surface under load. You are right, but this is another story. Some room is always needed above the method used (runtime, battery charge or time from outage). Thank you for your reply. Best regards, Marco Chiappero ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] ordered shutdown
If you want to conserve power on your UPS, you should simply send a client a command to shutdown. While it is shutting down, it makes no point to cut the power and after that, the remaining power it draws is so small, that cutting power is moot. Programmable outlets could have use in direction Off as well as On, as A lot of old computers do not obey halt -p, only halting, but not turning off. Modern ATX tend to obey Off more though. (BTW: Even my modern-ish laptop often fails to halt -p with power off, (some ACPI problem I guess - shrug - : it hangs, with fan going on off a lot, presumably in high power mode.) You *will* need programmable outlets if you need to restart/reboot part of loads attached to a UPS. ... Having said that, you should *always* take into account that the battery capacity may be less than expected (calculated) due to aging batteries, so you can never fully rely on the reported battery.charge and battery.runtime. If you search the archives, you'll find plenty of examples where people found this out the hard way. This is one reason why one should periodically run battery tests to find hidden battery problems that only surface under load. As batteries age, they might (or not) retain most of their Amp Hour capacity, but as their internal resistance increases, can't deliver same peak current load as a newer lower internal resistance battery. An on line battery test does not tell much, just a binary Worked/ Failed, (unless it tells more by comms port to NUT?) I would guess few (if any ?) UPS might have current measuring, for prediction ? None of the 5 or 6 UPS I have serviced have individual voltage sensors to individual batteries, so UPS Nut can only measure the whole stack, as some UPS use eg 4 x 12V 17AH @ 60 Euros, replacing all 4 when only some need it, is expensive. Off line, with disconnected batteries, a few car headlight bulbs in parallel can be used to calculate individual aggregate battery internal resistances, knowing that one can predict a UPS's reduced max load which could be much less than UPS manufacturers nominal max load with good new batteries. ( A few nice UPS allow one to slide out batteries disconnect for replacement /or test, while UPS remains running, albeit with no backup. ) Cheers, Julian -- Julian Stacey: BSDUnixLinux C Prog Admin SysEng Consult Munich www.berklix.com Mail plain ASCII text. HTML Base64 text are spam. www.asciiribbon.org ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] ordered shutdown
Citeren Marco Chiappero ma...@absence.it: If you want to conserve power on your UPS, you should simply send a client a command to shutdown. How can I do that? How can I shutdown different systems at different battery charge levels (or expected runtime)? I thought the only option aviable was using upssched. Well, that is the whole point now, at the moment there isn't. Switching off systems at various battery.charge/runtime levels is only useful, if you can also switch them on again. This is where the programmable outlets come into play. We first need to deal with that. Hopefully we will have something available by summer, but don't hold your breath. The number of active developers is quite limited at the moment and personally I feel that there are more important things to work on at the moment. [...] I'm sorry, I didn't state explicitly I was talking about upssched. I prefer to choose when to shutdown the computers looking at the battery charge or the remaining runtime rather than after X time. This is something you will rarely find on no-name consumer grade UPS, but as far as I know the more well known brands (MGE, APC, Tripplite) support this out of the box for their systems. Best regards, Arjen -- Please keep list traffic on the list ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] ordered shutdown
Citeren Julian Stacey j...@berklix.org: As batteries age, they might (or not) retain most of their Amp Hour capacity, but as their internal resistance increases, can't deliver same peak current load as a newer lower internal resistance battery. The internal resistance usually increases because of loss of active surface area in the cells (shedding lead from the plates and sulfatation) and (for VLRA cells) by drying out. All these effects not only cause higher resistance, but also lower the Amp hour rating. An on line battery test does not tell much, just a binary Worked/ Failed, (unless it tells more by comms port to NUT?) I would guess few (if any ?) UPS might have current measuring, for prediction ? None of the 5 or 6 UPS I have serviced have individual voltage sensors to individual batteries, so UPS Nut can only measure the whole stack, as some UPS use eg 4 x 12V 17AH @ 60 Euros, replacing all 4 when only some need it, is expensive. The only reliable way to determine this, is by running a (periodic) deep discharge test, either through a build in command or by pulling the plug. There is no need to remove batteries out to do this. Best regards, Arjen -- Please keep list traffic on the list ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] ordered shutdown
On Mon, Feb 09, 2009 at 04:23:54PM +0100, Arjen de Korte wrote: Well, that is the whole point now, at the moment there isn't. Switching off systems at various battery.charge/runtime levels is only useful, if you can also switch them on again. This is where the programmable outlets come into play. We first need to deal with that. Most server-grade boxes have IPMI support and that's _very_ convenient not just for turning the machine on/off. Also, we have good experiences with simple Wake-on-LAN for cheap boxes: it's not 100% reliable, but it is good enough to be useful (and if a machine does not have IPMI support then it cannot be that important ;-) IMHO nut is currently quite good at the low-level HW support but there is a real need to provide support for centralized, high-level power on/off plans. And centralized is a very important keyword here; having to modify upssched scripts on dozens of machines when the plan changes is a real PITA. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] ordered shutdown
Arjen de Korte ha scritto: Citeren Marco Chiappero ma...@absence.it: If you want to conserve power on your UPS, you should simply send a client a command to shutdown. How can I do that? How can I shutdown different systems at different battery charge levels (or expected runtime)? I thought the only option aviable was using upssched. Well, that is the whole point now, at the moment there isn't. So we can say it seems I understood how NUT works now. But then it is not the solution for us. as Lars stated, right? I think the scenario and requirements I described before are similar to (mine and) his ones. NUT is handy if you want to shut down one or many systems in the same moment but not in such case (upssched, is not even part of the core and does not fully fits these needs). Switching off systems at various battery.charge/runtime levels is only useful, if you can also switch them on again. Not really, there are many ways, such as IP PDUs, Wake-on-Lan, ecc... This is where the programmable outlets come into play. They are a comfortable and easy solution, but not the only one. We first need to deal with that. Hopefully we will have something available by summer, but don't hold your breath. The number of active developers is quite limited at the moment and personally I feel that there are more important things to work on at the moment. Ok, although in my opinion ordered shutdowns it's an important feature and discussing about design before implementation is a good thing. Just to be clear, there's no polemic intent in my words, I want to focus attention on some problems that I believe should be considered to make NUT powerful and customizable. I'm sorry, I didn't state explicitly I was talking about upssched. I prefer to choose when to shutdown the computers looking at the battery charge or the remaining runtime rather than after X time. This is something you will rarely find on no-name consumer grade UPS, but as far as I know the more well known brands (MGE, APC, Tripplite) support this out of the box for their systems. Sorry, what you mean? Not every UPS can shutdown whenever you want? Or not every UPS provide battery charge reading? Regards, Marco Chiappero ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] ordered shutdown
Gabor Gombas ha scritto: [...] And centralized is a very important keyword here; having to modify upssched scripts on dozens of machines when the plan changes is a real PITA. I agree, and that's the reason why I said there is a need for a director. It takes care about settings and actions, clients should only obey and possibly show UPS informations. It's also a metter of role: the system managing the UPS is the only one that should decide and control who can keep running and for how long, not the server administrator (and maybe you're not even the server owner or admin)! This should also make the powershare feature easier to implement since the computer controlling the UPS knows everything. Regards, Marco Chiappero ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] ordered shutdown
Lars, The win client includes several timers that can be used to simulate what you seek. There is a timer that can be set to cause the server to shut down after X minutes on battery. You can set this to the needed times giving you the sequencing you are looking for. The down side is the issue of mid shutdown recovery. On a large UPS system with the windows client you have to cycle power to the server to get it to reboot. Unless you have a way to switch off the output that the server is on, you will have to continue the shutdown of the entire system and then trigger a restart of the UPS unit OR require manual intervention. This is exactly the point I am facing in my system. At this point we are concerned with a clean shutdown and are willing to do a manual restart. I have about 50 ups units on campus and monitor them all with one NUT server. All of the windows clients then talk to that one master server to get the status to it's UPS unit. Mine is still a work in progress and has many things left to fix. Doug On Fri, Jan 30, 2009 at 7:32 AM, Lars Täuber taeu...@bbaw.de wrote: Hallo there. I'm new to this list and also to NUT. Our previous ups-system was APC based and apcupsd was serving the ordered shutdowns in our network. Our new ups is made by MGE and that's why we can't use apcupsd anymore. This led us into trouble. Our network system is quite complex and we need shutdown sequence levels. The servers depend on each other because of NFS and SQL connections and the like. We have one 60kVA UPS and more than 20 servers/routers/SANs supplied with energy by it. With apcupsd we could confiure the servers to shutdown on a specified battery level or the remaining time. Is there a way to do this with NUT anyhow? I thought about using the schedule mechanism with own bash scripts but this won't work on windows. In the docs is nothing written about such a feature. BTW, is there a feature request website for NUT somewhere? Thanks Lars ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] ordered shutdown
Citeren Gabor Gombas gomb...@sztaki.hu: Most server-grade boxes have IPMI support and that's _very_ convenient not just for turning the machine on/off. Also, we have good experiences with simple Wake-on-LAN for cheap boxes: it's not 100% reliable, but it is good enough to be useful (and if a machine does not have IPMI support then it cannot be that important ;-) With whatever strategy you use, you need to be able to send some kind of command (power on, WOL magic, whatever) at the right time. Shutting down is 'easy' when there is one point in time where you can decide to shutdown whatever is connected (what we have now) possibly with some kind of sequencing and then power cycle the UPS. What people are asking now, is to have multiple decision moments and for each one you must guarantee that you're able to return to the normal state with as little impact on other systems. This is something completely different. IMHO nut is currently quite good at the low-level HW support but there is a real need to provide support for centralized, high-level power on/off plans. And centralized is a very important keyword here; having to modify upssched scripts on dozens of machines when the plan changes is a real PITA. In that case, put these scripts on a network drive. They don't have to live in /etc/ups (or whatever is compiled in). In networked environments with lots of similar systems it is much more convenient to do this on a NFS share. Best regards, Arjen -- Please keep list traffic on the list ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] ordered shutdown
Citeren Marco Chiappero ma...@absence.it: NUT is handy if you want to shut down one or many systems in the same moment but not in such case (upssched, is not even part of the core and does not fully fits these needs). No, at the moment NUT only support if the decision to shutdown is made at the same time. This doesn't mean the systems have to be shutdown at the same time. Note there is a destinctive difference between these two. [...] This is something you will rarely find on no-name consumer grade UPS, but as far as I know the more well known brands (MGE, APC, Tripplite) support this out of the box for their systems. Sorry, what you mean? Not every UPS can shutdown whenever you want? Or not every UPS provide battery charge reading? Not every UPS allows you to change when it considers the battery voltage low and consequently, when you *must* shutdown your systems. Some no-name models will not even allow enough time to shutdown. Best regards, Arjen -- Please keep list traffic on the list ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] ordered shutdown
Citeren Marco Chiappero ma...@absence.it: And centralized is a very important keyword here; having to modify upssched scripts on dozens of machines when the plan changes is a real PITA. I agree, and that's the reason why I said there is a need for a director. It takes care about settings and actions, clients should only obey and possibly show UPS informations. It's also a metter of role: the system managing the UPS is the only one that should decide and control who can keep running and for how long, not the server administrator (and maybe you're not even the server owner or admin)! This should also make the powershare feature easier to implement since the computer controlling the UPS knows everything. Please elaborate here, because as far as I know we already have this (the 'upsd' server). What we're intending to do is to add additional 'upsd' servers (per outlet) that are configurable to some extend allow you to set additional shutdown parameters. But these additional servers would all be slaves to the server controlling the UPS, since by the time that one decides the UPS battery is empty, there is nothing to to but to shutdown. Best regards, Arjen -- Please keep list traffic on the list ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] ordered shutdown
On Mon, Feb 09, 2009 at 08:12:43PM +0100, Arjen de Korte wrote: With whatever strategy you use, you need to be able to send some kind of command (power on, WOL magic, whatever) at the right time. Shutting down is 'easy' when there is one point in time where you can decide to shutdown whatever is connected (what we have now) possibly with some kind of sequencing and then power cycle the UPS. What people are asking now, is to have multiple decision moments and for each one you must guarantee that you're able to return to the normal state with as little impact on other systems. This is something completely different. The first step would be to have a _central_ way to manage when to shut a specific class of clients down. Having to muck with upssched scripts on every client just does not scale. IMHO the clients should just say hello, I'm of class X when logging into the UPS, and it should be upsd's job to say clients of class X start to shut down NOW, everyone else wait. Being able to turn clients that were logged in to the UPS when their shutdown was ordered back on is the next logical step after the above, but for a start I'd be happy with the shutdown part. In that case, put these scripts on a network drive. They don't have to live in /etc/ups (or whatever is compiled in). In networked environments with lots of similar systems it is much more convenient to do this on a NFS share. I'm not really willing to allow NFS on every network where I do allow upsmon connections... Note: I'm not saying that it cannot be hacked together somehow. There are people who like the DIY approach and build their own computers, cars, houses etc. But most people would just want to get something that Just Works. Nut IMHO is now quite mature at low-level functionality, it would be really nice to build higher level functionality on top of that, and not require everyone to re-invent to wheel if they have more complex requirements. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] ordered shutdown
Hi there again, because nobody replied I decided to enhance apcupsd with the knowlegde of the snmp communication to our UPS. It works for me. I'm unsubscribing some time soon. Regards Lars Lars Täuber taeu...@bbaw.de schrieb: Hallo there. I'm new to this list and also to NUT. Our previous ups-system was APC based and apcupsd was serving the ordered shutdowns in our network. Our new ups is made by MGE and that's why we can't use apcupsd anymore. This led us into trouble. Our network system is quite complex and we need shutdown sequence levels. The servers depend on each other because of NFS and SQL connections and the like. We have one 60kVA UPS and more than 20 servers/routers/SANs supplied with energy by it. With apcupsd we could confiure the servers to shutdown on a specified battery level or the remaining time. Is there a way to do this with NUT anyhow? I thought about using the schedule mechanism with own bash scripts but this won't work on windows. In the docs is nothing written about such a feature. BTW, is there a feature request website for NUT somewhere? Thanks Lars ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser -- Informationstechnologie Berlin-Brandenburgische Akademie der Wissenschaften Jägerstrasse 22-23 10117 Berlin Tel.: +49 30 20370-352 http://www.bbaw.de ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] ordered shutdown
On Fri, Jan 30, 2009 at 7:32 AM, Lars Täuber taeu...@bbaw.de wrote: Our network system is quite complex and we need shutdown sequence levels. The servers depend on each other because of NFS and SQL connections and the like. There is a bit of sequencing in the master/slave protocol, but I have not had the time to set something up to try your particular situation. BTW, is there a feature request website for NUT somewhere? I guess this is too little, too late, but we use Alioth: http://alioth.debian.org/tracker/?atid=411545group_id=30602func=browse -- - Charles Lepple ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] ordered shutdown
Citeren Lars Täuber taeu...@bbaw.de: [...] The values of X and Y depend on how long the clients need for finishing their business with the SQL servers (X) and how long the SQL servers needs for doing their thing on the NFS servers (Y). This seems dangerous to me. Just think of the following situation: The ups has a normally 60 minutes of time left before shutdown after power loss. In this case I would use 40 mins for X and 5 mins for Y. The above values would be an extremely bad idea and this is also not how NUT works. See the FAQ. Lets assume a power outage of 38 min has happend before it power gets back. The servers still run and the shutdown sequences get canceled. The batteries now can bridge only 22 mins on a second outage. This would lead to an unexpected shutoff for those servers. The battery charge status has to get into account additionally to manage such situations. What you describe is not how NUT works. Until the UPS signals that the battery is low, it is business as usual (see the FAQ for the reasons behind this). Once the UPS signals battery low, all timers are started at the same time and there is no way to stop the following sequence of events. The systems *will* go down. If the power returns during the shutdown sequence, the shutdown sequence will be completed and NUT will power-cycle the UPS to make sure the connected systems are restarted. This means the value of X should only allow for enough time for your clients to disconnect (say about 5 minutes) and Y should only allow for enough time for your SQL servers to write their data to the NFS (maybe another 5 minutes). Typically, you should then allow for about 10 minutes runtime remaining before signaling low battery and starting the shutdown. The reason is that once the clients start shutting down, your runtime remaining will rapidly increase due to the lower load. If you feel uncomfortable with that, give it 15 minutes. There is one important thing here and that is that you need to be able to configure when the UPS signals low battery (and preferably also be able to prevent it from restarting below a certain threshold). This should allow for enough runtime remaining for an orderly shutdown of all systems. If you can also guarantee that the UPS will not power up again if the battery has not been recharged to that level, there is absolutely no risk and you will even ride through successive power failures without being harmed. Most (if not all) bigger UPSes will allow you to set what NUT calls 'battery.charge.low' and 'battery.charge.restart'. Some will even allow you to set 'battery.runtime.low' directly, which may make your life even easier since you no longer have to worry if the load on your UPS increases over time (it will automatically start the shutdown sequence sooner). Best regards, Arjen -- Please keep list traffic on the list ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] ordered shutdown
Citeren Charles Lepple clep...@gmail.com: Our network system is quite complex and we need shutdown sequence levels. The servers depend on each other because of NFS and SQL connections and the like. There is a bit of sequencing in the master/slave protocol, but I have not had the time to set something up to try your particular situation. Basically, this needs to be dealt with in the client application. Since we don't provide Windows clients (which Lars apparently is using), I have no idea if this is possible with those. Using the 'upsmon' client (but this requires some sort of *NIX system) this is a trivial however, by staging the FINALDELAY time we have in 'upsmon.conf'. Assuming there are clients connected to the SQL servers which in turn require NFS service you would use something like the following FINALDELAY 0 (for the clients) FINALDELAY X (for the SQL servers) FINALDELAY X+Y (for the NFS servers) The values of X and Y depend on how long the clients need for finishing their business with the SQL servers (X) and how long the SQL servers needs for doing their thing on the NFS servers (Y). You'll want a sufficient 'ups.delay.shutdown' period to make sure that all systems have not only started their shutdown sequences, but have also finished them before the power is actually cut. The use of FINALDELAY in the above only sequences the start of the shutdown, so it doesn't know when the systems are actually switched off. This is by design, since you don't want to stall shutting down if one system is unresponsive or takes longer to shutdown than expected (which would put all remaining systems at risk for a hard shutdown). Best regards, Arjen -- Please keep list traffic on the list ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
