Bug 4071

Summary: error message starting tcsh from ksh
Product: [Retired] Red Hat Linux Reporter: Dan Yocum <dyocum>
Component: pdkshAssignee: Trond Eivind Glomsrxd <teg>
Status: CLOSED CURRENTRELEASE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 5.2   
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2000-02-15 18:15:48 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Dan Yocum 1999-07-16 14:02:31 UTC
When ksh is used as the login shell and tcsh is invoked
sometime thereafter within a shell or terminal this error
message appears:

limit: coredumpsize: Can't set limit

This does not occur when you change shell in a terminal to
ksh and then to tcsh - only when ksh is the login shell.

This has existed at least since 5.0

Cheers,
Dan

Comment 1 David Lawrence 1999-07-16 18:09:59 UTC
I have verified that this does occur as reported on a standard 6.0
install. It is being assigned to a developer for further review.

Comment 2 Jeff Johnson 1999-08-20 22:32:59 UTC
*** This bug has been marked as a duplicate of 4582 ***

Comment 3 Anonymous 1999-08-26 22:06:59 UTC
From an expert here at the Lab.  Enjoy.  Dan

The ulimit -c and limit coredumpsize values on trocious and bldlinux52
were both set to 1000000, but since these are in different units
(blocks and kbytes, respectively), they are inconsistent.  The
difference is only noticeable if your shell is sh/ksh/bash, and then
you switch to csh/tcsh, which gives an ugly error message, since
you're then attempting to double your quota, and it fails
to execute your .cshrc file.

The value in the /etc/profile files needs to be twice the value in the
/etc/csh.cshrc file, and I have made that change on trocious and
bldlinux52.

I believe on the latest 5.2 release, the value is being set in
/etc/bashrc, rather than /etc/profile, but it should be fixed wherever
it lives.