From owner-freebsd-stable@FreeBSD.ORG Fri Nov 25 13:17:59 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 069A616A41F for ; Fri, 25 Nov 2005 13:17:59 +0000 (GMT) (envelope-from hk@alogis.com) Received: from alogis.com (firewall.solit-ag.de [212.184.102.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3180043D81 for ; Fri, 25 Nov 2005 13:17:52 +0000 (GMT) (envelope-from hk@alogis.com) Received: from alogis.com (localhost [127.0.0.1]) by alogis.com (8.13.1/8.13.1) with ESMTP id jAPDHgmN072211; Fri, 25 Nov 2005 14:17:42 +0100 (CET) (envelope-from hk@alogis.com) Received: (from hk@localhost) by alogis.com (8.13.1/8.13.1/Submit) id jAPDHgvo072210; Fri, 25 Nov 2005 14:17:42 +0100 (CET) (envelope-from hk) Date: Fri, 25 Nov 2005 14:17:42 +0100 From: Holger Kipp To: Sascha Holzleiter Message-ID: <20051125131742.GB71513@intserv.int1.b.intern> References: <20051123033644.O1053@ganymede.hub.org> <4385FFED.3050003@crc.u-strasbg.fr> <20051124181507.GA3012@serverbitch.de> <20051124183412.GA50476@intserv.int1.b.intern> <20051124230726.G63444@ns1.as.pvp.se> <20051125101047.GA11963@serverbitch.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051125101047.GA11963@serverbitch.de> User-Agent: Mutt/1.4.2.1i Cc: freebsd-stable@freebsd.org Subject: Re: ciss(4) driver in FreeBSD 6.x ... X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Nov 2005 13:17:59 -0000 On Fri, Nov 25, 2005 at 11:10:47AM +0100, Sascha Holzleiter wrote: > Hi, > > thanks for the input on this. > > On Thu, Nov 24, 2005 at 11:08:28PM +0100, kama wrote: > > > > do you know of any method to monitor these [ciss] controllers with FreeBSD, > > > > e.g. to detect drive failures? > > > > > > You could simply monitor the corresponding ciss syslog-messages > > > and scan for state changes (ie from OK to something else). Apart > > > from reboot-messages, you only get messages if states are > > > changing... > > This is what is done already but I always wanted to watch the drives > directly. The camcontrol approach seems to satisfy this. Well, that requires active testing every few minutes. You could instead make an appropriate entry in syslog.conf to pipe ciss-related entries into a program of your choice, so you get instant feedback ;-) Regards, Holger Kipp see man syslog.conf, action field description: --- o A vertical bar (``|''), followed by a command to pipe the selected messages to. The command is passed to sh(1) for evaluation, so usual shell metacharacters or input/output redirection can occur. (Note however that redirecting stdio(3) buffered output from the invoked command can cause additional delays, or even lost output data in case a logging subprocess exited with a signal.) The command itself runs with stdout and stderr redirected to /dev/null. Upon receipt of a SIGHUP, syslogd(8) will close the pipe to the process. If the process did not exit voluntarily, it will be sent a SIGTERM signal after a grace period of up to 60 seconds. The command will only be started once data arrives that should be piped to it. If it exited later, it will be restarted as necessary. So if it is desired that the subprocess should get exactly one line of input only (which can be very resource-consuming if there are a lot of messages flowing quickly), this can be achieved by exiting after just one line of input. If necessary, a script wrapper can be written to this effect. Unless the command is a full pipeline, it is probably useful to start the command with exec so that the invoking shell process does not wait for the command to complete. Warning: the process is started under the UID invoking syslogd(8), normally the superuser. ---