umlimit and /etc/zshenv

umlimit and /etc/zshenv

[Thorsten Haude]

Hi,

I have the following line in my /etc/zshenv:
    ulimit -c 20000

1. This is a legacy from the Bash. I read zsh's manpage but couldn't
find a clear statement about what happens if neither -S nor -H are
given.

2. I get problems with this command when a process reduces the hard
limit and calls a subprocess. So I wonder whether I get the semantics
of /etc/zshenv and ulimit wrong and ulimit should in fact be in
another /etc/z* file.
Could someone explain where my error is?

tia,
Thorsten
-- 
Im übrigen gilt ja hier derjenige, der auf den Schmutz hinweist,
für viel gefährlicher als der, der den Schmutz macht.
	- Kurt Tucholsky

Re: umlimit and /etc/zshenv

[Peter Stephenson]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3436 bytes --]

Thorsten Haude wrote:
> Hi,
> 
> I have the following line in my /etc/zshenv:
>     ulimit -c 20000
> 
> 1. This is a legacy from the Bash. I read zsh's manpage but couldn't
> find a clear statement about what happens if neither -S nor -H are
> given.

If -H isn't set, soft limits are assumed.  The manual page is a little
elliptical, but reading what it doesn't quite say implies this --- -S is
there to allow you to set both types of limit at once.  The patch at the
bottom makes this clearer.

> 2. I get problems with this command when a process reduces the hard
> limit and calls a subprocess. So I wonder whether I get the semantics
> of /etc/zshenv and ulimit wrong and ulimit should in fact be in
> another /etc/z* file.
> Could someone explain where my error is?

I think you're saying you're reducing the hard limit, and then executing
a command (the one in /etc/zshenv) which tries to make the soft limit
higher than the hard limit.  I think that's the correct behaviour ---
there's no way it can increase the value past the hard limit, and zsh
happens to warn you it can't do that when other shells may not (you may
find bash returns status 1 even if it doesn't print anything).

If this is what is going on, you need to work around it somehow:  either
use the output from ulimit or limit to decide what the hard limit is, or
if you're not interested in the error message simply send it to
/dev/null with `2>/dev/null'.

> Im übrigen gilt ja hier derjenige, der auf den Schmutz hinweist,
> für viel gefährlicher als der, der den Schmutz macht.
> 	- Kurt Tucholsky

(In case anyone was wondering: in general the people who root out dirt
should be considered much more dangerous than those who make the dirt in
the first place.)

Index: Doc/Zsh/builtins.yo
===================================================================
RCS file: /cvsroot/zsh/zsh/Doc/Zsh/builtins.yo,v
retrieving revision 1.44
diff -u -r1.44 builtins.yo
--- Doc/Zsh/builtins.yo	20 Feb 2002 12:51:53 -0000	1.44
+++ Doc/Zsh/builtins.yo	10 May 2002 09:32:07 -0000
@@ -1281,7 +1281,8 @@
 item(tt(ulimit) [ tt(-SHacdflmnpstv) [ var(limit) ] ... ])(
 Set or display resource limits of the shell and the processes started by
 the shell.  The value of var(limit) can be a number in the unit specified
-below or the value `tt(unlimited)'.  If the tt(-H) flag is given use
+below or the value `tt(unlimited)'.  By default, only soft limits are
+manipulated. If the tt(-H) flag is given use
 hard limits instead of soft limits.  If the tt(-S) flag is given
 together with the tt(-H) flag set both hard and soft limits.  If no
 options are used, the file size limit (tt(-f)) is assumed.  If

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR Ltd., Science Park, Milton Road,
Cambridge, CB4 0WH, UK                          Tel: +44 (0)1223 392070


**********************************************************************
The information transmitted is intended only for the person or
entity to which it is addressed and may contain confidential 
and/or privileged material. 
Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by 
persons or entities other than the intended recipient is 
prohibited.  
If you received this in error, please contact the sender and 
delete the material from any computer.
**********************************************************************

Re: umlimit and /etc/zshenv

[Thorsten Haude]

Hi Peter,

* Peter Stephenson <pws@csr.com> [02-05-10 11:40]:
>Thorsten Haude wrote:
>> I have the following line in my /etc/zshenv:
>>     ulimit -c 20000
>> 
>> 1. This is a legacy from the Bash. I read zsh's manpage but couldn't
>> find a clear statement about what happens if neither -S nor -H are
>> given.
>If -H isn't set, soft limits are assumed.  The manual page is a little
>elliptical, but reading what it doesn't quite say implies this --- -S is
>there to allow you to set both types of limit at once.  The patch at the
>bottom makes this clearer.
Thanks for clearing that up.

>> 2. I get problems with this command when a process reduces the hard
>> limit and calls a subprocess. So I wonder whether I get the semantics
>> of /etc/zshenv and ulimit wrong and ulimit should in fact be in
>> another /etc/z* file.
>> Could someone explain where my error is?
>I think you're saying you're reducing the hard limit, and then executing
>a command (the one in /etc/zshenv) which tries to make the soft limit
>higher than the hard limit.  I think that's the correct behaviour ---
>there's no way it can increase the value past the hard limit, and zsh
>happens to warn you it can't do that when other shells may not (you may
>find bash returns status 1 even if it doesn't print anything).
>
>If this is what is going on, you need to work around it somehow:  either
>use the output from ulimit or limit to decide what the hard limit is, or
>if you're not interested in the error message simply send it to
>/dev/null with `2>/dev/null'.
That's what I scraped together myself. I don't think one of the
applications involved is doing wrong, the result is however that I
get an error.
To name names: Mutt uses setrlimit() to disable coredumps before
handling the PGP passphrase. A macro for NEdit uses a shell command
to get an environmental variable. This uses /etc/zshenv of course, the
ulimit returns with an error and the macro command does not succeed
because the expected result is prepended by ulimit's error output.

I could do several things to avoid the error:
- Use another macro command, which does not shell out. I already did
that, but in general I think the ability to do shell commands in an
editor is more than just nice to have.
- I could remove the ulimit from /etc/zshenv, but I'm not sure how
large cores can get, so I'd rather keep it, and not only for
interactive shells.
- I could redirect ulimits output in /etc/zshenv, but that would
prevent seeing other, maybe more serious errors.
- NEdit or Mutt could handle things differrently. But how?
Would it be better for NEdit to just ignore stderr when returning
results, only evaluating it to show an error?
I don't know whether Mutt could do with a soft limit. 

I just want to learn more about the issues involved in case a similar
error is coming up that can't be avoided as easily.

Thanks for your help!

>> Im übrigen gilt ja hier derjenige, der auf den Schmutz hinweist,
>> für viel gefährlicher als der, der den Schmutz macht.
>> 	- Kurt Tucholsky
>(In case anyone was wondering: in general the people who root out dirt
>should be considered much more dangerous than those who make the dirt in
>the first place.)
No "should", please, Tucholsky has been a journalist:
Besides, the one pointing out the dirt is hearabouts considered more
dangerously than the one making it.

(Tucholsky biography: http://www.infoplease.com/ce6/people/A0849625.html)

Thorsten
-- 
Denn ein Tyrann ist nicht, wenn die Masse nicht geduldig stillhält.
	- Kurt Tucholsky

Re: umlimit and /etc/zshenv

[Oliver Kiddle]

Thorsten Haude wrote:

> That's what I scraped together myself. I don't think one of the
> applications involved is doing wrong, the result is however that I
> get an error.
> To name names: Mutt uses setrlimit() to disable coredumps before
> handling the PGP passphrase. A macro for NEdit uses a shell command
> to get an environmental variable. This uses /etc/zshenv of course, the
> ulimit returns with an error and the macro command does not succeed
> because the expected result is prepended by ulimit's error output.

Couldn't mutt restore the limit after getting the PGP passphrase?
Surely it isn't calling nedit to enter the passphrase because it'd then
have the passphrase written in clear to disc anyway.

> I could do several things to avoid the error:
> - Use another macro command, which does not shell out. I already did
> that, but in general I think the ability to do shell commands in an
> editor is more than just nice to have.

I was just wondering about that as nedit has a getenv().

> - I could remove the ulimit from /etc/zshenv, but I'm not sure how
> large cores can get, so I'd rather keep it, and not only for
> interactive shells.

Or set it to zero which is what I do. Whenever I do any debugging I
then have a shell function which unlimits it and sets other things like
CFLAGS.

> - I could redirect ulimits output in /etc/zshenv, but that would
> prevent seeing other, maybe more serious errors.

Probably not a bad idea though. It is generally wise to avoid any
output in .zshenv/zshrc as it can mess up quite a few things like this
(rcp for instance). If you don't want to lose the errors, you could
redirect to a file instead.

> - NEdit or Mutt could handle things differrently. But how?
> Would it be better for NEdit to just ignore stderr when returning
> results, only evaluating it to show an error?

I don't like that idea because it is useful to be able to see things
coming back from stderr in nedit shell comands. I wouldn't object if
nedit passed the stderr output from the shell command on to its own
stderr though.

Oliver

This e-mail and any attachment is for authorised use by the intended recipient(s) only.  It may contain proprietary material, confidential information and/or be subject to legal privilege.  It should not be copied, disclosed to, retained or used by, any other party.  If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender.  Thank you.

Re: umlimit and /etc/zshenv

[Thorsten Haude]

Hi,

* Oliver Kiddle <okiddle@yahoo.co.uk> [02-05-10 14:35]:
>Thorsten Haude wrote:
>> To name names: Mutt uses setrlimit() to disable coredumps before
>> handling the PGP passphrase. A macro for NEdit uses a shell command
>> to get an environmental variable. This uses /etc/zshenv of course, the
>> ulimit returns with an error and the macro command does not succeed
>> because the expected result is prepended by ulimit's error output.
>Couldn't mutt restore the limit after getting the PGP passphrase?
I have no idea, but I will ask the developers.

>Surely it isn't calling nedit to enter the passphrase because it'd then
>have the passphrase written in clear to disc anyway.
No, the error occurs even on mails that are not encrypted or signed if
I used GPG before in the same Mutt session.

>> I could do several things to avoid the error:
>> - Use another macro command, which does not shell out. I already did
>> that, but in general I think the ability to do shell commands in an
>> editor is more than just nice to have.
>I was just wondering about that as nedit has a getenv().
A legacy thing, and not even my own legacy at that.

>> - I could remove the ulimit from /etc/zshenv, but I'm not sure how
>> large cores can get, so I'd rather keep it, and not only for
>> interactive shells.
>Or set it to zero which is what I do. Whenever I do any debugging I
>then have a shell function which unlimits it and sets other things like
>CFLAGS.
That may be to late. The crash may not be repeatable, but the core
might still give useful insights.

>> - I could redirect ulimits output in /etc/zshenv, but that would
>> prevent seeing other, maybe more serious errors.
>Probably not a bad idea though. It is generally wise to avoid any
>output in .zshenv/zshrc as it can mess up quite a few things like this
>(rcp for instance). If you don't want to lose the errors, you could
>redirect to a file instead.
I like being immediately notified of any problems that might arise.
Sure, I could use a logfile and some logsurfery thing.

>> - NEdit or Mutt could handle things differrently. But how?
>> Would it be better for NEdit to just ignore stderr when returning
>> results, only evaluating it to show an error?
>I don't like that idea because it is useful to be able to see things
>coming back from stderr in nedit shell comands. I wouldn't object if
>nedit passed the stderr output from the shell command on to its own
>stderr though.
There was a discussion about this just this week. The error output
could either be done to a command line or with some dialog, both have
advantages and disadvantages.
However, the redirection cannot happen automatically since I may only
be interested in the error output.

Please understand that I don't disagree with all your suggestions, but
I want to explore the issue to find the best way of dealing with this.

Thorsten
-- 
You're not supposed to be so blind with patriotism that you can't face
reality. Wrong is wrong, no matter who does it or who says it.
	- Malcolm X

Re: umlimit and /etc/zshenv

[Bart Schaefer]

On Fri, 10 May 2002, Thorsten Haude wrote:

> I want to explore the issue to find the best way of dealing with this.

The best thing would be for mutt to either use soft limits, or restore the
old limit (which I don't think is possible with hard limits anyway).

The second-best thing would be for you to use something like

[ -t 2 ] && ulimit -c ...

so that the command executes only when somebody might actuall see the
error output.

OT: Quote (was: umlimit and /etc/zshenv)

[Thorsten Haude]

Hi,

* Thorsten Haude <zsh@thorstenhau.de> [02-05-10 13:26]:
>>> Im übrigen gilt ja hier derjenige, der auf den Schmutz hinweist,
>>> für viel gefährlicher als der, der den Schmutz macht.
>>> 	- Kurt Tucholsky
>Besides, the one pointing out the dirt is hearabouts considered more
>dangerously than the one making it.
Sorry: "considered to be much more dangerous"

Thorsten
-- 
It has become appallingly obvious that our technology has exceeded our humanity.
	- Albert Einstein