@MSGID: 1@dont-email.me> d65de3db
@REPLY: 1@dont-email.me> cec2f639
@REPLYADDR Kalevi Kolttonen <kalevi@kolttonen.fi>
@REPLYTO 2:5075/128 Kalevi Kolttonen
@CHRS: CP866 2
@RFC: 1 0
@RFC-Message-ID: 1@dont-email.me>
@RFC-References: 1@news.xmission.com>
1@dont-email.me> mPI2.444965@fx15.iad> 1@dont-email.me>
1@dont-email.me>
@TZUTC: -0000
@PID: tin/2.6.2-20221225 ("Pittyvaich")
(Linux/6.4.12-200.fc38.x86_64 (x86_64))
@TID: FIDOGATE-5.12-ge4e8b94
Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:
> I would disagree; Scott`s point is quite relevant to Kenny`s
> (very information free) quesion.
> 
> More specifically, Kenny only mentioned the values obtained
> (31411 and 6807), and asked "What is going on?" Each of those
> two values occur in two places: the "curr" limit and the "max"
> limit. While others have discussed how the "max" limit is
> derived, no one (other than Scott) has mentioned how the "curr"
> limit may (or may not) have been set.

Yes, I already posted a new message telling that this
information *could* indeed be relevant in Kenny`s case. 

But it was not really relevant to my Fedora 38. The values
were not set there, but came from the Linux kernel based
on the amount of available RAM.

So I cannot know for the certain whether Kenny`s values
came from the PAM configuration files or from the Linux
kernel, but I suspect the latter.

br,
KK
--- tin/2.6.2-20221225 ("Pittyvaich") (Linux/6.4.12-200.fc38.x86_64 (x86_64))
 * Origin: A noiseless patient Spider (2:5075/128)
SEEN-BY: 5001/100 5005/49 5010/352 5015/255 5019/40
5020/715 848 1042 4441
SEEN-BY: 5020/12000 5030/49 1081 5075/128
@PATH: 5075/128 5020/1042 4441