zsh login coredump

zsh login coredump

[mneptok]

Recently zsh started failing as a login shell. It can be invoked without
problems from another shell, but trying to log in remotely causes zsh to
coredump.

It looks to be related to Kerberos. Anyone have any insight?

=====

/etc/profile:33: parse error: condition expected: =
zsh: done                               |
zsh: segmentation fault (core dumped)
zsh: done                 |
zsh: segmentation fault
zsh: done                 |
zsh: segmentation fault
/etc/profile.d/krb5.sh:5: parse error: condition expected: =
Connection to *******.org closed.

=====

./k

kurt von finck
-- 
http://www.mneptok.com
mneptok@mneptok.com
--
public key at: subkeys.pgp.net
server key id: 5229D26A
fingerprint: 127A A484 ADBF A5AD E7FB 8CD2 8913 18F4 5229 D26A
--
Success is more a function of consistent common sense than it is of
genius. - An Wang
--

Re: zsh login coredump

[Bart Schaefer]

On May 21,  4:23pm, mneptok wrote:
> 
> It looks to be related to Kerberos. Anyone have any insight?

Did it occur to you to look at /etc/profile line 33 or perhaps at
/etc/profile.d/krb5.sh line 5, to see what's causing the parse errors?

Has /etc/profile or /etc/profile.d/krb5.sh changed recently?  Why?

Re: zsh login coredump

[mneptok]

On Sat, 2005-05-21 at 17:17 -0700, Bart Schaefer wrote:

> Did it occur to you to look at /etc/profile line 33 or perhaps at
> /etc/profile.d/krb5.sh line 5, to see what's causing the parse errors?
> 
> Has /etc/profile or /etc/profile.d/krb5.sh changed recently?  Why?

Yes, it did occur to me, but nothing jumped out at me:

=====
profile
=====

32 # Path manipulation
33 if [ `id -u` = 0 ]; then
34         pathmunge /sbin
35         pathmunge /usr/sbin
36         pathmunge /usr/local/sbin

=====
krb5.sh
=====

1 if ! echo ${PATH} | grep -q /usr/kerberos/bin ; then
2         PATH=/usr/kerberos/bin:${PATH}
3 fi
4 if ! echo ${PATH} | grep -q /usr/kerberos/sbin ; then
5         if [ `id -u` = 0 ] ; then
6                 PATH=/usr/kerberos/sbin:${PATH}
7         fi
8 fi
=====

./k

kurt von finck
-- 
http://www.mneptok.com
mneptok@mneptok.com
--
public key at: subkeys.pgp.net
server key id: 5229D26A
fingerprint: 127A A484 ADBF A5AD E7FB 8CD2 8913 18F4 5229 D26A
--
Success is more a function of consistent common sense than it is of
genius. - An Wang
--

Re: zsh login coredump

[Bart Schaefer]

On May 21,  8:15pm, mneptok wrote:
} Subject: Re: zsh login coredump
}
} On Sat, 2005-05-21 at 17:17 -0700, Bart Schaefer wrote:
} 
} > Did it occur to you to look at /etc/profile line 33 or perhaps at
} > /etc/profile.d/krb5.sh line 5, to see what's causing the parse errors?
} > 
} > Has /etc/profile or /etc/profile.d/krb5.sh changed recently?  Why?
} 
} Yes, it did occur to me, but nothing jumped out at me:
} 
} 33 if [ `id -u` = 0 ]; then
} 
} 5         if [ `id -u` = 0 ] ; then

OK, so ...

If you're getting a parse error on that line, the problem must be that
`id -u` is returning *nothing* (it might very well be dumping core as
well).  Since `id -u` only prints an integer, it must be the case that
it's unable even to obtain that integer, which means that one of

      euid = geteuid ();
      ruid = getuid ();
      egid = getegid ();
      rgid = getgid ();

is failing catastrophically.

As zsh also calls these library routines, that's probably the cause of
the crash.

Re: zsh login coredump

[mneptok]

On Sun, 2005-05-22 at 06:04 +0000, Bart Schaefer wrote:

> OK, so ...
> 
> If you're getting a parse error on that line, the problem must be that
> `id -u` is returning *nothing* (it might very well be dumping core as
> well).  Since `id -u` only prints an integer, it must be the case that
> it's unable even to obtain that integer, which means that one of
> 
>       euid = geteuid ();
>       ruid = getuid ();
>       egid = getegid ();
>       rgid = getgid ();
> 
> is failing catastrophically.
> 
> As zsh also calls these library routines, that's probably the cause of
> the crash.

"id -u" works form within bash and zsh.

-bash-2.05b$ id -u
32033

-bash-2.05b$ zsh

[mnep@gong]~% id -u
32033

Odd.

./k

kurt von finck
-- 
http://www.mneptok.com
mneptok@mneptok.com
--
public key at: subkeys.pgp.net
server key id: 5229D26A
fingerprint: 127A A484 ADBF A5AD E7FB 8CD2 8913 18F4 5229 D26A
--
Success is more a function of consistent common sense than it is of
genius. - An Wang
--

Re: zsh login coredump

[Bart Schaefer]

On May 21, 11:20pm, mneptok wrote:
}
} "id -u" works form within bash and zsh.

It would seem that once you've gotten as far as having an interactive
shell, whatever conditions are causing the failure no longer apply.

Try putting a call to id -u in ~/.zshenv (which should get executed
before /etc/profile) so you have a chance to see what it's returning
(or not).  E.g.:

echo calling id ...
id -u
echo done with id

} Odd.

Yes.

Re: zsh login coredump

[mneptok]

On Sun, 2005-05-22 at 15:38 +0000, Bart Schaefer wrote:
> On May 21, 11:20pm, mneptok wrote:
> }
> } "id -u" works form within bash and zsh.
> 
> It would seem that once you've gotten as far as having an interactive
> shell, whatever conditions are causing the failure no longer apply.
> 
> Try putting a call to id -u in ~/.zshenv (which should get executed
> before /etc/profile) so you have a chance to see what it's returning
> (or not).  E.g.:
> 
> echo calling id ...
> id -u
> echo done with id

Result:

calling id ...
32005
done with id
/etc/profile:33: parse error: condition expected: =
zsh: done                               |
zsh: segmentation fault (core dumped) 
Connection to *********.org closed.

Any ideas? Anyone? Bueller?

./k

kurt von finck
-- 
http://www.mneptok.com
mneptok@mneptok.com
--
public key at: subkeys.pgp.net
server key id: 5229D26A
fingerprint: 127A A484 ADBF A5AD E7FB 8CD2 8913 18F4 5229 D26A
--
Success is more a function of consistent common sense than it is of
genius. - An Wang
--

Re: zsh login coredump

[Bart Schaefer]

On May 23,  1:37am, mneptok wrote:
} Subject: Re: zsh login coredump
}
} calling id ...
} 32005
} done with id
} /etc/profile:33: parse error: condition expected: =
} 
} Any ideas? Anyone? Bueller?

Well, that's fairly odd.

Next thing to try might be putting "set -x" into ~/.zshenv so you can
watch the whole startup sequence, but there may be a *lot* of output.