listen(7) [redhat man page]
LISTEN(7) SQL Commands LISTEN(7) NAME
LISTEN - listen for a notification SYNOPSIS
LISTEN name INPUTS name Name of notify condition. OUTPUTS LISTEN Message returned upon successful completion of registration. WARNING: Async_Listen: We are already listening on name If this backend is already registered for that notify condition. DESCRIPTION
LISTEN registers the current PostgreSQL backend as a listener on the notify condition name. Whenever the command NOTIFY name is invoked, either by this backend or another one connected to the same database, all the backends cur- rently listening on that notify condition are notified, and each will in turn notify its connected frontend application. See the discussion of NOTIFY for more information. A backend can be unregistered for a given notify condition with the UNLISTEN command. Also, a backend's listen registrations are automati- cally cleared when the backend process exits. The method a frontend application must use to detect notify events depends on which PostgreSQL application programming interface it uses. With the libpq library, the application issues LISTEN as an ordinary SQL command, and then must periodically call the routine PQnotifies to find out whether any notify events have been received. Other interfaces such as libpgtcl provide higher-level methods for handling notify events; indeed, with libpgtcl the application programmer should not even issue LISTEN or UNLISTEN directly. See the documentation for the library you are using for more details. NOTIFY [notify(7)] contains a more extensive discussion of the use of LISTEN and NOTIFY. NOTES name can be any string valid as a name; it need not correspond to the name of any actual table. If notifyname is enclosed in double-quotes, it need not even be a syntactically valid name, but can be any string up to 63 characters long. In some previous releases of PostgreSQL, name had to be enclosed in double-quotes when it did not correspond to any existing table name, even if syntactically valid as a name. That is no longer required. USAGE
Configure and execute a listen/notify sequence from psql: LISTEN virtual; NOTIFY virtual; Asynchronous NOTIFY 'virtual' from backend with pid '8448' received. COMPATIBILITY
SQL92 There is no LISTEN in SQL92. SQL - Language Statements 2002-11-22 LISTEN(7)
Check Out this Related Man Page
POWERD(8) System Manager's Manual POWERD(8) NAME
powerd - UPS monitoring daemon SYNOPSIS
/sbin/powerd [tty] DESCRIPTION
powerd monitors the serial port connected to an UPS device and will perform an unattended shutdown of the system if the UPS is on battery longer than a specified number of minutes. powerd needs to watch a tty with modem control properties. Please refer to the powerd documen- tation for further information. powerd also has the capabilities of notifying other clients on the network that may have a UPS but not be connected to the serial line that there is a power outage, and id configured through the powerd.conf file CONFIGURATION FILE
Here is the configuration format: Lines beginning with '#' are ignored. MODE <mode> specifies the mode the UPS should be in. Valid arguements are MONITOR and PEER MONITOR being the mode to actually watch a UPS serial port, and PEER being to listen for a connection from a machine in MONITOR mode MONITOR <device> Specifies which device to monitor while in MONITOR mode. Specify an actual device file. Example: /dev/ttyS0 POWERFAIL <line> <high|low> Specifies which lines on the serial ports indicate that the power is out. Valid arguements are DCD, CAR, CTS, and RNG. Also specify if the line being HIGH or LOW indicates a power failure. Since most people may not know this arguement, Please use the enclosed upsdetect program to automatically find this line. NOTIFY <hostname[:port]> <password> Specified in MONITOR mode to notify a client running in PEER mode. Specify the hostname of the machine, and optional port the daemon is running on, And the password as specified by their LISTEN command. See below for more details. LISTEN <hostname> <password> Specified in PEER mode, specifies a hostname that is allowed to notify us of when the power is out, and the password they shall give us to authenticate themselves. The 2 passwords should match on the MONITOR mode machines NOTIFY password, and the PEER modes LISTEN password. LISTENPORT <port> Specified in PEER mode, specifies the port that powerd should listen on. If you use this arguement, powerd shall not default to using port 532, and the machine in MONITOR mode must specify the port you use in their NOTIFY command. DELAY <delayinseconds> Specifies how many seconds before notifying init of a power outage. Note that this doesnt mean that the system will shut down in that many seconds, as it depends on how init is configured. Init usually issues a 2 min shutdown. USER <username> Specifies which username to drop to from root. The program will reobtain root access only when it needs to, Like when notifying init that the power is out. This is simply a security feature, and not needed for powerd to operate. Note: powerd must still be run ini- tially as root. It will then drop to the user if, and only if, a username is specified. ARGUMENTS
None: Please use the configuration file /etc/powerd.conf which can be generated with detectups. See detectups(8) for more information FILES
/etc/powerd.conf powerd configuration file /etc/powerstatus indicates line power status /etc/inittab init is what actually issues the shutdown SEE ALSO
powerd(8), shutdown(8), wall(1), init(8), inittab(5). AUTHOR
James Brents <James@nistix.com> (with parts of this man page borrowed from all over the Linux community) POWERD(8)