Sponsored Content
Top Forums UNIX for Advanced & Expert Users Upgrading legacy packages with patch Post 303043773 by anaigini45 on Thursday 6th of February 2020 04:33:50 AM
Old 02-06-2020
All the servers are mission critical.
And in terms of risk management, we have an SLA of maximum 4 hours to bring the server back up in an event of a catastrophe.
 

9 More Discussions You Might Find Interesting

1. Programming

CMI Legacy

Is there anyone who still uses CMI to connect to the legacy system , my c applications do uses the binaries and libraries for using the CMI functionality but i do not have access to the original source code , and since this is a very old stuff , i just could not get any source to get to knwo the... (0 Replies)
Discussion started by: dino_leix
0 Replies

2. IP Networking

Patch-o-matic (patch for iptable) for linux2.4.08 & iptable1.2.7a

Hello friends I'm running Redhat 9.0 with linux kernel 2.4.20-8 & have iptables version 1.2.7a & encountering a problem that I narrate down. I need to apply patch to my iptable and netfilter for connection tracking and load balancing that are available in patch-o-matic distribution by netfilter.... (0 Replies)
Discussion started by: Rakesh Ranjan
0 Replies

3. Red Hat

upgrading packages

Hello, I am using Redhat Linux Enterprise 4 AS. To upgrade NFS, I had to browse the internet and finally I got the latest rpm https://rhn.redhat.com/errata/RHBA-2005-727.html That was a time-consuming procedure. On Solaris, I am used to go to sunfreeware.sun.com and download the latest... (3 Replies)
Discussion started by: melanie_pfefer
3 Replies

4. Programming

VERSYS Legacy System

I need help locating the tables that hold the demograhic data in this system on an AIX box. Does anyone know the path? (0 Replies)
Discussion started by: Chelcye
0 Replies

5. Slackware

Find Slackware Packages - packages.acl.org.ua

Hi! Let me introduce a project for find and download Slackware packages and browse Slackware repositories. The site provides following features: * Large, daily updated database with RPM, DEB, TGZ, TXZ packages for well-known repositories of the Slackware, Fedora, CentOS, RHEL, Debian,... (2 Replies)
Discussion started by: lystor
2 Replies

6. Solaris

Facing problem after upgrading the kernal patch level to 142900-12

I have a Solaris 10 OS having kernal patch level 138888-03 on several servers but recenlty I upgraded it into 142900-12 on some T-Series servers & v890 server after install them my syslog is increasing at a rate of 1GB on average on all servers . I believe its a bug, can somebody help me in... (1 Reply)
Discussion started by: sb200
1 Replies

7. What is on Your Mind?

Tron Legacy

Watched it. Major disappointment. (10 Replies)
Discussion started by: ni2
10 Replies

8. Ubuntu

Encountering problem on upgrading the packages

Hi folks, Ubuntu 9.04 I have an old box not running for years. I just dig it out from the store room. On running; $ sudo aptitude update ...... ...... Err http://hk.archive.ubuntu.com jaunty/main Packages 404 Not Found Err http://hk.archive.ubuntu.com jaunty/restricted Packages ... (1 Reply)
Discussion started by: satimis
1 Replies

9. Solaris

Determine if you are in a Legacy Zone?

Hi Folks, Just a quick question here, about Legacy Zones. Well more about how to determine if you are actually in one, on logging into a legacy zone - is there a quick way of checking that? Regards Gull04 (7 Replies)
Discussion started by: gull04
7 Replies
POWERD(8)						    BSD System Manager's Manual 						 POWERD(8)

NAME
powerd -- power management daemon for sysmon SYNOPSIS
powerd [-dn] DESCRIPTION
powerd acts upon power management events posted by the kernel's power management facility. When events are posted, powerd translates the event into a script name and a list of arguments. powerd then runs the script in order to implement the power management policy defined by the system administrator. powerd supports the following option: -d Enable debugging mode. Verbose messages and all messages intended for syslog(8) will be sent to stderr, and powerd will stay in the foreground of the controlling terminal. -n Prevent execution of power management scripts. CONFIGURATION SCRIPTS
All configuration of powerd is encapsulated into scripts that are run when power management events occur. The daemon will look for the scripts from the directory /etc/powerd/scripts. Configuration scripts are run synchronously; powerd will start the script and wait for its completion before it handles the next event. Configuration scripts are called with different arguments, depending on the script class. These classes are described in the following sec- tions. POWER SWITCH SCRIPTS Power switch scripts are called when a state change event occurs on a power switch device. Power switch scripts are called with two argu- ments: the device with which the event is associated, and the event type. The following power switch script names are defined: power_button This script is called when an event occurs on a power button device. reset_button This script is called when an event occurs on a reset button device. sleep_button This script is called when an event occurs on a sleep button device. lid_switch This script is called when an event occurs on a lid switch device. acadapter This script is called when an online or offline event occurs on an AC adapter device. hotkey_button This script is called when an event occurs on a hotkey button device. The following events are defined for power switch devices: pressed The button was pressed, the lid was closed, or the AC adapter was connected. released The button was released, the lid was opened, or the AC adapter was disconnected. Note that power and sleep button devices usually do not post this type of event. The following is an example of how a power button script might be invoked when a power button is pressed by the operator: /etc/powerd/scripts/power_button acpibut0 pressed ENVSYS SCRIPTS envsys(4) scripts are called when a condition was triggered in a sensor. These scripts are called with three arguments: the device associ- ated, the event type, and the sensor's name. The sensor_drive and the sensor_battery scripts uses a fourth argument: state description. The following envsys script names are defined: sensor_battery This script is called when an event occurs on a battery sensor (Wh/Ah/Battery state). sensor_drive This script is called when an event occurs on a drive sensor. sensor_fan This script is called when an event occurs on a fan sensor. sensor_indicator This script is called when an event ocurrs on a indicator/integer sensor. sensor_power This script is called when an event occurs on a power sensor (W/Ampere). sensor_resistance This script is called when an event occurs on a resistance sensor (Ohm). sensor_temperature This script is called when an event occurs on a temperature sensor. sensor_voltage This script is called when an event occurs on a voltage sensor. The following events are defined for fan, indicator, power, resistance, temperature, and voltage sensors: critical A critical condition was triggered. critical-under A critical under condition was triggered. critical-over A critical over condition was triggered. warning-under A warning under condition was triggered. warning-over A warning over condition was triggered. The following event is defined for all scripts, but it is only sent if any of the previous events has been previously sent: normal A normal state/capacity/condition was triggered. The following events are defined only for battery sensors: user-capacity Capacity dropped below the limit set by the user. low-power System is running in low power. This implies that the AC adapter is disconnected and all batteries are in critical or low capacity. The script shutdowns the system gracefully by default. The following events are defined for drive and battery sensors: state-changed The state of the sensor has been changed and it is not in the normal state. The following is an example of how a temperature sensor script might be invoked when a critical over condition is triggered: /etc/powerd/scripts/sensor_temperature lm0 critical-over "CPU Temp" SEE ALSO
acpi(4), acpiacad(4), acpibut(4), acpilid(4), envsys(4), i386/apm(4) HISTORY
powerd first appeared in NetBSD 2.0. Support to handle envsys(4) events appeared in NetBSD 5.0. AUTHORS
powerd was written by Jason R. Thorpe <thorpej@wasabisystems.com> and contributed by Wasabi Systems, Inc. Juan Romero Pardines added support to handle envsys(4) events. BUGS
Due to its synchronous nature powerd cannot be trusted to handle events within a certain time. BSD
December 15, 2010 BSD
All times are GMT -4. The time now is 01:12 AM.
Unix & Linux Forums Content Copyright 1993-2022. All Rights Reserved.
Privacy Policy