* Lee Revell ([EMAIL PROTECTED]) wrote:
> On Fri, 2005-07-29 at 13:51 -0700, Chris Wright wrote:
> > * Chris Wright ([EMAIL PROTECTED]) wrote:
> > > Yes, this requires updated pam patch.
> >
> > Here's the updated pam patch. I left the lower end at 0 rather than 1,
> > since it's no harm.
> >
>
On Fri, 2005-07-29 at 13:51 -0700, Chris Wright wrote:
> * Chris Wright ([EMAIL PROTECTED]) wrote:
> > Yes, this requires updated pam patch.
>
> Here's the updated pam patch. I left the lower end at 0 rather than 1,
> since it's no harm.
>
> +/* Hack to test new rlimit values */
Does this stil
On Fri, 29 Jul 2005, Michael Kerrisk uttered the following:
>> On 29 Jul 2005, Michael Kerrisk stated:
>> > Yes, as noted in my earlier message -- at the moment RLIMIT_NICE
>> > still isn't in the current glibc snapshot...
>>
>> According to traffic on libc-hacker, Ulrich committed it on Jun 20
>
* Chris Wright ([EMAIL PROTECTED]) wrote:
> Yes, this requires updated pam patch.
Here's the updated pam patch. I left the lower end at 0 rather than 1,
since it's no harm.
--- Linux-PAM-0.77/modules/pam_limits/pam_limits.c.prio 2005-01-14
10:47:03.0 -0800
+++ Linux-PAM-0.77/modules/pam
* Matt Mackall ([EMAIL PROTECTED]) wrote:
> On Thu, Jul 28, 2005 at 05:04:24PM +0200, Michael Kerrisk wrote:
> > In other words, there is an off-by-one mismatch between
> > these two interfaces: RLIMIT_NICE is expecting to deal
> > with values in the range 39..0, while [gs]etpriority()
> > works
> On 29 Jul 2005, Michael Kerrisk stated:
> > Yes, as noted in my earlier message -- at the moment RLIMIT_NICE
> > still isn't in the current glibc snapshot...
>
> According to traffic on libc-hacker, Ulrich committed it on Jun 20
> (along with RLIMIT_RTPRIO support).
I (now) see the message tha
On 29 Jul 2005, Michael Kerrisk stated:
> Yes, as noted in my earlier message -- at the moment RLIMIT_NICE
> still isn't in the current glibc snapshot...
According to traffic on libc-hacker, Ulrich committed it on Jun 20
(along with RLIMIT_RTPRIO support).
--
`Tor employs several thousand edito
> > The other downside is, this obviously changes any existing configs
> > actually using this by one nice level..
>
> it's pretty harmless, and i doubt the use of this is all that wide (if
> existent at all - utilities have not been updated yet). Lets fix it
> ASAP, preferably in 2.6.13.
Yes,
Hello Matt,
> > I'm guessing that it was you that added the RLIMIT_NICE resource
> > limit in 2.6.12.
>
> The original patch was from Chris Wright, but I did most of the
> cheerleading for it.
Okay -- thanks for the pointer. There was no record of the
pach in the (incomplete-because-of-git-cha
* Matt Mackall <[EMAIL PROTECTED]> wrote:
> The other downside is, this obviously changes any existing configs
> actually using this by one nice level..
it's pretty harmless, and i doubt the use of this is all that wide (if
existent at all - utilities have not been updated yet). Lets fix it
A
On Thu, Jul 28, 2005 at 05:04:24PM +0200, Michael Kerrisk wrote:
> Hello Ingo,
>
> I'm guessing that it was you that added the RLIMIT_NICE resource
> limit in 2.6.12.
The original patch was from Chris Wright, but I did most of the
cheerleading for it.
> (A passing note to all kernel developers:
"Michael Kerrisk" <[EMAIL PROTECTED]> wrote:
>
> (A passing note to all kernel developers: when
> making changes that affect userland-kernel interfaces, please
> send me a man-pages patch, or at least a notification of the
> change, so that some information makes its way into the manual
> p
Hello Ingo,
I'm guessing that it was you that added the RLIMIT_NICE resource
limit in 2.6.12. (A passing note to all kernel developers: when
making changes that affect userland-kernel interfaces, please
send me a man-pages patch, or at least a notification of the
change, so that some informat
13 matches
Mail list logo
