segmentation fault??

segmentation fault??

[behapy]

    after the first time my linux was down and may were broken file system(ext2), my linux doesn't work correctly.  and it is down often much more win95.
    during the kernel compile, the applications(xsplay which plays mp3 music files and xterm and netscape4.01) were running.  the error message occured "segmentation fault" after that the cpu usage was almost 100% by xosview.  the xsplay plaied music non-softly.  and my linux was down. no response.
    actually, this is not the only one time, not the only first time.  this appreas to me often.  and the lost+found are so many.  because of linux down, i ran e2fsck /dev/sdb2 or fsck.ext2 /dev/sdb2 so many times, may be of 20 times during 5days
    How could solve the problems?  I really don't want reinstall the Redhat 4.2.5..
    thank you very much who reads the hard-reading english and helps me.  have nice day 

Re: segmentation fault??

[L. C. Robinson]

Humm, most of the applications you mentioned are visual applications.
Why are you posting to the blinux list?  Are you blind or print
handicapped in some way?

Have you repaired the programs damaged?  There must be many if
you have such a full lost+found directory?  Do you know how to
find out what programs were affected, and replace them?

Do you know how to shut down properly?  Improper shutdowns will
lead to filesystem damage, and crashes can too.  If you are crashing,
you need to look for the cause.  Crashes are extremely rare on
a Linux system, unless you are running beta (alpha?) kernels, or
have flakey hardware, such as memory.  The bootup memory test
is nearly worthless.   More info about your system, both hardware
and software, would be helpful.  You should be able to routinely
run for weeks without a crash (programs can segfault, but they
cannot take the system down).

When you fsck the filesystem, are you doing it on a read-write mounted
filesystem?  This will lead to more damage, and should _never_ be
done.  What procedures do you use to fsck your filesystem?  Do
you know how to do it safely, and regularly?  See the tune2fs
man page to set this up properly, so that Red Hat will do it
automatically on bootup every few weeks.  Do NOT run tune2fs on
a mounted filesystem.

On Mon, 8 Jun 1998, behapy wrote:

>     after the first time my linux was down and may were broken file
>     system(ext2), my linux doesn't work correctly.  and it is down
>     often much more win95.  during the kernel compile, the
>     applications(xsplay which plays mp3 music files and xterm and
>     netscape4.01) were running.  the error message occured

>     "segmentation fault" after that the cpu usage was almost 100% by
>     xosview.  the xsplay plaied music no n-softly.  and my linux was
>     down. no response.  actually, this is not the only one time, not
>     the only first time.  this appreas to me often.  and the
>     lost+found are so many.  because of linux down, i ran e2fsck
>     /dev/sdb2 or fsck.ext2 /dev/sdb2 so many times, may be of 20
>     times during 5days How could solve the problems?  I really don't
>     want reinstall the Redhat 4.2.5..  thank you very much who reads
>     the hard-reading english and helps me.  have nice day 

-- 
L. C. Robinson
reply to infynity@cyberhighway.net (a family account)

Re: segmentation fault??

[John Covici]

on Mon, 8 Jun 1998 14:28:03 -0600 (MDT) "L. C. Robinson" <lcr@draken.localnet> in
<Pine.LNX.3.95.980608135705.20356A-100000@draken.localnet> wrote:
>When you fsck the filesystem, are you doing it on a read-write mounted
>filesystem?  This will lead to more damage, and should _never_ be
>done.  What procedures do you use to fsck your filesystem?  

This brings up an interesting point -- once I am logged in I cannot
get the root file system into readonly mode, I worked around things by
stopping all loggers and lpd, cron and a couple of other things, but
when ever I tried to get it into read only mode it said device or
resource busy.

I am still using screader, any way to work around this -- the boot
time checks are of course not available to me.

Any comments welcome on this -- luckily for me the fsck's have not
revealed any errors.


-- 
         John Covici
          covici@ccs.covici.com

Re: segmentation fault?? and fsck problems.

[L. C. Robinson]

Did you use the "-o remount,ro" option to "mount", to remount root?
Thus:
mount -n -o remount,ro /
(taken from the /etc/rc.d/init.d/halt script).
Note that after the remount, the mount command will not report
the read only status correctly; I check by trying to create a file
or remove a temporary one.

But this is a hard way to do things, and I never fsck the filesystems
this way, except under very unusual circumstances.  Fscking
automatically during bootup is the natural way to do it, if you
have set things properly for this.  Read the tune2fs man page
for info on how to make this happen every two weeks or so (time
set by you).

Now, I know you said that the boot time checks are not available
to you, but I don't see why.  The checks are initiated
automatically, and any problems found are repaired automatically,
so you probably don't need to see what is happening.  I am
sighted, so I suppose there might be some subtlety here, that
would get by me.  I can think of a way that this could be
automated by changing to, say, init state 9 (normally not used),
and modifying the "halt" and /etc/rc.d/rc.sysinit scripts to do
this for you, without completing a full shutdown, and then going
back to init state 3.  Another way to do it would be to add the
above quoted mount command to the /etc/rc.d/init.d/single script,
just before the last 3 lines, and then do the fsck manually,
after doing a "telinit 1", followed by a "telinit 3".  Red Hat's
single user scripts in the past have been broken though, for any
practical use that I know of, so I don't know what problems you
might run into, and if screader, etc, would work normally in that
limited environment.  It might be easier to modify the rc.sysinit
script to use screader during bootup, or to log the results of
the fsck for later inspection.

I wonder if Red Hat would be willing to make accessibility
modifications of this kind?  If anyone is interested in this,
feel free to forward this message to them.  If they (Red Hat) are
interested in including accessibility modifications in their
standard distribution, I'd be willing to try to modify things so
as to log the results of the fsck (probably to a floppy, since
other filesystems are not available for writing during a fsck),
and forward the modifications to them.  I already have hacked an
improved bootup package, based on Red Hat, that logs most other
stuff for daemon startup, and avoids the cryptic clutter on the
bootup screen (prominent warnings are given of any failures).
Blind users could activate this kind of thing by booting up in,
say, init state 8 or 9, which would be a modified version of
init 3 (the normal text state).


On Tue, 9 Jun 1998, John Covici wrote:

> on Mon, 8 Jun 1998 14:28:03 -0600 (MDT) "L. C. Robinson" <lcr@draken.localnet> in
> <Pine.LNX.3.95.980608135705.20356A-100000@draken.localnet> wrote:
> >When you fsck the filesystem, are you doing it on a read-write mounted
> >filesystem?  This will lead to more damage, and should _never_ be
> >done.  What procedures do you use to fsck your filesystem?  
> 
> This brings up an interesting point -- once I am logged in I cannot
> get the root file system into readonly mode, I worked around things by
> stopping all loggers and lpd, cron and a couple of other things, but
> when ever I tried to get it into read only mode it said device or
> resource busy.
> 
> I am still using screader, any way to work around this -- the boot
> time checks are of course not available to me.
> 
> Any comments welcome on this -- luckily for me the fsck's have not
> revealed any errors.

-- 
L. C. Robinson
reply to infynity@cyberhighway.net (a family account)

Re: segmentation fault?? and fsck problems.

[L. C. Robinson]

On Wed, 10 Jun 1998, John Covici wrote:

> on Tue, 9 Jun 1998 23:08:43 -0600 (MDT) "L. C. Robinson" <lcr@draken.localnet> in
> <Pine.LNX.3.95.980609184015.8522B-100000@draken.localnet> wrote:
> >Did you use the "-o remount,ro" option to "mount", to remount root?
> >Thus:
> >mount -n -o remount,ro /
> >(taken from the /etc/rc.d/init.d/halt script).
> 
> Yes, and when I do it it says device or resource busy and will not
> change state.

Humm, the halt script does this only after killing off all other
processes.  Filesystems cannot be umounted when they are in use.
The "fuser" utility can be used to help with this, but changing
to single user state is a more suitable way to do this sort of
thing, for the root filesystem.

> >But this is a hard way to do things, and I never fsck the
> >filesystems this way, except under very unusual circumstances.
> >Fscking automatically during bootup is the natural way to do
> >it, if you have set things properly for this.  Read the
> >tune2fs man page for info on how to make this happen every two
> >weeks or so (time set by you).
 
> It does happen, but I have no idea what is going on.  I did try
> to redirect the fsck output using a command something like fsck
> <options> 2>&1 |tee /dev/ttyS0 (which is where my synthesizer
> is), but it gave a status >2 and dropped me into a shell where
> the system was still in read only mode, and screader wouldn't
> run at all.

Did the fsck run prior to that, with output readable on ttyS0?
I found by experimenting that if you disable the -a flag (I do
this too) and try to redirect the output at the same time, so
as to run interactively, without automatic repairs, fsck refuses
to run, and delivers the following error statement:
"fsck.ext2: need terminal for interactive repairs",
and exits with a error code of 8, which causes rc.sysinit
to drop to a single user shell via sulogin.  If I leave the
-a option in, I can redirect the output to a file (and the
output is much less verbose) via:
exec > fsck-test-output-file
before the fsck statement.  Let me know if you want a copy of my
test script.  Note that the above exec statement remains in
effect till the end of the script, or until another exec
statement is encountered.  Maybe redirection of the whole
rc.sysinit script, as a unit, through the "exec" builtin would be
useful?

The drop to single user shell (sulogin) could be disabled, or you
could just type ^D when that happens, to continue on, as the
prompt directs (I guess you would have to do this without seeing
the prompt?).  But this won't happen if you make sure to use
the -a option to fsck, and if it does happen, it may just
mean you tried to redirect the interactive output, in which
case you have effectively made fsck inoperative (bad).

> I have modified the bootup scripts so that there are extra echo
> statements redirected to the synthesizer so I have some idea of
> what is happening.

But the echo statements only tell you whether the daemons tried
to start, not whether they succeeded.  My modifications to the
"functions" script change all that.

I wonder if the output of the whole boot script complex could
be changed with something like:

exec > /dev/ttyS0 2> /dev/ttyS0 < /dev/ttyS0

at the start of, say, the /etc/rc.d/rc script?
One might have to figure out how to set the protocol of
the serial port first, via stty, for this to work (gettys
normally do this).  I tried this once, when my monitor
went out, but had trouble with it.  How did you get your
echo statements to work?  The same procedure should make
the more comprehensive "exec" work.
 
> By closing down all the loggers, lpd, cron and a couple of
> other processes, I think I can do a safe fsck in read/write
> mode -- at least I tried it a couple of times and got no
> errors.

Sounds pretty risky to me.  If you can't remount it read only, it
means you missed some process still writing to the filesystem.
Killing off everything in root is almost impossible without an
automated init state change.  Probably safer to trust an
automated fsck, even if not seen.  Most users probably don't know
how to interpret any output from fsck anyway, and essentially
ignore it (little documentation is available).  The default Red
Hat boot check script recognizes this, by using the -a option, as
does the e2fsck program, which doesn't clutter your screen with
useless info when you run non-interactively.  You could check
/lost+found after bootup for any recovered files, and do better
than lots of people who CAN see.  Another trick would be to alter
the checks of the exit status of fsck in rc.sysinit, to message
you about success or failure, which is probably about all most
people understand or need anyway.

> I hope this explains my problem in a clearer way than I did
> before.

It's about what I would have guessed.  If I understand you right,
you object to not being able to "see" the fsck.  I would too.
This one is very sticky to get around.  Maybe someone needs to
email the maintainer of fsck with a request for an option or
environmental variable to cause fsck to redirect it's output when
in interactive mode, for accessibility purposes?  Something that
can be added to the line at the boot prompt would be preferable,
since it could be automated through LILO and loadlin.

Maybe redirection of the whole rc.sysinit script, as a unit,
through the "exec" builtin would be useful?

Please let me know how you solve this problem, what works,
since the info could be useful to me.  Come to think of it,
it would be useful to know what doesn't work, too.

-- 
L. C. Robinson
reply to infynity@cyberhighway.net (a family account)

People buy MicroShaft for compatibility, but get incompatibility and
instability instead: then they get to buy upgrades to fix it, and get
still more problems.  This is award winning "innovation".

Re: segmentation fault?? and fsck problems.

[Luke Davis]

I haven't followed this conversation very extencivly; but shouldn't it be
possible to redirect the entire console process, nomatter what, through
lilo's console redirect feature?
I'v heard of this feature, but have never managed to get it working.
As I said: I haven't followed this closely enough to know if this is what
is needed or not.

Re: segmentation fault?? and fsck problems.

[John Covici]

I did try that, but there is no way to set crtscts and I lost much
data over the serial interface doing it that way.

on Wed, 10 Jun 1998 15:22:42 -0400 (EDT) Luke Davis <ldavis@voicenet.com> in
<Pine.GSO.3.96.980610152110.14835C-100000@unix01> wrote:
>I haven't followed this conversation very extencivly; but shouldn't it be
>possible to redirect the entire console process, nomatter what, through
>lilo's console redirect feature?
>I'v heard of this feature, but have never managed to get it working.
>As I said: I haven't followed this closely enough to know if this is what
>is needed or not.


-- 
         John Covici
          covici@ccs.covici.com

Re: segmentation fault?? and fsck problems.

[John Covici]

on Wed, 10 Jun 1998 09:24:56 -0600 (MDT) "L. C. Robinson" <lcr@draken.localnet> in
<Pine.LNX.3.95.980610055249.26166C-100000@draken.localnet> wrote:
>On Wed, 10 Jun 1998, John Covici wrote:
>
>> on Tue, 9 Jun 1998 23:08:43 -0600 (MDT) "L. C. Robinson" <lcr@draken.localnet> in
>> <Pine.LNX.3.95.980609184015.8522B-100000@draken.localnet> wrote:
>> >Did you use the "-o remount,ro" option to "mount", to remount root?
>> >Thus:
>> >mount -n -o remount,ro /
>> >(taken from the /etc/rc.d/init.d/halt script).
>>
>> Yes, and when I do it it says device or resource busy and will not
>> change state.
>
>Humm, the halt script does this only after killing off all other
>processes.  Filesystems cannot be umounted when they are in use.
>The "fuser" utility can be used to help with this, but changing
>to single user state is a more suitable way to do this sort of
>thing, for the root filesystem.


I did try that, but many things didn't work as expected -- I suspect
the paths are somewhat different, but haven't had time to check.
>> >But this is a hard way to do things, and I never fsck the
>> >filesystems this way, except under very unusual circumstances.
>> >Fscking automatically during bootup is the natural way to do
>> >it, if you have set things properly for this.  Read the
>> >tune2fs man page for info on how to make this happen every two
>> >weeks or so (time set by you).
>
>> It does happen, but I have no idea what is going on.  I did try
>> to redirect the fsck output using a command something like fsck
>> <options> 2>&1 |tee /dev/ttyS0 (which is where my synthesizer
>> is), but it gave a status >2 and dropped me into a shell where
>> the system was still in read only mode, and screader wouldn't
>> run at all.
>
>Did the fsck run prior to that, with output readable on ttyS0?
>I found by experimenting that if you disable the -a flag (I do
>this too) and try to redirect the output at the same time, so
>as to run interactively, without automatic repairs, fsck refuses
>to run, and delivers the following error statement:
>"fsck.ext2: need terminal for interactive repairs",
>and exits with a error code of 8, which causes rc.sysinit
>to drop to a single user shell via sulogin.  If I leave the
>-a option in, I can redirect the output to a file (and the
>output is much less verbose) via:
>exec > fsck-test-output-file
>before the fsck statement.  Let me know if you want a copy of my
>test script.  Note that the above exec statement remains in
>effect till the end of the script, or until another exec
>statement is encountered.  Maybe redirection of the whole
>rc.sysinit script, as a unit, through the "exec" builtin would be
>useful?


Well, I think I still had the -a option in there and it still gave an
error, but I didn't have any assistance at the time, so I cannot
verify the error.

I didn't want to redirect the whole sysinit process because I had
already put in those echo statements and didn't want to confuse things
further.  Also, I want the screens to remain the same in case
something else goes wrong where I need sighted assistance.

>The drop to single user shell (sulogin) could be disabled, or you
>could just type ^D when that happens, to continue on, as the
>prompt directs (I guess you would have to do this without seeing
>the prompt?).  But this won't happen if you make sure to use
>the -a option to fsck, and if it does happen, it may just
>mean you tried to redirect the interactive output, in which
>case you have effectively made fsck inoperative (bad).

But what I really would like to do, if I get that shell I would like
to run screader or whatever I am using and find out what is happening.


>> I have modified the bootup scripts so that there are extra echo
>> statements redirected to the synthesizer so I have some idea of
>> what is happening.
>
>But the echo statements only tell you whether the daemons tried
>to start, not whether they succeeded.  My modifications to the
>"functions" script change all that.

Well, some of them do test return codes, but I'd like to see your mods
and maybe get some ideas from them.

>I wonder if the output of the whole boot script complex could
>be changed with something like:
>
>exec > /dev/ttyS0 2> /dev/ttyS0 < /dev/ttyS0
>
>at the start of, say, the /etc/rc.d/rc script?

I am not sure which of these programs need an interactive terminal --
maybe it would work and maybe not.

>One might have to figure out how to set the protocol of
>the serial port first, via stty, for this to work (gettys
>normally do this).  I tried this once, when my monitor
>went out, but had trouble with it.  How did you get your
>echo statements to work?  The same procedure should make
>the more comprehensive "exec" work.
>
>> By closing down all the loggers, lpd, cron and a couple of
>> other processes, I think I can do a safe fsck in read/write
>> mode -- at least I tried it a couple of times and got no
>> errors.
>
>Sounds pretty risky to me.  If you can't remount it read only, it
>means you missed some process still writing to the filesystem.

But maybe its only screader which has something open in read/write
mode and isn't doing any actual writing.


-- 
         John Covici
          covici@ccs.covici.com

Re: segmentation fault?? and fsck problems.

[L. C. Robinson]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 3344 bytes --]

On Wed, 10 Jun 1998, John Covici wrote:

> I didn't want to redirect the whole sysinit process because I had
> already put in those echo statements and didn't want to confuse things
> further.  Also, I want the screens to remain the same in case
> something else goes wrong where I need sighted assistance.

You probably just need to do:
fsck [options]   > /dev/ttyS0 
or something similar.  I tried doing:
exec > /dev/tty6 2> /dev/tty6 < /dev/tty6
fsck -fV /dev/hdc2
and it worked in interactive mode (hdc2 is a small experimental
partition I use).
fsck -fV /dev/hdc2 > /dev/tty6 2> /dev/tty6 < /dev/tty6
worked similarly.
If that doesn't work, there are other sneaky ways to save the
output in a buffer or coprocess for later logging or reading.

BTW, I have no difficulty remounting this partition read only,
unless there is a file open on it.  

> >The drop to single user shell (sulogin) could be disabled, or you
> >could just type ^D when that happens, to continue on, as the
> >prompt directs (I guess you would have to do this without seeing
> >the prompt?).  But this won't happen if you make sure to use
> >the -a option to fsck, and if it does happen, it may just
> >mean you tried to redirect the interactive output, in which
> >case you have effectively made fsck inoperative (bad).
> 
> But what I really would like to do, if I get that shell I would like
> to run screader or whatever I am using and find out what is happening.

I just checked the sulogin man page, and you are in luck!!  You
can add a tty device argument to sulogin, to redirect to your speech
device, or whatever, and you can even add a timeout, and control
what shell is used.
 
> >> I have modified the bootup scripts so that there are extra echo
> >> statements redirected to the synthesizer so I have some idea of
> >> what is happening.
> >
> >But the echo statements only tell you whether the daemons tried
> >to start, not whether they succeeded.  My modifications to the
> >"functions" script change all that.
> 
> Well, some of them do test return codes, but I'd like to see your mods
> and maybe get some ideas from them.

I will attach my functions script.  Be sure to read the commentary:
it tells you to add some lines to another script or two.

> >> By closing down all the loggers, lpd, cron and a couple of
> >> other processes, I think I can do a safe fsck in read/write
> >> mode -- at least I tried it a couple of times and got no
> >> errors.
> >
> >Sounds pretty risky to me.  If you can't remount it read only, it
> >means you missed some process still writing to the filesystem.
> 
> But maybe its only screader which has something open in read/write
> mode and isn't doing any actual writing.

I doubt it, but fuser can tell you for sure.  There are better ways,
though.  If you do this, eventually you will overlook something 
during a check, and damage your filesystem.  Then there is the
problem of getting all the daemons properly restarted.  That's
what single user mode is for (but it may be broken, as I
mentioned -- ie, you would need to customize it).
 
-- 
L. C. Robinson
reply to infynity@cyberhighway.net (a family account)

People buy MicroShaft for compatibility, but get incompatibility and
instability instead: then they get to buy upgrades to fix it, and get
still more problems.  This is award winning "innovation".


[-- Attachment #2: /etc/RC.D/init.d/functions --]
[-- Type: TEXT/PLAIN, Size: 5046 bytes --]

#! /bin/sh
#
# functions	This file contains functions to be used by most or all
#		shell scripts in the /etc/init.d directory.
#
# Version:	@(#) /etc/init.d/functions 1.01 26-Oct-1993
#
# Author:	Miquel van Smoorenburg, <miquels@drinkel.nl.mugnet.org>
# Hacked by:    Greg Galloway and Marc Ewing
#

# First set up a default search path.
export PATH="/sbin:/usr/sbin:/bin:/usr/bin"

# Customize for local use:
: set ${LOG_TTY:=/dev/tty12} to where you want messages sent -- should match syslog.conf
SKIP_AWK=true
# VERBOSE_BOOTUP=true       # uncomment to make bootup stuff echo to screen
DAEMON_LOG=/var/log/init_daemons  # set local3.info to go here in /etc/syslog.conf
: ${DAEMON_LOG:-/var/log/messages}  default set here if not set already
# Put the following at the end of /etc/RC.D/rc 
# ${VERBOSE_BOOTUP:-echo "Quiet bootup: see $DAEMON_LOG for deamon startup messages."}
FAILED_DAEMON_MSG="\nWARNING: some daemon(s) failed to start: see the log file!!\n" 

# Use ONLY for machines with no monitor (serial terminal control)
# SERIAL_CONSOLE=/dev/ttyS0

# set -x
MyTTY=`/usr/bin/tty`
case "$MyTTY" in
/dev/tty?|/dev/conso*|/dev/tty)
	# exec < $NEWTTY > $NEWTTY 2> $NEWTTY
	unset SERIAL_CONSOLE
	;;
not*) : ;;
/dev/ttyS?) SERIAL_CONSOLE=/dev/ttyS0 ;;
esac
set +x

# I note that 'logger' and 'basename' are in /usr/bin, and may not be available
# on a small root only filesystem...
# basename can be replaced with a (limited) shell function:
basename(){ builtin echo "${1##*/}" ; }

# A function to start a program.
daemon() {
	# Test syntax.
	if [ $# = 0 ]; then
		echo "Usage: daemon {program}"
		return 1
	fi

	# Save basename.
	base=`basename $1`

	# See if it's already running.
	[ "`pidofproc $base`" != "" ] && return

	# And start it up (with error logging):
	[ "${VERBOSE_BOOTUP}" ] || builtin echo -n .
	run_prog "$@"
}

run_prog(){
	base=`basename $1`
	"$@" ||
	if [ "`pidofproc $base`" = "" ] ; then
		shift
		VERBOSE_BOOTUP=error Logger "${ST_MSG:=Start of} $base $* *** FAILED ****" 
		touch /tmp/FAILED_DAEMON_MARKER
		return 1
	fi
	shift
	Logger "${ST_MSG:=Started} $base $*" 
}

echo(){
	# Converts messages of the form: echo -n "Starting XXX: " for the Logger function
	# or alternately: echo -n "Shutting down XXX services: "
	if [ "$#" = 0 -a "$ECHO" ]; then
		# for the terminating echo in converted statements
		# Do only if logger ran (ST_MSG is reset):
		[ "$ST_MSG" = ' ' ] && builtin echo
		unset ST_MSG ECHO LOG_MSG
	#elif [ "X${1}" = X-n -a \( "X${2#Shutting}" != "X$2" -o "X${2#Starting}" != "X$2" \) ]
	elif [ "X${1}" = X-n ] ; then
		case "$2" in
			Shutting*|Starting*|Stopping*)
				ST_MSG="$2" ECHO="builtin echo" # save it for "Logger" function
				;;
			# For normal echo statements:
			*) builtin echo "$@" ;;
		esac
	else
		# For normal echo statements:
		if [ "$SERIAL_CONSOLE" ] ; then
		  builtin echo "$@" > $SERIAL_CONSOLE
		else
			builtin echo "$@"
		fi
	fi
}

Logger(){
  declare LOGGER_TAG="-t daemon"
	if [ "$ECHO" -a "${VERBOSE_BOOTUP}" ]; then
		# For old message compatibility:
		builtin echo -n "$@"
		# unset	LOG_MSG
		logger -p local3.info $LOGGER_TAG "${LOG_MSG}$*"
		[ "$ST_MSG" = ' ' ] || LOG_MSG="$ST_MSG "
		ST_MSG=' '
	else
		# builtin echo actual mesg is: $*
		logger -p local3.info $LOGGER_TAG ${VERBOSE_BOOTUP:+-s} "$*"
		unset ST_MSG
	fi
	no_syslog_echo "$*"
}

no_syslog_echo(){
	# logging doesn't work until syslogd is running, so we do it "manually"
	[ -f /var/lock/subsys/syslog ] && return 0
	builtin echo "syslog off: $*" >> /var/log/init_daemons 
	builtin echo "syslog off: $*" >> ${LOG_TTY:=/dev/tty12}
	return 1
}

# A function to stop a program.
killproc() {
	# Test syntax.
	if [ $# = 0 ]; then
		echo "Usage: killproc {program}"
		return 1
	fi

	# Save basename.
	base=`basename $1`

	# Find pid.
	pid=`pidofproc $base`

	# Kill it.
	if [ "$pid" != "" ] ; then
		if kill -9 $pid
		then
			Logger "${ST_MSG:=Killed} $base" 
		else
			Logger "Kill of $base *** FAILED ****" 
		fi
	fi

	# Remove pid file if any.
	rm -f /var/run/$base.pid
}

# A function to find the pid of a program.
pidofproc() {
	# Test syntax.
	if [ $# = 0 ] ; then
		echo "Usage: pidofproc {program}"
		return 1
	fi

	# First try "pidof"
	type pidof > /dev/null 2>&1 && {
		pid=`pidof $1`
		if [ "$pid" != "" ] ; then
						builtin echo $pid
						return 0
		fi
	}

	# Next try "/var/run/*.pid" files
	type head > /dev/null 2>&1 &&
	if [ -f /var/run/$1.pid ] ; then
					pid=`head -1 /var/run/$1.pid`
					if [ "$pid" != "" ] ; then
									builtin echo $pid
									return 0
					fi
	fi

	# To speed things up:
	[ "$SKIP_AWK" ] && return

	type awk > /dev/null 2>&1 || return
	type ps > /dev/null 2>&1 || return
	# Finally try to extract it from ps
	ps auxw | awk 'BEGIN { prog=ARGV[1]; ARGC=1 } 
			   { if ((prog == $11) || (("(" prog ")") == $11) ||
			   ((prog ":") == $11)) { print $2 } }' $1
}

Re: segmentation fault?? and fsck problems.

[L. C. Robinson]

I thought you might have problems with this.  I wonder if it's
because you might need to set the protocol on the serial port to
match your terminal device setup.  The command to do this would
look something like this:
stty speed 19200 cs8 -parenb -cstopb < /dev/ttyS0
This would need to be adjusted for the protocol you are using, of
course.  You can make stty report the existing protocol by
running the stty command with no protocol options (but add '-a'
to force stty to report everything).  Note the odd direction of
the redirection operator '<': this is correct.

I suspect that the reason things work better with screader is
because you are logged in on a fully booted system, and before
you logged in, the getty set the protocols on the serial port
correctly.  Of course, gettys are not active till the boot
process is complete.  Screader is not responsible for setting the
port up, but it does offer lots of advantages in terms of
controlling the output, of course.  Has anyone found a way to
get speech software like screader, working on a system that is not
yet fully operational (during the boot process)?

This problem with not having access to the speech resources of
the machine before it is fully booted (which I believe is the way
things should be), is the reason why I think that the right way
to handle the boot message problem for blind users, is to log
everything possible, and allow the user to look at the log files
after the boot is complete (this could be automated).  Extra help
should be added where possible, in case things go wrong, by
playing wav files, beeping, and the like, to give cues during the
boot.  This discussion has helped me to get a better idea where
to add such things to a modified "initscripts" package which I
have been working on.  I am, of course, interested in the ideas
of others, especially since I am not blind, and do not have any
speech hardware, and so have difficulty testing many aspects of
the concept.

On Thu, 11 Jun 1998, John Covici wrote:

> on Thu, 11 Jun 1998 00:31:26 -0600 (MDT) "L. C. Robinson" <lcr@draken.localnet> in
> <Pine.LNX.3.95.980610180759.30808A-200000@draken.localnet> wrote:
> >On Wed, 10 Jun 1998, John Covici wrote:
> >
> >> I didn't want to redirect the whole sysinit process because I had
> >> already put in those echo statements and didn't want to confuse things
> >> further.  Also, I want the screens to remain the same in case
> >> something else goes wrong where I need sighted assistance.
> >
> >You probably just need to do:
> >fsck [options]   > /dev/ttyS0
> >or something similar.  I tried doing:
> >exec > /dev/tty6 2> /dev/tty6 < /dev/tty6
> >fsck -fV /dev/hdc2
> >and it worked in interactive mode (hdc2 is a small experimental
> >partition I use).
> 
> I wonder if that is because its a tty and not a serial port -- I have
> had some other problems with programs redirecting their output to the
> serial port -- I can't remember which programs they were, but I know I
> had problems with that approach -- that is why I want to run a program
> like screader and use that instead.
> 
> >fsck -fV /dev/hdc2 > /dev/tty6 2> /dev/tty6 < /dev/tty6
> >worked similarly.
 

-- 
L. C. Robinson
reply to infynity@cyberhighway.net (a family account)

People buy MicroShaft for compatibility, but get incompatibility and
instability instead: then they get to buy upgrades to fix it, and get
still more problems.  This is award winning "innovation".

Re: segmentation fault?? and fsck problems.

[John Covici]

The problem is you can't issue those commands till its too late -- the
serial console feature is special code in console.c and there is no
place to specify the tty parameters.  All you do is at the lilo prompt
say console=/dev/tty0 console=/dev/ttyS0 -- you can specify parity,
data bits, but not flow control.
on Thu, 11 Jun 1998 11:31:40 -0600 (MDT) "L. C. Robinson" <lcr@draken.localnet> in
<Pine.LNX.3.95.980611101846.4928B-100000@draken.localnet> wrote:
>I thought you might have problems with this.  I wonder if it's
>because you might need to set the protocol on the serial port to
>match your terminal device setup.  The command to do this would
>look something like this:
>stty speed 19200 cs8 -parenb -cstopb < /dev/ttyS0
>This would need to be adjusted for the protocol you are using, of
>course.  You can make stty report the existing protocol by
>running the stty command with no protocol options (but add '-a'
>to force stty to report everything).  Note the odd direction of
>the redirection operator '<': this is correct.
>
>I suspect that the reason things work better with screader is
>because you are logged in on a fully booted system, and before
>you logged in, the getty set the protocols on the serial port
>correctly.  Of course, gettys are not active till the boot
>process is complete.  Screader is not responsible for setting the
>port up, but it does offer lots of advantages in terms of
>controlling the output, of course.  Has anyone found a way to
>get speech software like screader, working on a system that is not
>yet fully operational (during the boot process)?
>
>This problem with not having access to the speech resources of
>the machine before it is fully booted (which I believe is the way
>things should be), is the reason why I think that the right way
>to handle the boot message problem for blind users, is to log
>everything possible, and allow the user to look at the log files
>after the boot is complete (this could be automated).  Extra help
>should be added where possible, in case things go wrong, by
>playing wav files, beeping, and the like, to give cues during the
>boot.  This discussion has helped me to get a better idea where
>to add such things to a modified "initscripts" package which I
>have been working on.  I am, of course, interested in the ideas
>of others, especially since I am not blind, and do not have any
>speech hardware, and so have difficulty testing many aspects of
>the concept.
>
>On Thu, 11 Jun 1998, John Covici wrote:
>
>> on Thu, 11 Jun 1998 00:31:26 -0600 (MDT) "L. C. Robinson" <lcr@draken.localnet> in
>> <Pine.LNX.3.95.980610180759.30808A-200000@draken.localnet> wrote:
>> >On Wed, 10 Jun 1998, John Covici wrote:
>> >
>> >> I didn't want to redirect the whole sysinit process because I had
>> >> already put in those echo statements and didn't want to confuse things
>> >> further.  Also, I want the screens to remain the same in case
>> >> something else goes wrong where I need sighted assistance.
>> >
>> >You probably just need to do:
>> >fsck [options]   > /dev/ttyS0
>> >or something similar.  I tried doing:
>> >exec > /dev/tty6 2> /dev/tty6 < /dev/tty6
>> >fsck -fV /dev/hdc2
>> >and it worked in interactive mode (hdc2 is a small experimental
>> >partition I use).
>>
>> I wonder if that is because its a tty and not a serial port -- I have
>> had some other problems with programs redirecting their output to the
>> serial port -- I can't remember which programs they were, but I know I
>> had problems with that approach -- that is why I want to run a program
>> like screader and use that instead.
>>
>> >fsck -fV /dev/hdc2 > /dev/tty6 2> /dev/tty6 < /dev/tty6
>> >worked similarly.
>
>
>--
>L. C. Robinson
>reply to infynity@cyberhighway.net (a family account)
>
>People buy MicroShaft for compatibility, but get incompatibility and
>instability instead: then they get to buy upgrades to fix it, and get
>still more problems.  This is award winning "innovation".
>
>
>---
>Send your message for blinux-list to blinux-list@redhat.com
>Blinux software archive at ftp://leb.net/pub/blinux
>Blinux web page at http://leb.net/blinux
>To unsubscribe send mail to blinux-list-request@redhat.com
>with subject line: unsubscribe


-- 
         John Covici
          covici@ccs.covici.com

Re: segmentation fault?? and fsck problems.

[L. C. Robinson]

But you can add a stty command to fix the flow control problem,
etc., to, say, the beginning of /etc/rc.d/rc, so that you could
redirect the output of any of the scripts run in that hierarchy,
and get at least part of what you need.

The bootup info put out by the kernel can be recovered after boot
is complete by running dmesg (and are logged in /var/log/dmesg).
I have heard that the situation is improved for the 2.1 kernels,
and there is a code freeze on there, so we should see a gamma 2.2
kernel soon.  Maybe that will help with some types of speech
hardware, but not for those who need the cheaper software only
(with sound card) solutions (like me).

On Fri, 12 Jun 1998, John Covici wrote:

> The problem is you can't issue those commands till its too late
> -- the serial console feature is special code in console.c and
> there is no place to specify the tty parameters.  All you do is
> at the lilo prompt say console=/dev/tty0 console=/dev/ttyS0 --
> you can specify parity, data bits, but not flow control.

> on Thu, 11 Jun 1998 11:31:40 -0600 (MDT) "L. C. Robinson" wrote:

> >I thought you might have problems with this.  I wonder if it's
> >because you might need to set the protocol on the serial port to
> >match your terminal device setup.  The command to do this would
> >look something like this:
> >stty speed 19200 cs8 -parenb -cstopb < /dev/ttyS0
> >This would need to be adjusted for the protocol you are using, of
> >course.  You can make stty report the existing protocol by
> >running the stty command with no protocol options (but add '-a'
> >to force stty to report everything).  Note the odd direction of
> >the redirection operator '<': this is correct.
> >
> >I suspect that the reason things work better with screader is
> >because you are logged in on a fully booted system, and before
> >you logged in, the getty set the protocols on the serial port
> >correctly.  Of course, gettys are not active till the boot
> >process is complete.  Screader is not responsible for setting the
> >port up, but it does offer lots of advantages in terms of
> >controlling the output, of course.  Has anyone found a way to
> >get speech software like screader, working on a system that is not
> >yet fully operational (during the boot process)?
> >
> >This problem with not having access to the speech resources of
> >the machine before it is fully booted (which I believe is the way
> >things should be), is the reason why I think that the right way
> >to handle the boot message problem for blind users, is to log
> >everything possible, and allow the user to look at the log files
> >after the boot is complete (this could be automated).  Extra help
> >should be added where possible, in case things go wrong, by
> >playing wav files, beeping, and the like, to give cues during the
> >boot.  This discussion has helped me to get a better idea where
> >to add such things to a modified "initscripts" package which I
> >have been working on.  I am, of course, interested in the ideas
> >of others, especially since I am not blind, and do not have any
> >speech hardware, and so have difficulty testing many aspects of
> >the concept.
> >
> >On Thu, 11 Jun 1998, John Covici wrote:
> >
> >> on Thu, 11 Jun 1998 00:31:26 -0600 (MDT) "L. C. Robinson" <lcr@draken.localnet> in
> >> <Pine.LNX.3.95.980610180759.30808A-200000@draken.localnet> wrote:
> >> >On Wed, 10 Jun 1998, John Covici wrote:
> >> >
> >> >> I didn't want to redirect the whole sysinit process because I had
> >> >> already put in those echo statements and didn't want to confuse things
> >> >> further.  Also, I want the screens to remain the same in case
> >> >> something else goes wrong where I need sighted assistance.
> >> >
> >> >You probably just need to do:
> >> >fsck [options]   > /dev/ttyS0
> >> >or something similar.  I tried doing:
> >> >exec > /dev/tty6 2> /dev/tty6 < /dev/tty6
> >> >fsck -fV /dev/hdc2
> >> >and it worked in interactive mode (hdc2 is a small experimental
> >> >partition I use).
> >>
> >> I wonder if that is because its a tty and not a serial port -- I have
> >> had some other problems with programs redirecting their output to the
> >> serial port -- I can't remember which programs they were, but I know I
> >> had problems with that approach -- that is why I want to run a program
> >> like screader and use that instead.
> >>
> >> >fsck -fV /dev/hdc2 > /dev/tty6 2> /dev/tty6 < /dev/tty6
> >> >worked similarly.
> >
> >
> >--
> >L. C. Robinson
> >reply to infynity@cyberhighway.net (a family account)
> >
> >People buy MicroShaft for compatibility, but get incompatibility and
> >instability instead: then they get to buy upgrades to fix it, and get
> >still more problems.  This is award winning "innovation".
> >
> >
> >---
> >Send your message for blinux-list to blinux-list@redhat.com
> >Blinux software archive at ftp://leb.net/pub/blinux
> >Blinux web page at http://leb.net/blinux
> >To unsubscribe send mail to blinux-list-request@redhat.com
> >with subject line: unsubscribe
> 
> 
> -- 
>          John Covici
>           covici@ccs.covici.com
> 
> ---
> Send your message for blinux-list to blinux-list@redhat.com
> Blinux software archive at ftp://leb.net/pub/blinux
> Blinux web page at http://leb.net/blinux
> To unsubscribe send mail to blinux-list-request@redhat.com
> with subject line: unsubscribe
> 
> 

-- 
L. C. Robinson
reply to infynity@cyberhighway.net (a family account)

People buy MicroShaft for compatibility, but get incompatibility and
instability instead: then they get to buy upgrades to fix it, and get
still more problems.  This is award winning "innovation".