Date: Sun, 12 Sep 1999 19:17:05 -0700 (PDT) From: "Rodney W. Grimes" <freebsd@gndrsh.dnsmgr.net> To: Doug@gorean.org (Doug) Cc: des@flood.ping.uio.no (Dag-Erling Smorgrav), hackers@freebsd.org Subject: Re: How to prevent motd including os info Message-ID: <199909130217.TAA31971@gndrsh.dnsmgr.net> In-Reply-To: <37DC52D3.D69781D3@gorean.org> from Doug at "Sep 12, 1999 06:26:43 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
> "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" <freebsd@gndrsh.dnsmgr.net> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199909130217.TAA31971>