rpc.statd
Jun 6 18:48:10 www rpc.statd: invalid hostname to sm_stat: ^X^X^Z ^Z%8x%8x%8x%8x%8x%8x%8x%8x%8x%62716x%hn%51859x%hnM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM- ^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM -^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^P M-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^ PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM- ^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM -^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^P M-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^ PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM- ^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^P this is a message in messages before a kernel paniced on freebsd 4.3. I have token liberty of disabling, what does this look like to you guys. -- Dan +--+ | BRAVENET WEB SERVICES | | [EMAIL PROTECTED] | | screen;cd /usr/src;make buildworld;cd ~ | | cp MYKERNEL /sys/i386/conf;cd /usr/src | |make buildkernel KERNCONF=MYKERNEL| |make installkernel KERNCONF=MYKERNEL;make installworld| +__+ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: rpc.statd
On Wed, 6 Jun 2001, Dan Phoenix wrote: > > Jun 6 18:48:10 www rpc.statd: invalid hostname to > sm_stat: ^X^X^Z > >^Z%8x%8x%8x%8x%8x%8x%8x%8x%8x%62716x%hn%51859x%hnM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM- [ snip ] It's some l33t h4x0r attemting to use a Linux RPC exploit against your FreeBSD machine. From what I've been told, It's harmless (since FreeBSD never had the hole that Linux did), and I see it quite often on some of the public boxes that I run. Are you absolutely sure that this was the cause of your kernel panic? -- Matt Emmerton GSI Computer Services To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: rpc.statd
On Wed, Jun 06, 2001 at 09:39:39PM -0700, Dan Phoenix wrote: > > Jun 6 18:48:10 www rpc.statd: invalid hostname to > sm_stat: ^X^X^Z > >^Z%8x%8x%8x%8x%8x%8x%8x%8x%8x%62716x%hn%51859x%hnM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM- [snip] > > this is a message in messages before a kernel paniced on freebsd 4.3. > I have token liberty of disabling, what does this look like to you guys. As already pointed out, this should definitely not be the cause of a kernel panic. This is, exactly as the other poster explained, a Linux-targeting expoit which has absolutely no effect on FreeBSD's rpc.statd. G'luck, Peter -- If I had finished this sentence, To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
weird rpc.statd memory behavior
On a RELENG_4 machine with the world rebuilt on Sep 27, 'top' gave me the following output after sorting by the 'SIZE' field.. last pid: 424; load averages: 0.17, 0.15, 0.10up 0+00:29:43 15:39:23 46 processes: 1 running, 45 sleeping CPU states: 4.7% user, 0.0% nice, 1.2% system, 3.1% interrupt, 91.1% idle Mem: 19M Active, 202M Inact, 40M Wired, 80K Cache, 61M Buf, 240M Free Swap: 512M Total, 512M Free PID USERNAME PRI NICE SIZERES STATETIME WCPUCPU COMMAND 125 root 2 0 257M 560K select 0:00 0.00% 0.00% rpc.statd 244 mysql -2 0 12180K 11172K getblk 1:14 5.47% 5.47% mysqld 411 root 2 0 2116K 1580K select 0:00 0.00% 0.00% sshd 269 root 2 0 2116K 1580K select 0:00 0.00% 0.00% sshd [snip more processes] Aall right then.. what's the deal? :) Yes, I know that those 257 megabytes are not *really* used, allocated, hogged and so on.. but why does statd ask for so much? :) And that's just 29 minutes after a reboot :) G'luck, Peter -- Hey, out there - is it *you* reading me, or is it someone else? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: weird rpc.statd memory behavior
On Fri, Oct 06, 2000 at 03:43:59PM +0300, Peter Pentchev wrote: > On a RELENG_4 machine with the world rebuilt on Sep 27, 'top' gave me > the following output after sorting by the 'SIZE' field.. > > last pid: 424; load averages: 0.17, 0.15, 0.10up 0+00:29:43 15:39:23 > 46 processes: 1 running, 45 sleeping > CPU states: 4.7% user, 0.0% nice, 1.2% system, 3.1% interrupt, 91.1% idle > Mem: 19M Active, 202M Inact, 40M Wired, 80K Cache, 61M Buf, 240M Free > Swap: 512M Total, 512M Free > > PID USERNAME PRI NICE SIZERES STATETIME WCPUCPU COMMAND > 125 root 2 0 257M 560K select 0:00 0.00% 0.00% rpc.statd > 244 mysql -2 0 12180K 11172K getblk 1:14 5.47% 5.47% mysqld > 411 root 2 0 2116K 1580K select 0:00 0.00% 0.00% sshd > 269 root 2 0 2116K 1580K select 0:00 0.00% 0.00% sshd > [snip more processes] > > Aall right then.. what's the deal? :) Yes, I know that those 257 > megabytes are not *really* used, allocated, hogged and so on.. but why > does statd ask for so much? :) And that's just 29 minutes after a reboot :) Use The Source Luke. Taking a quick look at the source memory is only allocated in two places. On malloc which doesn't account for this and one f*ing hugh mmap of a file in /var to allow for extension of the file. The code in -current mmaps 0x1000 bytes of address space or exactly 256MB. This is compleatly harmless as it not only doesn't use any real memory, but since it's mmaping a file in /var it doesn't use any swap either. Check it out for your self at: /usr/src/usr.sbin/rpc.statd -- Brooks -- Any statement of the form "X is the one, true Y" is FALSE. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Problems with rpc.statd and PAE
Hi,
Sent this to -questions, but got no answer. Now I'll try -hackers...
I've just configured my first server with 4G RAM. To use it, I had
to select PAE in kernel config. I was a little bit troubled by it's
advice not to use modules (is it that critical?), but got it running.
But when it is running on PAE, NFS statd refuses to run:
# /etc/rc.d/nfslocking start
Starting statd.
rpc.statd: unable to mmap() status file: Cannot allocate memory
Segmentation fault
#
Using strace I found it was trying to mmap the status file, at
/var/db/statd.status:
open("/var/db/statd.status", O_RDWR)= 10
mmap(0, 268435456, PROT_READ|PROT_WRITE, MAP_SHARED, 10, 0) = -1 ENOMEM
(Cannot allocate memory)
It's really strange to have mmap len = 256M, specially because the
file is always small. But it works without PAE, and do not work with
PAE. And it is described in the handbook:
http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/book.html#STATD-MEM-LEAK
Also, I tought PAE was only needed when we had MORE than 4G. But
without PAE the system shows only 3.5G:
- Without PAE:
Jul 25 16:34:41 zeus kernel: real memory = 3757965312 (3583 MB)
Jul 25 16:34:41 zeus kernel: avail memory = 3678429184 (3508 MB)
- With PAE:
Jul 25 17:09:01 zeus kernel: real memory = 4831838208 (4608 MB)
Jul 25 17:09:01 zeus kernel: avail memory = 4193112064 (3998 MB)
If I could use the whole 4G, or at least lose less than 512M, I'd
prefer to stay off PAE.
Any help you could give me?
TIA,
Jonny
PS: sources fully updated to 6-RELENG from last week.
--
João Carlos Mendes Luís - Networking Engineer - [EMAIL PROTECTED]
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Problems with rpc.statd and PAE
João Carlos Mendes Luís <[EMAIL PROTECTED]> writes: >Also, I tought PAE was only needed when we had MORE than 4G. But > without PAE the system shows only 3.5G. Without PAE, the address space is only 32 bits (4 GB), 512 MB of which are reserved for PCI devices. With PAE, the address space is 36 bits (64 GB) which is more than room enough for your 4 GB of RAM *plus* the PCI configuration and MMIO space. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Problems with rpc.statd and PAE
On 31 Jul, João Carlos Mendes Luís wrote:
> Hi,
>
> Sent this to -questions, but got no answer. Now I'll try -hackers...
>
> I've just configured my first server with 4G RAM. To use it, I had
> to select PAE in kernel config. I was a little bit troubled by it's
> advice not to use modules (is it that critical?), but got it running.
>
> But when it is running on PAE, NFS statd refuses to run:
>
> # /etc/rc.d/nfslocking start
> Starting statd.
> rpc.statd: unable to mmap() status file: Cannot allocate memory
> Segmentation fault
> #
>
> Using strace I found it was trying to mmap the status file, at
> /var/db/statd.status:
>
> open("/var/db/statd.status", O_RDWR)= 10
> mmap(0, 268435456, PROT_READ|PROT_WRITE, MAP_SHARED, 10, 0) = -1 ENOMEM
> (Cannot allocate memory)
>
> It's really strange to have mmap len = 256M, specially because the
> file is always small. But it works without PAE, and do not work with
> PAE. And it is described in the handbook:
>
> http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/book.html#STATD-MEM-LEAK
I've been seeing this same problem for a long time on an 7.0-CURRENT
i386 machine with 1GB of RAM, and I'm not using PAE. I haven't
discovered any obvious cause for the problem.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Problems with rpc.statd and PAE
Don Lewis wrote:
On 31 Jul, João Carlos Mendes Luís wrote:
Hi,
Sent this to -questions, but got no answer. Now I'll try -hackers...
I've just configured my first server with 4G RAM. To use it, I had
to select PAE in kernel config. I was a little bit troubled by it's
advice not to use modules (is it that critical?), but got it running.
But when it is running on PAE, NFS statd refuses to run:
# /etc/rc.d/nfslocking start
Starting statd.
rpc.statd: unable to mmap() status file: Cannot allocate memory
Segmentation fault
#
Using strace I found it was trying to mmap the status file, at
/var/db/statd.status:
open("/var/db/statd.status", O_RDWR)= 10
mmap(0, 268435456, PROT_READ|PROT_WRITE, MAP_SHARED, 10, 0) = -1 ENOMEM
(Cannot allocate memory)
It's really strange to have mmap len = 256M, specially because the
file is always small. But it works without PAE, and do not work with
PAE. And it is described in the handbook:
http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/book.html#STATD-MEM-LEAK
I've been seeing this same problem for a long time on an 7.0-CURRENT
i386 machine with 1GB of RAM, and I'm not using PAE. I haven't
discovered any obvious cause for the problem.
It's a production file server, so I cannot make any test today, but this
weekend I'll try to recompile statd to use less memory.
Is there a good reason to map 256M at once?
Jonny
--
João Carlos Mendes Luís - Networking Engineer - [EMAIL PROTECTED]
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Problems with rpc.statd and PAE
João Carlos Mendes Luís wrote: > Don Lewis wrote: > > I've been seeing this same problem for a long time on an 7.0-CURRENT > > i386 machine with 1GB of RAM, and I'm not using PAE. I haven't > > discovered any obvious cause for the problem. > > It's a production file server, so I cannot make any test today, but this > weekend I'll try to recompile statd to use less memory. > > Is there a good reason to map 256M at once? Is there a good reason _not_ to do it? rpc.statd has always mapped 256M, for as long as FreeBSD exists (maybe longer). I've never had a proble with that. Obviously it does that because it makes managing the state data easier. That's enough of a good reason, I think. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "File names are infinite in length, where infinity is set to 255 characters." -- Peter Collinson, "The Unix File System" ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
