On 09/03/2008 05:47 AM, UKnicks sent:
> ALL:
>
> We use a build and customization (B&C) process (a bunch of
> scripts) to rebuild boxes after we've installed RHEL5. I believe, not
> completely sure, some kernel changes are made. Problem is after we
> run our B&C and try to issue a set -o vi command it causes a
> segmentation fault and a core dump.
>
> [ I just tried this myself.. I logged onto a remote box... issued a
> set -o vi command and nothing happened. The next command I typed,
> "ls", caused the box to kick me out. I returned to the same directory
> and found a core file]
>
>
> Testers have reported this doesn't occur before the B&C process. Any
> ideas?
>
> I apologize if I've left out any pertinent information. I'll try to
> repost it as soon as requested.
>
> Thanx

Are the systems in question _completely_ updated to RHEL 5.2 before the
failure occurs?

What shell is in use at the instant of failure? ($ echo $0)

A rather short search of Red Hat's Bugzilla hasn't yet found anything
close to this. However, that doesn't mean I looked in all the right
places.

Since more than one script is involved, can this be isolated to a
particular script? Have the scripts been vetted in previous installations?

Others will probably ask more pointed questions.

This is certainly why you're paying Red Hat for support.

--
1PW

@?6A62?FEH9E=6o2@=]4@> [r4o7t]

On Sep 3, 1:34 pm, 1PW wrote:
> On 09/03/2008 05:47 AM, UKnicks sent:
>
>
>
> > ALL:
>
> > We use a build and customization (B&C) process (a bunch of
> > scripts) to rebuild boxes after we've installed RHEL5. I believe, not
> > completely sure, some kernel changes are made. Problem is after we
> > run our B&C and try to issue a set -o vi command it causes a
> > segmentation fault and a core dump.
>
> > [ I just tried this myself.. I logged onto a remote box... issued a
> > set -o vi command and nothing happened. The next command I typed,
> > "ls", caused the box to kick me out. I returned to the same directory
> > and found a core file]
>
> > Testers have reported this doesn't occur before the B&C process. Any
> > ideas?
>
> > I apologize if I've left out any pertinent information. I'll try to
> > repost it as soon as requested.
>
> > Thanx
>
> Are the systems in question _completely_ updated to RHEL 5.2 before the
> failure occurs?
>
> What shell is in use at the instant of failure? ($ echo $0)
>
> A rather short search of Red Hat's Bugzilla hasn't yet found anything
> close to this. However, that doesn't mean I looked in all the right
> places.
>
> Since more than one script is involved, can this be isolated to a
> particular script? Have the scripts been vetted in previous installations?
>
> Others will probably ask more pointed questions.
>
> This is certainly why you're paying Red Hat for support.

>
> --
> 1PW
>
> @?6A62?FEH9E=6o2@=]4@> [r4o7t]


Yes the systems are completely upgraded before this error occurs.

Shell in use when this happens is KSH.

I'll type set -o vi. NOthing happens..However , No matter what I type
following this causes segmentation fault.

On 09/03/2008 11:23 AM, UKnicks sent:
> On Sep 3, 1:34 pm, 1PW wrote:
>> On 09/03/2008 05:47 AM, UKnicks sent:
>>
>>
>>
>>> ALL:
>>> We use a build and customization (B&C) process (a bunch of
>>> scripts) to rebuild boxes after we've installed RHEL5. I believe, not
>>> completely sure, some kernel changes are made. Problem is after we
>>> run our B&C and try to issue a set -o vi command it causes a
>>> segmentation fault and a core dump.
>>> [ I just tried this myself.. I logged onto a remote box... issued a
>>> set -o vi command and nothing happened. The next command I typed,
>>> "ls", caused the box to kick me out. I returned to the same directory
>>> and found a core file]
>>> Testers have reported this doesn't occur before the B&C process. Any
>>> ideas?
>>> I apologize if I've left out any pertinent information. I'll try to
>>> repost it as soon as requested.
>>> Thanx
>> Are the systems in question _completely_ updated to RHEL 5.2 before the
>> failure occurs?
>>
>> What shell is in use at the instant of failure? ($ echo $0)
>>
>> A rather short search of Red Hat's Bugzilla hasn't yet found anything
>> close to this. However, that doesn't mean I looked in all the right
>> places.
>>
>> Since more than one script is involved, can this be isolated to a
>> particular script? Have the scripts been vetted in previous installations?
>>
>> Others will probably ask more pointed questions.
>>
>> This is certainly why you're paying Red Hat for support.
>
>> --
>> 1PW
>>
>> @?6A62?FEH9E=6o2@=]4@> [r4o7t]
>
>
> Yes the systems are completely upgraded before this error occurs.
>
> Shell in use when this happens is KSH.
>
> I'll type set -o vi. Nothing happens..However , No matter what I type
> following this causes segmentation fault.

FWIW - I switched to the korn shell, in my RHEL 5.2, and then entered:
# set -o vi and then # ls. I encountered no troubles.

So - can we get you to try and divide and conquer? I don't know about
your constraints, priorities, commitments or logistics. Not knowing how
involved your scripts are, or how many scripts you're running. Are the
scripts always entered in the same identical sequence?

Does dmesg, or any of your other logs, give any additional clues?

Would it be possible to enter the lines in your scripts manually - one
line at a time, followed by your "set -o vi && ls" sequence such that
further isolation takes place?

I know this will take time. An alternative might be one where you
publish your scripts in a /pub directory on some server for peer
inspection. If the scripts are very minimal, I suppose others in this
NG would not object to their publication here.

--
1PW

@?6A62?FEH9E=6o2@=]4@> [r4o7t]

On Sep 3, 3:11 pm, 1PW wrote:
> On 09/03/2008 11:23 AM, UKnicks sent:
>
>
>
> > On Sep 3, 1:34 pm, 1PW wrote:
> >> On 09/03/2008 05:47 AM, UKnicks sent:
>
> >>> ALL:
> >>> We use a build and customization (B&C) process (a bunch of
> >>> scripts) to rebuild boxes after we've installed RHEL5. I believe, not
> >>> completely sure, some kernel changes are made. Problem is after we
> >>> run our B&C and try to issue a set -o vi command it causes a
> >>> segmentation fault and a core dump.
> >>> [ I just tried this myself.. I logged onto a remote box... issued a
> >>> set -o vi command and nothing happened. The next command I typed,
> >>> "ls", caused the box to kick me out. I returned to the same directory
> >>> and found a core file]
> >>> Testers have reported this doesn't occur before the B&C process. Any
> >>> ideas?
> >>> I apologize if I've left out any pertinent information. I'll try to
> >>> repost it as soon as requested.
> >>> Thanx
> >> Are the systems in question _completely_ updated to RHEL 5.2 before the
> >> failure occurs?
>
> >> What shell is in use at the instant of failure? ($ echo $0)
>
> >> A rather short search of Red Hat's Bugzilla hasn't yet found anything
> >> close to this. However, that doesn't mean I looked in all the right
> >> places.
>
> >> Since more than one script is involved, can this be isolated to a
> >> particular script? Have the scripts been vetted in previous installations?
>
> >> Others will probably ask more pointed questions.
>
> >> This is certainly why you're paying Red Hat for support.
>
> >> --
> >> 1PW
>
> >> @?6A62?FEH9E=6o2@=]4@> [r4o7t]
>
> > Yes the systems are completely upgraded before this error occurs.
>
> > Shell in use when this happens is KSH.
>
> > I'll type set -o vi. Nothing happens..However , No matter what I type
> > following this causes segmentation fault.
>
> FWIW - I switched to the korn shell, in my RHEL 5.2, and then entered:
> # set -o vi and then # ls. I encountered no troubles.
>
> So - can we get you to try and divide and conquer? I don't know about
> your constraints, priorities, commitments or logistics. Not knowing how
> involved your scripts are, or how many scripts you're running. Are the
> scripts always entered in the same identical sequence?
>
> Does dmesg, or any of your other logs, give any additional clues?
>
> Would it be possible to enter the lines in your scripts manually - one
> line at a time, followed by your "set -o vi && ls" sequence such that
> further isolation takes place?
>
> I know this will take time. An alternative might be one where you
> publish your scripts in a /pub directory on some server for peer
> inspection. If the scripts are very minimal, I suppose others in this
> NG would not object to their publication here.
>
> --
> 1PW
>
> @?6A62?FEH9E=6o2@=]4@> [r4o7t]


Tomorrow morning we've decided to split the Build and Customization
script in half and rebuild before running each half. Then we'll at
least be able to narrow it down to either the bottom of top half of
the B&C process. After we find which half the error is in we'll
divide and conquer that half of the process.

I'd say we run anywhere from 10-15 scripts, always in the same
sequence.

I ran dmesg saw the output, ran the "set -o vi ; ls" command sequence,
ran dmesg again and saw no difference in the output. Did i do that
correctly? I also tailed /var/log/messages and nothing was written
there either. These are the only two places I've checked. If you
know of any others, I'd be glad to look.

On 09/03/2008 12:23 PM, UKnicks sent:

Snip, snip...

> Tomorrow morning we've decided to split the Build and Customization
> script in half and rebuild before running each half. Then we'll at
> least be able to narrow it down to either the bottom of top half of
> the B&C process. After we find which half the error [it] is in we'll
> divide and conquer that half of the process.

Outstanding! Of course Murphy's law shall be invoked... It'll be in
the portion you didn't run. ;-(

>
> I'd say we run anywhere from 10-15 scripts, always in the same
> sequence.

Good! Very useful... Don't change.

>
> I ran dmesg saw the output, ran the "set -o vi ; ls" command sequence,
> ran dmesg again and saw no difference in the output. Did i do that
> correctly?

As long as another core dump _was_ written - yes. True?

I also tailed /var/log/messages and nothing was written
> there either. These are the only two places I've checked. If you
> know of any others, I'd be glad to look.

Nothing immediate comes to mind. Perhaps you'll find your own solution
tomorrow. Even if you do, please post your results for all of us to
learn from.

Good luck to you all!

--
1PW

@?6A62?FEH9E=6o2@=]4@> [r4o7t]

UKnicks wrote:
> ALL:
>
> We use a build and customization (B&C) process (a bunch of
> scripts) to rebuild boxes after we've installed RHEL5. I believe, not
> completely sure, some kernel changes are made. Problem is after we
> run our B&C and try to issue a set -o vi command it causes a
> segmentation fault and a core dump.
>
> [ I just tried this myself.. I logged onto a remote box... issued a
> set -o vi command and nothing happened. The next command I typed,
> "ls", caused the box to kick me out. I returned to the same directory
> and found a core file]
>
>
> Testers have reported this doesn't occur before the B&C process. Any
> ideas?
>
> I apologize if I've left out any pertinent information. I'll try to
> repost it as soon as requested.
>
> Thanx

'set' is internal to the shell I believe - missing dependancy maybe?
`ldd /bin/ksh` ? Maybe try an strace|ptrace to see where it is
yacking... Run the ptrace on echo $$ and see if you can get anything in
a log file somewhere... Just throwing some ideas out.

JR.


--

Bill will have to take Linux from my cold, dead flippers.

-Tux.

Johnny Rebel wrote:
> UKnicks wrote:
>> ALL:
>>
>> We use a build and customization (B&C) process (a bunch of
>> scripts) to rebuild boxes after we've installed RHEL5. I believe, not
>> completely sure, some kernel changes are made. Problem is after we
>> run our B&C and try to issue a set -o vi command it causes a
>> segmentation fault and a core dump.
>>
>> [ I just tried this myself.. I logged onto a remote box... issued a
>> set -o vi command and nothing happened. The next command I typed,
>> "ls", caused the box to kick me out. I returned to the same directory
>> and found a core file]
>>
>>
>> Testers have reported this doesn't occur before the B&C process. Any
>> ideas?
>>
>> I apologize if I've left out any pertinent information. I'll try to
>> repost it as soon as requested.
>>
>> Thanx
>
> 'set' is internal to the shell I believe - missing dependancy maybe?
> `ldd /bin/ksh` ? Maybe try an strace|ptrace to see where it is
> yacking... Run the ptrace on echo $$ and see if you can get anything in
> a log file somewhere... Just throwing some ideas out.
>
> JR.
>
>

Just thinking as well - vi is an alias for vim on Linux, and alias is
also an internal command. Maybe there is an issue with this somewhere?

JR.


--

Bill will have to take Linux from my cold, dead flippers.

-Tux.

On 09/03/2008 04:19 PM, Johnny Rebel sent:
> Johnny Rebel wrote:
>> UKnicks wrote:
>>> ALL:
>>>
>>> We use a build and customization (B&C) process (a bunch of
>>> scripts) to rebuild boxes after we've installed RHEL5. I believe, not
>>> completely sure, some kernel changes are made. Problem is after we
>>> run our B&C and try to issue a set -o vi command it causes a
>>> segmentation fault and a core dump.
>>>
>>> [ I just tried this myself.. I logged onto a remote box... issued a
>>> set -o vi command and nothing happened. The next command I typed,
>>> "ls", caused the box to kick me out. I returned to the same directory
>>> and found a core file]
>>>
>>>
>>> Testers have reported this doesn't occur before the B&C process. Any
>>> ideas?
>>>
>>> I apologize if I've left out any pertinent information. I'll try to
>>> repost it as soon as requested.
>>>
>>> Thanx
>> 'set' is internal to the shell I believe - missing dependancy maybe?
>> `ldd /bin/ksh` ? Maybe try an strace|ptrace to see where it is
>> yacking... Run the ptrace on echo $$ and see if you can get anything in
>> a log file somewhere... Just throwing some ideas out.
>>
>> JR.
>>
>>
>
> Just thinking as well - vi is an alias for vim on Linux, and alias is
> also an internal command. Maybe there is an issue with this somewhere?
>
> JR.
>
>

Good theories JR. Maybe we'll get more information later on Thursday.

--
1PW

@?6A62?FEH9E=6o2@=]4@> [r4o7t]

1PW wrote:
> On 09/03/2008 04:19 PM, Johnny Rebel sent:
>> Johnny Rebel wrote:
>>> UKnicks wrote:
>>>> ALL:
>>>>
>>>> We use a build and customization (B&C) process (a bunch of
>>>> scripts) to rebuild boxes after we've installed RHEL5. I believe, not
>>>> completely sure, some kernel changes are made. Problem is after we
>>>> run our B&C and try to issue a set -o vi command it causes a
>>>> segmentation fault and a core dump.
>>>>
>>>> [ I just tried this myself.. I logged onto a remote box... issued a
>>>> set -o vi command and nothing happened. The next command I typed,
>>>> "ls", caused the box to kick me out. I returned to the same directory
>>>> and found a core file]
>>>>
>>>>
>>>> Testers have reported this doesn't occur before the B&C process. Any
>>>> ideas?
>>>>
>>>> I apologize if I've left out any pertinent information. I'll try to
>>>> repost it as soon as requested.
>>>>
>>>> Thanx
>>> 'set' is internal to the shell I believe - missing dependancy maybe?
>>> `ldd /bin/ksh` ? Maybe try an strace|ptrace to see where it is
>>> yacking... Run the ptrace on echo $$ and see if you can get anything in
>>> a log file somewhere... Just throwing some ideas out.
>>>
>>> JR.
>>>
>>>
>> Just thinking as well - vi is an alias for vim on Linux, and alias is
>> also an internal command. Maybe there is an issue with this somewhere?
>>
>> JR.
>>
>>
>
> Good theories JR. Maybe we'll get more information later on Thursday.
>

Thanks! Although some people get an icky feeling using the trace
family. Here is hoping the issue gets resolved!

JR.


--

Bill will have to take Linux from my cold, dead flippers.

-Tux.

On Sep 4, 2:15 pm, Johnny Rebel wrote:
> 1PW wrote:
> > On 09/03/2008 04:19 PM, Johnny Rebel sent:
> >> Johnny Rebel wrote:
> >>> UKnicks wrote:
> >>>> ALL:
>
> >>>> We use a build and customization (B&C) process (a bunch of
> >>>> scripts) to rebuild boxes after we've installed RHEL5. I believe, not
> >>>> completely sure, some kernel changes are made. Problem is after we
> >>>> run our B&C and try to issue a set -o vi command it causes a
> >>>> segmentation fault and a core dump.
>
> >>>> [ I just tried this myself.. I logged onto a remote box... issued a
> >>>> set -o vi command and nothing happened. The next command I typed,
> >>>> "ls", caused the box to kick me out. I returned to the same directory
> >>>> and found a core file]
>
> >>>> Testers have reported this doesn't occur before the B&C process. Any
> >>>> ideas?
>
> >>>> I apologize if I've left out any pertinent information. I'll try to
> >>>> repost it as soon as requested.
>
> >>>> Thanx
> >>> 'set' is internal to the shell I believe - missing dependancy maybe?
> >>> `ldd /bin/ksh` ? Maybe try an strace|ptrace to see where it is
> >>> yacking... Run the ptrace on echo $$ and see if you can get anything in
> >>> a log file somewhere... Just throwing some ideas out.
>
> >>> JR.
>
> >> Just thinking as well - vi is an alias for vim on Linux, and alias is
> >> also an internal command. Maybe there is an issue with this somewhere?
>
> >> JR.
>
> > Good theories JR. Maybe we'll get more information later on Thursday.
>
> Thanks! Although some people get an icky feeling using the trace
> family. Here is hoping the issue gets resolved!
>
> JR.
>
> --
>
> Bill will have to take Linux from my cold, dead flippers.
>
> -Tux.



OK! After a day of divide and conquer on 18 scripts we have figured
out who/what the culprit is: Apparently, if your subshell editor is
different from the parent shell's editor it causes this segmentation
fault. The offending line was : export EDITOR=emacs in our /etc/
profile. Our parent shell is bash and the editor is set (by /etc/
profile) as emacs... If you then spawn a ksh subshell ,run set -o vi,
and then type any command it causes the segmentation fault. However if
the parent shell's editor (The bash shell) is set to VI , or is unset
it doesn't cause the error. NO idea why this causes the problem as
we've had this line in our /etc/profile for YEARS now.

On 09/04/2008 12:45 PM, UKnicks sent:

Snip, snip...

>
> OK! After a day of divide and conquer on 18 scripts we have figured
> out who/what the culprit is: Apparently, if your subshell editor is
> different from the parent shell's editor it causes this segmentation
> fault. The offending line was : export EDITOR=emacs in our /etc/
> profile. Our parent shell is bash and the editor is set (by /etc/
> profile) as emacs... If you then spawn a ksh subshell ,run set -o vi,
> and then type any command it causes the segmentation fault. However if
> the parent shell's editor (The bash shell) is set to VI , or is unset
> it doesn't cause the error. NO idea why this causes the problem as
> we've had this line in our /etc/profile for YEARS now.
>

Well Done! All of you folks should be proud of your accomplishment. My
guess is that a Red Hat RPM fixed something, since May 2008, but also
may have unknowingly caused a problem elsewhere.

I scanned Red Hat's bugzilla data base again and failed to find
something like this. I hope you can take the time to open a trouble
with Red Hat. Your notification could reach far. FYI:



Does your operation have something that only works with the Korn shell?

Have any non-redhat applications/utilities been installed that might
even come close to an explanation for this?

You, and your associates, have certainly earned your pay this week.

--
1PW

@?6A62?FEH9E=6o2@=]4@> [r4o7t]

UKnicks wrote:
> On Sep 4, 2:15 pm, Johnny Rebel wrote:
>> 1PW wrote:
>>> On 09/03/2008 04:19 PM, Johnny Rebel sent:
>>>> Johnny Rebel wrote:
>>>>> UKnicks wrote:
>>>>>> ALL:
>>>>>> We use a build and customization (B&C) process (a bunch of
>>>>>> scripts) to rebuild boxes after we've installed RHEL5. I believe, not
>>>>>> completely sure, some kernel changes are made. Problem is after we
>>>>>> run our B&C and try to issue a set -o vi command it causes a
>>>>>> segmentation fault and a core dump.
>>>>>> [ I just tried this myself.. I logged onto a remote box... issued a
>>>>>> set -o vi command and nothing happened. The next command I typed,
>>>>>> "ls", caused the box to kick me out. I returned to the same directory
>>>>>> and found a core file]
>>>>>> Testers have reported this doesn't occur before the B&C process. Any
>>>>>> ideas?
>>>>>> I apologize if I've left out any pertinent information. I'll try to
>>>>>> repost it as soon as requested.
>>>>>> Thanx
>>>>> 'set' is internal to the shell I believe - missing dependancy maybe?
>>>>> `ldd /bin/ksh` ? Maybe try an strace|ptrace to see where it is
>>>>> yacking... Run the ptrace on echo $$ and see if you can get anything in
>>>>> a log file somewhere... Just throwing some ideas out.
>>>>> JR.
>>>> Just thinking as well - vi is an alias for vim on Linux, and alias is
>>>> also an internal command. Maybe there is an issue with this somewhere?
>>>> JR.
>>> Good theories JR. Maybe we'll get more information later on Thursday.
>> Thanks! Although some people get an icky feeling using the trace
>> family. Here is hoping the issue gets resolved!
>>
>> JR.
>>
>> --
>>
>> Bill will have to take Linux from my cold, dead flippers.
>>
>> -Tux.
>
>
>
> OK! After a day of divide and conquer on 18 scripts we have figured
> out who/what the culprit is: Apparently, if your subshell editor is
> different from the parent shell's editor it causes this segmentation
> fault. The offending line was : export EDITOR=emacs in our /etc/
> profile. Our parent shell is bash and the editor is set (by /etc/
> profile) as emacs... If you then spawn a ksh subshell ,run set -o vi,
> and then type any command it causes the segmentation fault. However if
> the parent shell's editor (The bash shell) is set to VI , or is unset
> it doesn't cause the error. NO idea why this causes the problem as
> we've had this line in our /etc/profile for YEARS now.
>

Very cool. Glad you have it fixed, and posted back. How come you are
using ksh on Linux anyways? I personally go the other way and put bash
on all Unix systems. That way, most of the things that get changed are
truly bugs/OS features between different flavours. Plus ksh on Unix
systems don't come with source code making it difficult to fix anything.
Just curious why the ksh?

JR.


--

Bill will have to take Linux from my cold, dead flippers.

-Tux.

On Sep 4, 6:55 pm, Johnny Rebel wrote:
> UKnicks wrote:
> > On Sep 4, 2:15 pm, Johnny Rebel wrote:
> >> 1PW wrote:
> >>> On 09/03/2008 04:19 PM, Johnny Rebel sent:
> >>>> Johnny Rebel wrote:
> >>>>> UKnicks wrote:
> >>>>>> ALL:
> >>>>>> We use a build and customization (B&C) process (a bunch of
> >>>>>> scripts) to rebuild boxes after we've installed RHEL5. I believe, not
> >>>>>> completely sure, some kernel changes are made. Problem is after we
> >>>>>> run our B&C and try to issue a set -o vi command it causes a
> >>>>>> segmentation fault and a core dump.
> >>>>>> [ I just tried this myself.. I logged onto a remote box... issued a
> >>>>>> set -o vi command and nothing happened. The next command I typed,
> >>>>>> "ls", caused the box to kick me out. I returned to the same directory
> >>>>>> and found a core file]
> >>>>>> Testers have reported this doesn't occur before the B&C process. Any
> >>>>>> ideas?
> >>>>>> I apologize if I've left out any pertinent information. I'll try to
> >>>>>> repost it as soon as requested.
> >>>>>> Thanx
> >>>>> 'set' is internal to the shell I believe - missing dependancy maybe?
> >>>>> `ldd /bin/ksh` ? Maybe try an strace|ptrace to see where it is
> >>>>> yacking... Run the ptrace on echo $$ and see if you can get anything in
> >>>>> a log file somewhere... Just throwing some ideas out.
> >>>>> JR.
> >>>> Just thinking as well - vi is an alias for vim on Linux, and alias is
> >>>> also an internal command. Maybe there is an issue with this somewhere?
> >>>> JR.
> >>> Good theories JR. Maybe we'll get more information later on Thursday.
> >> Thanks! Although some people get an icky feeling using the trace
> >> family. Here is hoping the issue gets resolved!
>
> >> JR.
>
> >> --
>
> >> Bill will have to take Linux from my cold, dead flippers.
>
> >> -Tux.
>
> > OK! After a day of divide and conquer on 18 scripts we have figured
> > out who/what the culprit is: Apparently, if your subshell editor is
> > different from the parent shell's editor it causes this segmentation
> > fault. The offending line was : export EDITOR=emacs in our /etc/
> > profile. Our parent shell is bash and the editor is set (by /etc/
> > profile) as emacs... If you then spawn a ksh subshell ,run set -o vi,
> > and then type any command it causes the segmentation fault. However if
> > the parent shell's editor (The bash shell) is set to VI , or is unset
> > it doesn't cause the error. NO idea why this causes the problem as
> > we've had this line in our /etc/profile for YEARS now.
>
> Very cool. Glad you have it fixed, and posted back. How come you are
> using ksh on Linux anyways? I personally go the other way and put bash
> on all Unix systems. That way, most of the things that get changed are
> truly bugs/OS features between different flavours. Plus ksh on Unix
> systems don't come with source code making it difficult to fix anything.
> Just curious why the ksh?
>
> JR.
>
> --
>
> Bill will have to take Linux from my cold, dead flippers.
>
> -Tux.

Hmmm, I don't have a definite answer for why we use ksh. I think it
does have something to do with our application though. Its always been
this way as far as I know. Anyway thanx for the assistance.

UKnicks wrote:
> On Sep 3, 1:34 pm, 1PW wrote:
>> On 09/03/2008 05:47 AM, UKnicks sent:
>>
>>
>>
>>> ALL:
>>> We use a build and customization (B&C) process (a bunch of
>>> scripts) to rebuild boxes after we've installed RHEL5. I believe, not
>>> completely sure, some kernel changes are made. Problem is after we
>>> run our B&C and try to issue a set -o vi command it causes a
>>> segmentation fault and a core dump.
>>> [ I just tried this myself.. I logged onto a remote box... issued a
>>> set -o vi command and nothing happened. The next command I typed,
>>> "ls", caused the box to kick me out. I returned to the same directory
>>> and found a core file]
>>> Testers have reported this doesn't occur before the B&C process. Any
>>> ideas?
>>> I apologize if I've left out any pertinent information. I'll try to
>>> repost it as soon as requested.
>>> Thanx
>> Are the systems in question _completely_ updated to RHEL 5.2 before the
>> failure occurs?
>>
>> What shell is in use at the instant of failure? ($ echo $0)
>>
>> A rather short search of Red Hat's Bugzilla hasn't yet found anything
>> close to this. However, that doesn't mean I looked in all the right
>> places.
>>
>> Since more than one script is involved, can this be isolated to a
>> particular script? Have the scripts been vetted in previous installations?
>>
>> Others will probably ask more pointed questions.
>>
>> This is certainly why you're paying Red Hat for support.
>
>> --
>> 1PW
>>
>> @?6A62?FEH9E=6o2@=]4@> [r4o7t]
>
>
> Yes the systems are completely upgraded before this error occurs.
>
> Shell in use when this happens is KSH.
>
> I'll type set -o vi. NOthing happens..However , No matter what I type
> following this causes segmentation fault.

And you're using ksh..... why? It's not well supported for Linux. Can you
switch to Bash?

UKnicks wrote:
> On Sep 4, 6:55 pm, Johnny Rebel wrote:
>> UKnicks wrote:
>>> On Sep 4, 2:15 pm, Johnny Rebel wrote:
>>>> 1PW wrote:
>>>>> On 09/03/2008 04:19 PM, Johnny Rebel sent:
>>>>>> Johnny Rebel wrote:
>>>>>>> UKnicks wrote:
>>>>>>>> ALL:
>>>>>>>> We use a build and customization (B&C) process (a bunch of
>>>>>>>> scripts) to rebuild boxes after we've installed RHEL5. I believe, not
>>>>>>>> completely sure, some kernel changes are made. Problem is after we
>>>>>>>> run our B&C and try to issue a set -o vi command it causes a
>>>>>>>> segmentation fault and a core dump.
>>>>>>>> [ I just tried this myself.. I logged onto a remote box... issued a
>>>>>>>> set -o vi command and nothing happened. The next command I typed,
>>>>>>>> "ls", caused the box to kick me out. I returned to the same directory
>>>>>>>> and found a core file]
>>>>>>>> Testers have reported this doesn't occur before the B&C process. Any
>>>>>>>> ideas?
>>>>>>>> I apologize if I've left out any pertinent information. I'll try to
>>>>>>>> repost it as soon as requested.
>>>>>>>> Thanx
>>>>>>> 'set' is internal to the shell I believe - missing dependancy maybe?
>>>>>>> `ldd /bin/ksh` ? Maybe try an strace|ptrace to see where it is
>>>>>>> yacking... Run the ptrace on echo $$ and see if you can get anything in
>>>>>>> a log file somewhere... Just throwing some ideas out.
>>>>>>> JR.
>>>>>> Just thinking as well - vi is an alias for vim on Linux, and alias is
>>>>>> also an internal command. Maybe there is an issue with this somewhere?
>>>>>> JR.
>>>>> Good theories JR. Maybe we'll get more information later on Thursday.
>>>> Thanks! Although some people get an icky feeling using the trace
>>>> family. Here is hoping the issue gets resolved!
>>>> JR.
>>>> --
>>>> Bill will have to take Linux from my cold, dead flippers.
>>>> -Tux.
>>> OK! After a day of divide and conquer on 18 scripts we have figured
>>> out who/what the culprit is: Apparently, if your subshell editor is
>>> different from the parent shell's editor it causes this segmentation
>>> fault. The offending line was : export EDITOR=emacs in our /etc/
>>> profile. Our parent shell is bash and the editor is set (by /etc/
>>> profile) as emacs... If you then spawn a ksh subshell ,run set -o vi,
>>> and then type any command it causes the segmentation fault. However if
>>> the parent shell's editor (The bash shell) is set to VI , or is unset
>>> it doesn't cause the error. NO idea why this causes the problem as
>>> we've had this line in our /etc/profile for YEARS now.
>> Very cool. Glad you have it fixed, and posted back. How come you are
>> using ksh on Linux anyways? I personally go the other way and put bash
>> on all Unix systems. That way, most of the things that get changed are
>> truly bugs/OS features between different flavours. Plus ksh on Unix
>> systems don't come with source code making it difficult to fix anything.
>> Just curious why the ksh?
>>
>> JR.
>>
>> --
>>
>> Bill will have to take Linux from my cold, dead flippers.
>>
>> -Tux.
>
> Hmmm, I don't have a definite answer for why we use ksh. I think it
> does have something to do with our application though. Its always been
> this way as far as I know. Anyway thanx for the assistance.
>

I would suggest investigating that further (using bash that is) - it may
save you headaches in the future. It is also native to the OS... when
in Rome...

No probs.

JR.


--

Bill will have to take Linux from my cold, dead flippers.

-Tux.

On 09/05/2008 04:55 AM, UKnicks sent:

Snip, snip...

>>> OK! After a day of divide and conquer on 18 scripts we have figured
>>> out who/what the culprit is: Apparently, if your subshell editor is
>>> different from the parent shell's editor it causes this segmentation
>>> fault. The offending line was : export EDITOR=emacs in our /etc/
>>> profile. Our parent shell is bash and the editor is set (by /etc/
>>> profile) as emacs... If you then spawn a ksh subshell ,run set -o vi,
>>> and then type any command it causes the segmentation fault. However if
>>> the parent shell's editor (The bash shell) is set to VI , or is unset
>>> it doesn't cause the error. NO idea why this causes the problem as
>>> we've had this line in our /etc/profile for YEARS now.
>> Very cool. Glad you have it fixed, and posted back. How come you are
>> using ksh on Linux anyways? I personally go the other way and put bash
>> on all Unix systems. That way, most of the things that get changed are
>> truly bugs/OS features between different flavours. Plus ksh on Unix
>> systems don't come with source code making it difficult to fix anything.
>> Just curious why the ksh?
>>
>> JR.
>>
>> --
>>
>> Bill will have to take Linux from my cold, dead flippers.
>>
>> -Tux.
>
> Hmmm, I don't have a definite answer for why we use ksh. I think it
> does have something to do with our application though. Its always been
> this way as far as I know. Anyway thanx for the assistance.
>

I have really never used ksh nor had I ever contemplated studying it.
However, it appears as if several features of ksh may have attracted the
author(s) of one or more of your possible scripts to use this.



The above shows more than two or three features that may have been
called upon when writing one or more of your possible scripts.

I was raised on tcsh myself, and later I converted to bash, but I think
I would have liked to pick up a few things about ksh before I became too
set in my ways.

Again, I do hope you file a trouble with Red Hat for the segmentation
fault discoveries you've made.

--
1PW

@?6A62?FEH9E=6o2@=]4@> [r4o7t]