From owner-freebsd-hackers Sun Sep 12 19:17:23 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from gndrsh.dnsmgr.net (GndRsh.dnsmgr.net [198.145.92.4]) by hub.freebsd.org (Postfix) with ESMTP id 82A8814C7F for ; Sun, 12 Sep 1999 19:17:18 -0700 (PDT) (envelope-from freebsd@gndrsh.dnsmgr.net) Received: (from freebsd@localhost) by gndrsh.dnsmgr.net (8.9.3/8.9.3) id TAA31971; Sun, 12 Sep 1999 19:17:06 -0700 (PDT) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <199909130217.TAA31971@gndrsh.dnsmgr.net> Subject: Re: How to prevent motd including os info In-Reply-To: <37DC52D3.D69781D3@gorean.org> from Doug at "Sep 12, 1999 06:26:43 pm" To: Doug@gorean.org (Doug) Date: Sun, 12 Sep 1999 19:17:05 -0700 (PDT) Cc: des@flood.ping.uio.no (Dag-Erling Smorgrav), hackers@freebsd.org X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > "Rodney W. Grimes" wrote: > > > > > [moving to -hackers] > > [I'm going to loose the rest of this thread since I am not on hackers :-(] > > Shame on you. :) The volume of mail became too high for my time a long while ago. :-( > > > "Rodney W. Grimes" writes: > > > Actually I would like _all_ the output from /etc/rc* to be avaliable > > after boot. > > One of the things discussed on -hackers recently is my rc* (et al) cleanup > effort. You can see the results at http://gorean.org/rcfiles/. If I can get > the current set of patches committed the next step in my proposal is to > change as many of the 'echo' statements as humanly possible to use 'logger' > instead. This is somewhat controversial because it will (for some items) > require moving 'logger' to /bin, but I think it's worth it. I don't like that idea, don't get me wrong, it's not the moving of logger to /bin that bothers me, it just seems like this is using the splitting mall for what a ballpean hammer could do. It dawned on me what can be done. Look, we get all the kernel printf's from the dmesg output saved in a buffer and pull that out later with syslog, looks like we could just slip a pipe fitting into /dev/console that copies all it's output into the mesgbuf as well, until we smack it wth the ballpean and tell it to stop doing that (Either getty lanching the login: on ttyv0 could cause this, or something at the end of /etc/rc). What do you think of that idea? I think this is what HPUX does, as I do know I can get the complete console output from a boot on it. > > > This would be a big win for remote admining and trying > > to figure out what went wrong during the last boot without having to > > drive down and hook up a console of some form. I know we could hang > > serial consoles on all of them, but why spend money on hardware when > > the problem can be solved with software :-). > > I agree, both that it would be a huge benefit for remote admins (I'm one > too) and that there are some problems that a serial console doesn't solve > where having a hard copy is your best bet (such as jr. asst. cow orker > rebooted a machine he should not have, and now it's borked and no one knows > why). Been there, fixed that, and Jr's now missing his left pointer finger so he only types ``eoo'' when he tries a reboot :-) :-) > > > > fsck_output="$(/sbin/fsck -p)" > > > /sbin/mount -at nonfs > > > echo "${fsck_output}" >/var/run/fsck.boot > > > > > > but then you wouldn't be able to see the output while it runs. The > > > only solution I can think of is the following: > > > > > > fsck_output="$(/sbin/fsck -p | /bin/tee /dev/console)" > > > /sbin/mount -at nonfs > > > echo "${fsck_output}" >/var/run/fsck.boot > > > > > > but I don't expect people to be happy about moving tee(1) from > > > /usr/bin to /bin. > > Another possible solution to this would be giving fsck a flag to > copy it's > output to a file, STDOUT, or what have you. Since the rest of the cases > could be handled with 'logger' and/or redirction we wouldn't have to bring > 'tee' into /bin. Adding a flag to fsck to duplicate it's output is even worse than bringing tee(1) to bin, it's putting tee(1) inside fsck(8) :-(. -- Rod Grimes - KD7CAX - (RWG25) rgrimes@gndrsh.dnsmgr.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message