Today Vivek Khera wrote:
> > "MH" == Matt Heckaman <[EMAIL PROTECTED]> writes:
>
> MH> I do not know if "should" would be the word I would choose, however it
> MH> fits the situation well. Personally, I cvsup ports every night, but I'm
> MH> a little bit over-obsessed with things being "new"
Beware of per-user limits. You don't mention what user you ran "limit"
as, or what user the news server process runs as. Each could have very
different limits. See /etc/login.conf. It might even depend on how the
server server process is started. Processes started at boot run under the
"daem
I call cvsup from crontab, with a line like this:
0 8 * * * root cvsup -g -L 2 /usr/local/etc/cvsup/ports-supfile \
| mail -s "epsilon.lucida.qc.ca: ports update output" admin
(formatted so it would read right in email)
The output from cvsup only shows what it's changed, so it's very handy for
Brad Knowles wrote:
>
>
> Unfortunately, none of this seems to be related to my problem of
> having the error message described, or how I can eliminate this error
> message.
>
housley@cat:~/work/monitors {34} sysctl -a | grep -i file
kern.maxfiles: 2088
kern.bootfile: /kernel
kern.maxfi
At 8:12 AM -0800 2000/2/29, Tom wrote:
> Beware of per-user limits. You don't mention what user you ran "limit"
> as, or what user the news server process runs as. Each could have very
> different limits. See /etc/login.conf. It might even depend on how the
> server server process is star
James Housley stated:
> Brad Knowles wrote:
> >
> >
> > Unfortunately, none of this seems to be related to my problem of
> > having the error message described, or how I can eliminate this error
> > message.
> >
> housley@cat:~/work/monitors {34} sysctl -a | grep -i file
> kern.maxfiles
> "SO" == Sean O'Connell <[EMAIL PROTECTED]> writes:
SO> I thought this too, but if I run
SO> sysctl -w kern.maxfiles=4096
SO> sysctl -w kern.maxfilesperproc=4096
SO> Now:
SO> % sysctl kern.maxfiles
SO> kern.maxfiles: 4096
SO> % sysctl kern.maxfilesperproc
SO> kern.maxfilesperproc: 4096
S
Sean O'Connell wrote:
>
> % sysctl kern.maxfiles
> kern.maxfiles: 4096
> % sysctl kern.maxfilesperproc
> kern.maxfilesperproc: 4096
>
> However, limit -h (tcsh builtin) and limits -H still report
>
> descriptors 2088
> openfiles2088
>
> respectively.
>
> Even the manpage for s
Sean O'Connell wrote:
> kern.maxfilesperprocinteger yes
>
> Am I missing something obvious? Are these values really updated?
>
Logout and back in the shell probably gets the value when spawned/login.
And if that fixes it you will need to either kill -1 your problem
prog
Vivek Khera stated:
> > "SO" == Sean O'Connell <[EMAIL PROTECTED]> writes:
>
> SO> I thought this too, but if I run
>
> SO> sysctl -w kern.maxfiles=4096
> SO> sysctl -w kern.maxfilesperproc=4096
>
> SO> Now:
>
> SO> % sysctl kern.maxfiles
> SO> kern.maxfiles: 4096
> SO> % sysctl kern.maxfi
At 11:34 AM -0500 2000/2/29, Sean O'Connell wrote:
> % sysctl kern.maxfiles
> kern.maxfiles: 4096
> % sysctl kern.maxfilesperproc
> kern.maxfilesperproc: 4096
>
> However, limit -h (tcsh builtin) and limits -H still report
>
> descriptors 2088
> openfiles2088
Have
At 11:16 AM -0500 2000/2/29, James Housley wrote:
> housley@cat:~/work/monitors {34} sysctl -a | grep -i file
Any my results:
$ sysctl -a | grep -i file
kern.maxfiles: 32768
kern.bootfile: /kernel
kern.maxfilesperproc: 16384
kern.corefile: %N.core
p1003_1b.mapped_files: 0
> It looks
At 11:46 AM -0500 2000/2/29, Sean O'Connell wrote:
> So for the matter at hand, I would suppose that stopping and restarting
> innd would be all that is needed.
My problem is with Diablo (not innd), and I've already stopped
and restarted it several times. No change.
Anyone
At 11:46 AM -0500 2000/2/29, Sean O'Connell wrote:
> So for the matter at hand, I would suppose that stopping and restarting
> innd would be all that is needed.
Sigh The problem turns out to have been a hard-coded limit
in Diablo. I've recompiled/stopped/restarted and I'll wait
14 matches
Mail list logo
