Re: Superpages on amd64 FreeBSD 7.2-STABLE
There's a bunch of other random crap that may be going on relating to the helper processes (eg rewriters, auth, etc) which may also be restarted. Anyway. The thread is about superpage demotion and copying, not what Squid is or isn't doing in her configuration. :) Adrian 2009/11/27 Daniel O'Connor : > On Fri, 27 Nov 2009, krad wrote: >> Im sure you will get a lot of lovely answers to this but best keep >> things simple. WHy not just syslog it of to another server and >> offload all the compression to that box. You could even back it with >> zfs nad do on the fly gzip compression at the file system level, or >> use syslog-ng to do it. If you are worried about zfs and bsd use >> (open)*solaris or another filesystem with with inline compression > > Or send squids logs to a small buffer process which you then HUP when > rotating logs. > > Also, I don't really understand why squid would fork when you tell it to > rotate, seems like a design defect. > > -- > Daniel O'Connor software and network engineer > for Genesis Software - http://www.gsoft.com.au > "The nice thing about standards is that there > are so many of them to choose from." > -- Andrew Tanenbaum > GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C > ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Workaround for ntop as daemon, is it ok?
Hi,
I have just set up an ntop server based on 8.0-RELEASE.
FreeBSD ntop 8.0-RELEASE FreeBSD 8.0-RELEASE #0: Sat Nov 21 15:48:17 UTC 2009
r...@almeida.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386
After installing ntop 1.3.10 and all dependencies from the ports ntop
did work, but when running ntop as a daemon I got permanent and repeating
warning messages:
[warn] kevent: Bad file descriptor
ktrace reported the following:
47944 100098 initial thread CALL kevent(0x5,0x29ed8700,0x1,0x29ed8c00,
0x40,0)
47944 100098 initial thread RET kevent 1
47945 100139 ntop CALL kevent(0x5,0x29ed8700,0x3,0x29ed8c00,0x40,
0xbfbfd8a4)
47945 100139 ntop RET kevent -1 errno 9 Bad file descriptor
"[warn] kevent: Bad file descriptor
I found out that ntop forks another thread for the daemon and kills the
initial one. The problem with this behaviour is that the kqueue is
started by the initial thread and the daemon thread doesn't use the
same file descriptors. So the kqueue is lost.
This is ntop running in foreground (note fd 5, this is the kqueue):
PID COMM FD T V FLAGSREF OFFSET PRO NAME
48884 ntop cwd v d - - -
/usr/ports/net/ntop/work/ntop-3.3.10
48884 ntop root v d - - - /
48884 ntop0 v c rw-- 12 421416 - /dev/pts/1
48884 ntop1 v c rw-- 12 421416 - /dev/pts/1
48884 ntop2 v c rw-- 12 421416 - /dev/pts/1
48884 ntop3 v r rw-l 1 12646 -
/var/db/ntop/prefsCache.db
48884 ntop4 v r rw-l 1 12557 -
/var/db/ntop/ntop_pw.db
48884 ntop5 k - rw-- 1 0 - -
48884 ntop6 v c rw-- 2 35673 - /dev/bpf
48884 ntop7 s - rw---n-- 2 0 UDP 0.0.0.0:30903
0.0.0.0:0
48884 ntop8 s - rw---n-- 2 0 UDP 0.0.0.0:56316
0.0.0.0:0
48884 ntop9 s - rw---n-- 2 0 UDP 0.0.0.0:56311
0.0.0.0:0
48884 ntop 10 v r rw-l 1 13782 -
/var/db/ntop/dnsCache.db
48884 ntop 11 v r rw-l 1 652448 -
/var/db/ntop/macPrefix.db
48884 ntop 12 v r rw-l 1 167936 -
/var/db/ntop/fingerprint.db
48884 ntop 13 v r r--- 1 24903680 -
/usr/local/etc/ntop/GeoLiteCity.dat
48884 ntop 14 v r r--- 1 1601536 -
/usr/local/etc/ntop/GeoIPASNum.dat
48884 ntop 15 s - rw-- 1 0 TCP 0.0.0.0:3000
0.0.0.0:0
48884 ntop 17 v r rw-l 18192 -
/var/db/ntop/LsWatch.db
And this is ntop running in background:
PID COMM FD T V FLAGSREF OFFSET PRO NAME
48842 ntop cwd v d - - - /
48842 ntop root v d - - - /
48842 ntop0 v r r--- 1 24903680 -
/usr/local/etc/ntop/GeoLiteCity.dat
48842 ntop1 v r r--- 1 1601536 -
/usr/local/etc/ntop/GeoIPASNum.dat
48842 ntop2 v c rw-- 11 413845 - /dev/pts/1
48842 ntop3 v r rw-l 1 12646 -
/var/db/ntop/prefsCache.db
48842 ntop4 v r rw-l 1 12557 -
/var/db/ntop/ntop_pw.db
48842 ntop5 s - rw-- 1 0 TCP 0.0.0.0:3000
0.0.0.0:0
48842 ntop6 v c rw-- 2 32705 - /dev/bpf
48842 ntop7 s - rw---n-- 1 0 UDP 0.0.0.0:48169
0.0.0.0:0
48842 ntop8 s - rw---n-- 1 0 UDP 0.0.0.0:36849
0.0.0.0:0
48842 ntop9 s - rw---n-- 1 0 UDP 0.0.0.0:64119
0.0.0.0:0
48842 ntop 10 v r rw-l 1 13284 -
/var/db/ntop/dnsCache.db
48842 ntop 11 v r rw-l 1 499464 -
/var/db/ntop/macPrefix.db
48842 ntop 12 v r rw-l 1 167936 -
/var/db/ntop/fingerprint.db
48842 ntop 14 v r rw-l 18192 -
/var/db/ntop/LsWatch.db
After further investiagations I found the function which is responsible
for the fork at line 172 of ntop.c.
/* */
void daemonizeUnderUnix(void) {
#ifndef WIN32
int childpid;
signal(SIGHUP, SIG_IGN);
#ifdef HANDLE_DIED_CHILD
signal(SIGCHLD, handleDiedChild);
#else
signal(SIGCHLD, SIG_IGN);
#endif
signal(SIGQUIT, SIG_IGN);
if((childpid=fork()) < 0)
traceEvent(CONST_TRACE_ERROR, "INIT: Occurred while daemonizing
(errno=%d)", errno);
else {
#ifdef DEBUG
traceEvent(CONST_TRACE_INFO, "DEBUG: after fork() in %s (%d)",
childpid ? "parent" : "child", childpid);
#endif
if(!childpid) { /* child */
traceEvent(CONST_TRACE_INFO, "INIT: Bye bye: I'm becoming a daemon...")
Re: zero size set_pcpu linker sets
On Tue, 24 Nov 2009, Navdeep Parhar wrote: Hi, objdump -h shows that most, but not all, KLDs on amd64 have a "set_pcpu" section of size 0. Why? What is the difference between having a 0 sized set_pcpu vs. not having it at all? The kernel linker considers the alignment requirements of these empty sections and advances mapsize/mapbase. This bothers my kgdb (which is slightly modified to deal with amd64 KLDs). So what's your real problem? I'm using the patch shown here as a stopgap measure. I think the correct fix is to not have these empty sections in the KLD to begin with. Right. The problem here is a bug with ld and linker sets and size and aligment calculations the the elf section is started when not all of this is known correctly and it's not fixed later. This came up with that "netisr" bug where we had seen the misalignment of the dpcpu set. /bz -- Bjoern A. Zeeb It will not break if you know what you are doing. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Superpages on amd64 FreeBSD 7.2-STABLE
On Fri, 27 Nov 2009, Adrian Chadd wrote: > There's a bunch of other random crap that may be going on relating to > the helper processes (eg rewriters, auth, etc) which may also be > restarted. OK. > Anyway. The thread is about superpage demotion and copying, not what > Squid is or isn't doing in her configuration. :) Yeah I understand that but if you can avoid the huge problem with a deft rearrangement that may help your production environment and give you more time for a real solution :) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C signature.asc Description: This is a digitally signed message part.
ucred when euid/egid
Hello, I face some misunderstood situation related to the access permissions. There is a program(script) with the suid/sgid (mode 6555): r-sr-sr-x fuser:proggroup theprog There is a file: rw-rw someone:filegroupthefile User 'fuser' (==program euid) have primary group 'filegroup'(==group, who can read/write thefile). Program try to read(write) thefile and fail with permissions. I don't fully understand why. According VOP_ACCESS(9) there is a check /* Otherwise, check the groups. */ for (i = 0, gp = cred->cr_groups; i < cred->cr_ngroups; i++, gp++) ... So, i have only one assumption: when seteuided program executed ucred struct and cred->cr_groups doesn't change accordingly to euid/egid and stay the same as for executor. Is this a bug (how can i fix it) or feature (how can i bypass it)? -- Best regards, Anthony mailto:a...@mail.ru ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Workaround for ntop as daemon, is it ok?
On Fri, Nov 27, 2009 at 09:19:11AM +0100, Henner Morten Kruse wrote: > I have just set up an ntop server based on 8.0-RELEASE. > FreeBSD ntop 8.0-RELEASE FreeBSD 8.0-RELEASE #0: Sat Nov 21 15:48:17 UTC 2009 > r...@almeida.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 > After installing ntop 1.3.10 and all dependencies from the ports ntop > did work, but when running ntop as a daemon I got permanent and repeating > warning messages: > [warn] kevent: Bad file descriptor > [...] > I found out that ntop forks another thread for the daemon and kills the > initial one. The problem with this behaviour is that the kqueue is > started by the initial thread and the daemon thread doesn't use the > same file descriptors. So the kqueue is lost. That's a process, not a thread. > [...] > When I change the fork() in line 186 to rfork(RFPROC) everything works > and I get no more warning messages and procstat reports an existing > kqueue for the daemonized ntop: > So my question to this is: > Is my workaround ok or could this cause any problems? And what is the cause > of these warnings? Is it a bug or incapability in the kqueue implementation > or is it caused by bad code in ntop? Because it refers to other file descriptors, a kqueue is only really meaningful in the file descriptor table it was created in (this could be avoided for events that do not refer to file descriptors, and I think Solaris's "ports" system does that). As described in the kqueue(2) man page, calling rfork(2) without RFFDG will allow sharing the kqueue between the two processes. As long as the parent process exits quickly, or no "tricks" with file descriptor numbers are done, this is pretty safe. Another fix is to create the kqueue in the child process. -- Jilles Tjoelker ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: zero size set_pcpu linker sets
On Fri, Nov 27, 2009 at 08:51:41AM +, Bjoern A. Zeeb wrote: > On Tue, 24 Nov 2009, Navdeep Parhar wrote: > > Hi, > > >objdump -h shows that most, but not all, KLDs on amd64 have a "set_pcpu" > >section of size 0. Why? What is the difference between having a 0 > >sized set_pcpu vs. not having it at all? > > > >The kernel linker considers the alignment requirements of these empty > >sections and advances mapsize/mapbase. This bothers my kgdb (which is > >slightly modified to deal with amd64 KLDs). > > So what's your real problem? > I'm trying to read a KLD's globals etc. from its .bss and .data from within kgdb. It has a problem on amd64 that was discussed a long time back: http://lists.freebsd.org/pipermail/freebsd-hackers/2008-September/026014.html The workaround I was using failed after the appearance of set_pcpu, and that made me look at the object file and the kernel linker code. I think there are two minor problems: a) There is an empty set_pcpu in the KLD when it shouldn't be there. b) The kernel linker doesn't ignore this section even though it's empty. It ends up advancing its location calculations because of the way it considers alignment requirements, even for empty sections. > > >I'm using the patch shown here as a stopgap measure. I think the correct > >fix is to not have these empty sections in the KLD to begin with. > > Right. The problem here is a bug with ld and linker sets and size and > aligment calculations the the elf section is started when not all of > this is known correctly and it's not fixed later. This came up with > that "netisr" bug where we had seen the misalignment of the dpcpu set. Yes, I remember that bug, and some of the changes that went in to fix it. Do you know why this empty set_pcpu shows up in most, but not all KLDs? I was hoping we could remove it from all the ones that don't really have any PCPU data. Regards, Navdeep ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
heap limits: mmap(2) vs. break(2) on i386
Hi, I am trying to figure out why java fails to start with 1024MB of heap on i386 with 4GB of RAM and 4GB of swap. Both MAXDSIZ and DFLDSIZ are set to 2GB. Here is my limits: Resource limits (current): cputime infinity secs filesize infinity kB datasize 2097152 kB stacksize 65536 kB coredumpsize infinity kB memoryuseinfinity kB memorylocked infinity kB maxprocesses 5547 openfiles 2 sbsize infinity bytes vmemoryuse infinity kB Running ktrace I see: 9154 java CALL mmap(0,0x4400,PROT_READ|PROT_WRITE|PROT_EXEC,MAP_PRIVATE|MAP_NORESERVE|MAP_ANON,0x,0,0) 9154 java RET mmap -1 errno 12 Cannot allocate memory 9154 java CALL write(0x1,0xbf9fe378,0x2b) 9154 java GIO fd 1 wrote 43 bytes "Error occurred during initialization of VM I made a small program that uses malloc(3) to allocate the same amount of memory, and that works nicely, ktrace reveals why: 10108 a.outCALL mmap(0,0x4400,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,0x,0,0) 10108 a.outRET mmap -1 errno 12 Cannot allocate memory 10108 a.outCALL break(0x4c10) 10108 a.outRET break 0 So the question is: why does mmap() fails while essentially the same sbrk() request succeeds? This is really bad since, while native FreeBSD programs can work around this by using malloc(3), Linux programs and software that knows nothing about intricate details of the FreeBSD VM (i.e. Java) will fail miserably. I tried increasing vm.max_proc_mmap to 2147483647 from default 49344, but it did not do any good. mmap() still fails with the request of this size. I have seen several threads on the issue over the years, but still no resolution. It seems that only plausible solution is to limit heap size in java, which may not work for all cases. Funny thing is that the first sentence of the sbrk(2) manual page says: The brk() and sbrk() functions are legacy interfaces from before the advent of modern virtual memory management. Yet, "legacy interfaces" seems to do much better job than "modern virtual memory management interfaces"! -Maxim ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: heap limits: mmap(2) vs. break(2) on i386
Maxim Sobolev wrote: I am trying to figure out why java fails to start with 1024MB of heap on i386 with 4GB of RAM and 4GB of swap. Both MAXDSIZ and DFLDSIZ are set to 2GB. Some memory (1GiB?) is reserved for kernel address space, and you reserved 2GiB for DSS. That leaves less than 1GiB available after shared libraries and whatnot are mapped. If there is more than 1GiB available, mmap can still fail due to the memory being non-contiguous. Jason ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: heap limits: mmap(2) vs. break(2) on i386
Jason Evans wrote: Maxim Sobolev wrote: I am trying to figure out why java fails to start with 1024MB of heap on i386 with 4GB of RAM and 4GB of swap. Both MAXDSIZ and DFLDSIZ are set to 2GB. Some memory (1GiB?) is reserved for kernel address space, and you reserved 2GiB for DSS. That leaves less than 1GiB available after shared libraries and whatnot are mapped. If there is more than 1GiB available, mmap can still fail due to the memory being non-contiguous. Jason, So, are you saying that by allocating 2GB to MAXDSIZ, I limit myself less than 1GB left to be allocated via mmap()? Perhaps the cause of the problem is my interpretation of MAXDSIZ as an overall limit of VM that the process will be able to allocate regardless of the memory management interface is wrong, and in fact the process can allocate up to MAXDSIZ using sbrk(2) and then some extra using mmap(2) up to 3GB? I tried lowering DFLDSIZ to 1.5GB, and it helped with Java. What is the best strategy if I want to maximize amount of memory available to applications? Most of modern applications use mmap(), isn't it? Then where MAXDSIZ can bite me if I set it to say 512MB? -Maxim ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: heap limits: mmap(2) vs. break(2) on i386
Maxim Sobolev wrote: Jason Evans wrote: Maxim Sobolev wrote: I am trying to figure out why java fails to start with 1024MB of heap on i386 with 4GB of RAM and 4GB of swap. Both MAXDSIZ and DFLDSIZ are set to 2GB. Some memory (1GiB?) is reserved for kernel address space, and you reserved 2GiB for DSS. That leaves less than 1GiB available after shared libraries and whatnot are mapped. If there is more than 1GiB available, mmap can still fail due to the memory being non-contiguous. So, are you saying that by allocating 2GB to MAXDSIZ, I limit myself less than 1GB left to be allocated via mmap()? Yes, my recollection is that MAXDSIZ controls the amount of virtual address space dedicated to DSS, and this address space will not be mapped via anonymous mmap. I wanted to move completely away from using sbrk in malloc, but we can't completely remove DSS for backward compatibility reasons, which means less heap address space than would be ideal. What is the best strategy if I want to maximize amount of memory available to applications? Most of modern applications use mmap(), isn't it? Then where MAXDSIZ can bite me if I set it to say 512MB? I would set MAXDSIZ to 0, so that the maximum amount of memory is available for mapping shared libraries and files, and allocating via malloc. This may cause problems with a couple of ports that implement their own memory allocators based on sbrk, but otherwise it should be all good. You might also set /etc/malloc.conf to 'd' in order to disable the sbrk calls. Jason ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: heap limits: mmap(2) vs. break(2) on i386
Jason Evans wrote: Maxim Sobolev wrote: Jason Evans wrote: Maxim Sobolev wrote: I am trying to figure out why java fails to start with 1024MB of heap on i386 with 4GB of RAM and 4GB of swap. Both MAXDSIZ and DFLDSIZ are set to 2GB. Some memory (1GiB?) is reserved for kernel address space, and you reserved 2GiB for DSS. That leaves less than 1GiB available after shared libraries and whatnot are mapped. If there is more than 1GiB available, mmap can still fail due to the memory being non-contiguous. So, are you saying that by allocating 2GB to MAXDSIZ, I limit myself less than 1GB left to be allocated via mmap()? Yes, my recollection is that MAXDSIZ controls the amount of virtual address space dedicated to DSS, and this address space will not be mapped via anonymous mmap. I wanted to move completely away from using sbrk in malloc, but we can't completely remove DSS for backward compatibility reasons, which means less heap address space than would be ideal. What is the best strategy if I want to maximize amount of memory available to applications? Most of modern applications use mmap(), isn't it? Then where MAXDSIZ can bite me if I set it to say 512MB? I would set MAXDSIZ to 0, so that the maximum amount of memory is available for mapping shared libraries and files, and allocating via malloc. This may cause problems with a couple of ports that implement their own memory allocators based on sbrk, but otherwise it should be all good. You might also set /etc/malloc.conf to 'd' in order to disable the sbrk calls. I see, thank you for the explanation. One of the problem that we are having is that we use a lot of interpreted languages in our environment (python, php etc), and most of those implement their own memory allocators, some of which rely on sbrk(2) unfortunately. I believe that's where that 2GB limit of ours comes from - one of our Python applications is very memory hungry and we had to bump that limit to allow it sufficient room. Crazy idea, perhaps, but has anyone considered wrapping up sbrk(2) into mmap(2), so that there is only one memory pool to draw from? Switch to 64-bit certainly helps, however there are lot of 32-bit machines hanging around and we will see them for a while in the embedded space. Certainly current situation with two separate sources of heap memory is not normal. -Maxim ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
