Re: Nagios and threads
On 6/20/05, Charles Sprickman [EMAIL PROTECTED] wrote: Hello, Just curious if there's any regulars here who would like to help Ethan out: [snip] ... It happens when the main thread forks to execute an active check. On the second fork to create the grandchild, the grandchild is created by fork, but never returns from liblthread's fork wrapper, because it's stuck in __pthread_acquire(). Maybe some FreeBSD users can help out with this problem. IIRC, doing any significant work in a forked child of a multithreaded process is somewhat ill defined. From SusV3's description of fork() ... Consequently, to avoid errors, the child process may only execute async-signal-safe operations until such time as one of the exec functions is called. (This behaviour would extend to a grandchild.) A comment in libpthread/thr_kern.c refers to this, so I think there's at least some assumptions that the child won't be doing much before execing or exiting. (But Im sure one of the implementors will pipe up if I'm wrong :-)) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
(no subject)
Hi list I have an Intel Motherboard with a SRCS16 raid controller. According to amr(4), this controller should be supported. Unfortunately the 5.4 Install CD does not recognize the raid controller. Loading amr before booting does not help (results in the error message seen in the dmesg below). When booting normally, the amr module is not loaded. Now I have the following questions: Is this version of the Intel Controller not supported? If this is the case, is there a simple solution to get it recognized? (a quick glance at the amr code was not enough to enlighten me) Is there an easy way to setup gmirror with the install CD in case the controller does not work? (even when loaded the geom_mirror module, the gmirror tool does not know about the 'label' command) thanks Stefan dmesg: Copyright (c) 1992-2005 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.4-RELEASE #0: Sun May 8 10:21:06 UTC 2005 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC module_register: module amr/amrd already exists! Module amr/amrd failed to register: 17 module_register: module pci/amr already exists! Module pci/amr failed to register: 17 ACPI APIC Table: A M I OEMAPIC Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(TM) CPU 3.00GHz (2992.52-MHz 686-class CPU) Origin = GenuineIntel Id = 0xf41 Stepping = 1 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE real memory = 1073610752 (1023 MB) avail memory = 1036853248 (988 MB) ioapic0 Version 2.0 irqs 0-23 on motherboard ioapic1 Version 2.0 irqs 24-47 on motherboard ioapic2 Version 2.0 irqs 48-71 on motherboard npx0: math processor on motherboard npx0: INT 16 interface acpi0: A M I OEMRSDT on motherboard acpi0: Power Button (fixed) Timecounter ACPI-fast frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0x408-0x40b on acpi0 cpu0: ACPI CPU on acpi0 acpi_throttle0: ACPI CPU Throttling on cpu0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 pci0: unknown at device 0.1 (no driver attached) pci0: base peripheral at device 1.0 (no driver attached) pcib1: ACPI PCI-PCI bridge irq 16 at device 2.0 on pci0 pci1: ACPI PCI bus on pcib1 pcib2: ACPI PCI-PCI bridge at device 0.0 on pci1 pci2: ACPI PCI bus on pcib2 em0: Intel(R) PRO/1000 Network Connection, Version - 1.7.35 port 0xc880-0xc8bf mem 0xfce0-0xfce3,0xfcec-0xfced irq 24 at device 3.0 on pci2 em0: Ethernet address: 00:04:23:b7:6c:4c em0: Speed:N/A Duplex:N/A em1: Intel(R) PRO/1000 Network Connection, Version - 1.7.35 port 0xcc00-0xcc3f mem 0xfce8-0xfceb,0xfcee-0xfcef irq 27 at device 3.1 on pci2 em1: Ethernet address: 00:04:23:b7:6c:4d em1: Speed:N/A Duplex:N/A pci1: base peripheral, interrupt controller at device 0.1 (no driver attached) pcib3: ACPI PCI-PCI bridge at device 0.2 on pci1 pci3: ACPI PCI bus on pcib3 em2: Intel(R) PRO/1000 Network Connection, Version - 1.7.35 port 0xd880-0xd8bf mem 0xfcfa-0xfcfb irq 54 at device 4.0 on pci3 em2: Ethernet address: 00:0e:0c:4e:2f:d0 em2: Speed:N/A Duplex:N/A em3: Intel(R) PRO/1000 Network Connection, Version - 1.7.35 port 0xdc00-0xdc3f mem 0xfcfe-0xfcff irq 55 at device 4.1 on pci3 em3: Ethernet address: 00:0e:0c:4e:2f:d1 em3: Speed:N/A Duplex:N/A pci1: base peripheral, interrupt controller at device 0.3 (no driver attached) uhci0: Intel 82801EB (ICH5) USB controller USB-A port 0xb800-0xb81f irq 16 at device 29.0 on pci0 usb0: Intel 82801EB (ICH5) USB controller USB-A on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: Intel 82801EB (ICH5) USB controller USB-B port 0xb880-0xb89f irq 19 at device 29.1 on pci0 usb1: Intel 82801EB (ICH5) USB controller USB-B on uhci1 usb1: USB revision 1.0 uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhci2: Intel 82801EB (ICH5) USB controller USB-C port 0xbc00-0xbc1f irq 18 at device 29.2 on pci0 usb2: Intel 82801EB (ICH5) USB controller USB-C on uhci2 usb2: USB revision 1.0 uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered pci0: serial bus, USB at device 29.7 (no driver attached) pcib4: ACPI PCI-PCI bridge at device 30.0 on pci0 pci4: ACPI PCI bus on pcib4 pci4: display, VGA at device 12.0 (no driver attached) isab0: PCI-ISA bridge at device 31.0 on
Re: Nagios and threads
[snip] at least some assumptions that the child won't be doing much before execing or exiting. (But Im sure one of the The child process should be able to call any system calls it likes -without assuming that pthreads from the parent process have been copied over to the child process. I spose most implementations support that. regards -kamal Kamal R. Prasad UNIX systems consultant http://members.fortunecity.com/kamalp [EMAIL PROTECTED] In theory, there is no difference between theory and practice. In practice, there is. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: using vkbd device
Hello, I did some more testing with kbdmux. 1. I wait for the screen saver becoming active. 2. I press the control key. 3. All keys, I press after that, come as control keys, e.g. I press 'j' or 'J' and see a linefeed, I press 'I' and see a tab. 4. I wait a second time for the screen saver. 5. I press control. 6. The keys are ok now. Does syscons eat up the key but sets the state in kbdmux? Norbert ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Intel SRCS16 Was: (no subject)
apologies for the ommited subject Stefan Zitat von [EMAIL PROTECTED]: Hi list I have an Intel Motherboard with a SRCS16 raid controller. According to amr(4), this controller should be supported. Unfortunately the 5.4 Install CD does not recognize the raid controller. Loading amr before booting does not help (results in the error message seen in the dmesg below). When booting normally, the amr module is not loaded. Now I have the following questions: Is this version of the Intel Controller not supported? If this is the case, is there a simple solution to get it recognized? (a quick glance at the amr code was not enough to enlighten me) Is there an easy way to setup gmirror with the install CD in case the controller does not work? (even when loaded the geom_mirror module, the gmirror tool does not know about the 'label' command) thanks Stefan dmesg: Copyright (c) 1992-2005 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.4-RELEASE #0: Sun May 8 10:21:06 UTC 2005 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC module_register: module amr/amrd already exists! Module amr/amrd failed to register: 17 module_register: module pci/amr already exists! Module pci/amr failed to register: 17 ACPI APIC Table: A M I OEMAPIC Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(TM) CPU 3.00GHz (2992.52-MHz 686-class CPU) Origin = GenuineIntel Id = 0xf41 Stepping = 1 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE real memory = 1073610752 (1023 MB) avail memory = 1036853248 (988 MB) ioapic0 Version 2.0 irqs 0-23 on motherboard ioapic1 Version 2.0 irqs 24-47 on motherboard ioapic2 Version 2.0 irqs 48-71 on motherboard npx0: math processor on motherboard npx0: INT 16 interface acpi0: A M I OEMRSDT on motherboard acpi0: Power Button (fixed) Timecounter ACPI-fast frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0x408-0x40b on acpi0 cpu0: ACPI CPU on acpi0 acpi_throttle0: ACPI CPU Throttling on cpu0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 pci0: unknown at device 0.1 (no driver attached) pci0: base peripheral at device 1.0 (no driver attached) pcib1: ACPI PCI-PCI bridge irq 16 at device 2.0 on pci0 pci1: ACPI PCI bus on pcib1 pcib2: ACPI PCI-PCI bridge at device 0.0 on pci1 pci2: ACPI PCI bus on pcib2 em0: Intel(R) PRO/1000 Network Connection, Version - 1.7.35 port 0xc880-0xc8bf mem 0xfce0-0xfce3,0xfcec-0xfced irq 24 at device 3.0 on pci2 em0: Ethernet address: 00:04:23:b7:6c:4c em0: Speed:N/A Duplex:N/A em1: Intel(R) PRO/1000 Network Connection, Version - 1.7.35 port 0xcc00-0xcc3f mem 0xfce8-0xfceb,0xfcee-0xfcef irq 27 at device 3.1 on pci2 em1: Ethernet address: 00:04:23:b7:6c:4d em1: Speed:N/A Duplex:N/A pci1: base peripheral, interrupt controller at device 0.1 (no driver attached) pcib3: ACPI PCI-PCI bridge at device 0.2 on pci1 pci3: ACPI PCI bus on pcib3 em2: Intel(R) PRO/1000 Network Connection, Version - 1.7.35 port 0xd880-0xd8bf mem 0xfcfa-0xfcfb irq 54 at device 4.0 on pci3 em2: Ethernet address: 00:0e:0c:4e:2f:d0 em2: Speed:N/A Duplex:N/A em3: Intel(R) PRO/1000 Network Connection, Version - 1.7.35 port 0xdc00-0xdc3f mem 0xfcfe-0xfcff irq 55 at device 4.1 on pci3 em3: Ethernet address: 00:0e:0c:4e:2f:d1 em3: Speed:N/A Duplex:N/A pci1: base peripheral, interrupt controller at device 0.3 (no driver attached) uhci0: Intel 82801EB (ICH5) USB controller USB-A port 0xb800-0xb81f irq 16 at device 29.0 on pci0 usb0: Intel 82801EB (ICH5) USB controller USB-A on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: Intel 82801EB (ICH5) USB controller USB-B port 0xb880-0xb89f irq 19 at device 29.1 on pci0 usb1: Intel 82801EB (ICH5) USB controller USB-B on uhci1 usb1: USB revision 1.0 uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhci2: Intel 82801EB (ICH5) USB controller USB-C port 0xbc00-0xbc1f irq 18 at device 29.2 on pci0 usb2: Intel 82801EB (ICH5) USB controller USB-C on uhci2 usb2: USB revision 1.0 uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered pci0: serial bus, USB at device
RE: Nagios and threads
[snip] at least some assumptions that the child won't be doing much before execing or exiting. (But Im sure one of the The child process should be able to call any system calls it likes -without assuming that pthreads from the parent process have been copied over to the child process. I spose most implementations support that. regards -kamal From Programming with POSIX Threads [David R. Butenhof]: p.197-198: ... Avoid using fork in a threaded program (if you can) unless you intend to exec a new program immediately ... Pthreads does not terminate the other threads in a forked process. ... They simple cease to exist. ... The state of mutexes is not affected by a fork. If it was locked in the parent it is locked in the child! Norbert ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Nagios and threads
On 6/22/05, Kamal R. Prasad [EMAIL PROTECTED] wrote: [snip] at least some assumptions that the child won't be doing much before execing or exiting. (But Im sure one of the The child process should be able to call any system calls it likes -without assuming that pthreads from the parent process have been copied over to the child process. I spose most implementations support that. There's more to it than system calls, though (most (all?) of which will be async-signal-safe anyway). Simple example: any lock that the libc implementation needs to provide its functionality may be arbitrarily locked by some other thread: eg, one thread calls malloc() as another calls fork(): the original thread ceases to exist in the child while holding a lock in malloc, leaving malloc() unusable in the process. It may be that FreeBSD is less tolerant of this than other OSes, and the failure may occur more frequently, but I'm not sure that there's anything wrong with it per se. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Nagios and threads
On Wed, 22 Jun 2005, Norbert Koch wrote: [snip] at least some assumptions that the child won't be doing much before execing or exiting. (But Im sure one of the The child process should be able to call any system calls it likes -without assuming that pthreads from the parent process have been copied over to the child process. I spose most implementations support that. regards -kamal From Programming with POSIX Threads [David R. Butenhof]: p.197-198: ... Avoid using fork in a threaded program (if you can) unless you intend to exec a new program immediately ... Pthreads does not terminate the other threads in a forked process. ... They simple cease to exist. ... The state of mutexes is not affected by a fork. If it was locked in the parent it is locked in the child! Yes, and realize that both libc and libpthread are consumers themselves of mutexes (and CVs). Also, some system calls are wrapped by libpthread to provide cancellation points. Unless you exec after the fork, you may be relying on inconsistent mutex state. -- DE ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Nagios and threads
On Wed, 22 Jun 2005, Peter Edwards wrote: On 6/22/05, Kamal R. Prasad [EMAIL PROTECTED] wrote: The child process should be able to call any system calls it likes -without assuming that pthreads from the parent process have been copied over to the child process. I spose most implementations support that. There's more to it than system calls, though (most (all?) of which will be async-signal-safe anyway). Simple example: any lock that the libc implementation needs to provide its functionality may be arbitrarily locked by some other thread: eg, one thread calls malloc() as another calls fork(): the original thread ceases to exist in the child while holding a lock in malloc, leaving malloc() unusable in the process. We do protect the malloc lock across a fork(), but that's it. -- DE ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Nagios and threads
reading also the continuation of this mail thread, I wonder if there
is any relationship with this issue i found a few days ago debugging
asterisk. It happens when linking the code with libc_r, but maybe
some of the bugs in libc_r were also imported in other thread
libraries.
cheers
luigi
Probably a known issue, but I thought it worthwhile reporting it,
if nothing else for archival purposes.
I think our userland thread library (libc_r) has some bugs in
handling descriptors. I can reproduce the behaviour on -current
and 4.x, and I believe it applies to 5.x too.
Following is a description of the problem and some code to replicate it
The code includes a workaround but it is not particularly nice.
Any better ideas ? I am not sure on what to do, but perhaps the
only sensible thing to do is to add a note with this workaround
(or better ones, if available) to our pthreads manpage
--- PROBLEM DESCRIPTION ---
Basically, our libc_r keeps two views of i/o descriptors, one
(external) is for threads and reflects the modes requested by the
threads (blocking or not, etc.); the internal view instead is how
descriptors are actually set in the kernel -- and there they should
always be set as O_NONBLOCK to avoid blocking on a syscall.
The bug occurs when a process does a fork(), and then either
a close() or an exec() -- a similar thing also occurs with popen().
The relevant source code is in
/usr/src/lib/libc_r/uthread/uthread_execve.c
/usr/src/lib/libc_r/uthread/uthread_close.c
Right before the exec(), the internal descriptors are put into
blocking mode if the external one are blocking, and they are only
reset to O_NONBLOCK after termination of the child (upon SIGCHLD).
The same occurs for close().
Note that close() has hacks to leave pipes alone, but the same
code is not present in the execve() case where instead I believe
it would be necessary. Another thing to note is that there is
some kind of 'fate sharing' among the stdio descriptors (0, 1, 2)
which is not totally clear to me, but seems to require setting
O_NONBLOCK on all 3 to make sure that they are not changed to
blocking mode.
Because descriptors are shared between parent and child, for the
lifetime of the child descriptors in the parent will be blocking
and the scheduling of threads will be completely broken.
The only fix i have found is to act as follows:
pipe(fd); /* create a pipe with the child */
p = fork();
if (p == 0) { /* child */
/* call fcntl() _before_ close() to avoid resetting
* O_NONBLOCK on the internal descriptors. After that,
* close the descriptors not needed in the child.
*/
for (i=0; i getdtablesize(); i++) {
long fl = fcntl(i, F_GETFL);
if (fl != -1 i != fd[0]) {
/* open and must be closed in the child */
fcntl(i, F_SETFL, O_NONBLOCK | fl);
close(i);
}
}
/* standard stuff (dup2, exec*()... */
dup2(fd[0], STDOUT_FILENO); /* as an example */
execl();
} else { /* parent */
close(fd[0]); /* close child end. */
...
}
but of course this is rather unintuitive. On the other hand,
I have no idea of a better way to address the problem, and being
fairly new to threads programming maybe others know better.
I am attaching two minimal programs to demonstrate the bug.
simple.c is a simple program (linked against the regular C library)
cc -o simple simple.c
that only plays with blocking mode on the descriptors.
thre.c is meant to be linked with libc_r.
cc -o thre thre.c -lc_r
It does a fork and exec of the other program.
If you call it without arguments, it does not implement the
above workaround, and you see how the 'internal' descriptor
change to blocking mode. If you call it with an argument, it
implements the workaround.
enjoy
luigi
On Mon, Jun 20, 2005 at 04:56:36PM -0400, Charles Sprickman wrote:
Hello,
Just curious if there's any regulars here who would like to help Ethan
out:
http://nagios.sourceforge.net/docs/2_0/whatsnew.html
Known Issues
There are a few known issues with the Nagios 2.0 code at the moment.
Hopefully some of these will be fixed before 2.0 is released as stable...
1. FreeBSD and threads. On FreeBSD there's a native user-level
implementation of threads called 'pthread' and there's also an optional
ports collection 'linuxthreads' that uses kernel hooks. Some folks from
Yahoo! have reported that using the pthread library causes Nagios to pause
under heavy I/O load, causing some service check results to be lost.
Switching to linuxthreads seems to help this problem, but not fix it. The
lock happens in liblthread's __pthread_acquire() - it can't ever acquire
the spinlock. It happens when the main thread
Re: instability with mount_nullfs and jails
On Mon, Jun 20, 2005 at 07:50:31PM +0200, GiZmen wrote: hi, I have problem with mount_nullfs and jails. My system FreeBSD 5.4-STABLE when have two jails and each of this jails has couple mount_nullfs freeze without kernel panic. It freezes out in random times. Sometimes it can run for couple days sometimes it freezes after couple hours. I have mount points like below: [EMAIL PROTECTED]:~# mount /dev/ad0s1a on / (ufs, local) devfs on /dev (devfs, local, multilabel) /dev/ad0s1e on /tmp (ufs, local, nodev, nosuid, nosymfollow, soft-updates, multilabel, acls) /dev/ad0s1f on /usr (ufs, local, nodev, soft-updates, multilabel, acls) /dev/ad0s1d on /var (ufs, local, nodev, nosuid, soft-updates, multilabel, acls) /usr/local/bandwidthd/htdocs on /usr/jails/httpd/www/traf (nullfs, local, nodev, noexec, nosuid, read-only) /usr/local/share/pear on /usr/jails/httpd/lib/php/pear (nullfs, local, nodev, noexec, nosuid, read-only) /usr/local/share/smarty on /usr/jails/httpd/lib/php/smarty (nullfs, local, nodev, noexec, nosuid, read-only) /usr/local/lib/php/20020429 on /usr/jails/httpd/lib/php/20020429 (nullfs, local, nodev, noexec, nosuid, read-only) /usr/local/libexec/apache on /usr/jails/httpd/libexec/apache (nullfs, local, nodev, noexec, nosuid, read-only) /usr/local/etc/php on /usr/jails/httpd/etc/php (nullfs, local, nodev, noexec, nosuid, read-only) /usr/local/bin on /usr/jails/httpd/bin (nullfs, local, nodev, nosuid, read-only) devfs on /usr/jails/httpd/dev (devfs, local, multilabel) /dev/ad0s1g.bde on /crypto (ufs, local, noatime, nodev, nosuid, synchronous, soft-updates, multilabel, acls) /dev/ad2s1a.bde on /crypto2 (ufs, local, noatime, nodev, nosuid, synchronous, soft-updates, multilabel, acls) /crypto/home on /usr/jails/users/home (nullfs, local, nodev) /crypto/home on /usr/jails/httpd/home (nullfs, local, nodev, noexec, nosuid) from fstab.sshd: /bin/usr/jails/users/binnullfs ro,nosuid,nodev0 0 /sbin /usr/jails/users/sbin nullfs ro,nodev 0 0 /usr/ports /usr/jails/users/usr/ports nullfs rw,nosuid,nodev 0 0 /usr/include/usr/jails/users/usr/includenullfs ro,nosuid,noexec,nodev 0 0 /usr/share /usr/jails/users/usr/share nullfs ro,nosuid,nodev,noexec 0 0 /usr/lib/usr/jails/users/usr/libnullfs ro,nosuid,nodev 0 0 #/lib/usr/jails/users/libnullfs ro,nosuid,nodev,noexec 0 0 #/libexec/usr/jails/users/libexecnullfs ro,nosuid,nodev 0 0 /usr/bin/usr/jails/users/usr/binnullfs ro,nodev0 0 /usr/sbin /usr/jails/users/usr/sbin nullfs ro,nodev0 0 /usr/libexec/usr/jails/users/usr/libexecnullfs ro,nodev0 0 When i start sshd jail with mount_nulls like above i will have crash after random period of time. Without this jail i have never had any freeze. home dir in users jail is mount_nulled from /crypto partition.Earlier my users jails didnt have mount_nulls, i have had copy of each dir. I could have uptime like 80 days. I dont know why it is so instabile? Could any one point me somehow ? Maybe i do someting wrong or someting? Be specific about your crash. See the Developers' Handbook chapter on kernel debugging for the minimum information needed to proceed further with this. Kris pgpDJlVSJX7ar.pgp Description: PGP signature
Re: Bug in devinfo or something wrong with me?
On Tuesday 21 June 2005 11:16 am, John Baldwin wrote:
On Monday 16 May 2005 08:51 am, Stefan Farfeleder wrote:
On Mon, May 16, 2005 at 02:11:42PM +0300, Juho Vuori wrote:
The below included simple program reliably printfs error 4\n on
5.4-RELEASE. Am I understanding something wrong or is this a bug in
libdevinfo?
There is indeed a bug in libdevinfo.
To continue on this however, if you put say sleep(5) between
devinfo_free() and the second devinfo_init() and manage to change the
device configuration during the sleep (tested with pluggin in/out a USB
memory), the program terminates with no errors. I've run into other
oddities with devinfo as well, but in much more complex situations so
they might just as well be variations of this simple example.
if (devinfo_init()) {
devinfo_init() initialises the devinfo_dev tailq, devinfo_generation and
sets devinfo_initted to 1.
devinfo_free();
devinfo_free() clears devinfo_dev and sets devinfo_initted to 0 but
devinfo_generation keeps its value.
if (devinfo_init()) {
Now devinfo_dev doesn't get filled because ubus.ub_generation ==
devinfo_generation.
Here is a patch that resets devinfo_generation to 0 in devinfo_free().
The whole file can probably be simplified a bit due to this bug.
Stefan
I think the intent is actually so that you can call devinfo_init()
periodically without calling devinfo_free() to make sure the tree is up to
date. However, the generation should still be cleared when free() is
called. IOW, if you wanted to have a program that would poll the kernel
each second to get the current tree, it would call devinfo_init() in a loop
and only call devinfo_free() at program exit. This would let
devinfo_init() cache data if the device tree doesn't change. I'll try to
get the patch into the tree.
I just committed it to HEAD and will MFC in a week or so.
--
John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/
Power Users Use the Power to Serve = http://www.FreeBSD.org
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Nagios and threads
Daniel Eischen wrote: On Tue, 21 Jun 2005, Michal Mertl wrote: Dag-Erling Smrgrav wrote: Charles Sprickman [EMAIL PROTECTED] writes: 1. FreeBSD and threads. On FreeBSD there's a native user-level implementation of threads called 'pthread' and there's also an optional ports collection 'linuxthreads' that uses kernel hooks. This is only the case for FreeBSD 4. FreeBSD 5 has native threads. Yes, the description on Nagios page is not precise but unfortunately Nagios still has some problems even on 5.4. I wasn't able to find out what was wrong and the problem dissappeared when I had to replace the computer with single-processor one. The symptoms I observed were that every several days one Nagios process was consuming all the CPU doing hundreds of thousands of syscalls per second. It got always stuck around the time when the the daily cron job run. I did a ktrace on the stuck process and tried to abort it to have the core but I've lost the ktrace output and it never saved the core :-(. I'll install it on another machine and try to diagnose the problem some more. You gotta try it on -stable. OK. I installed Nagios on a SMP computer with fresh -stable. I tried to stress the disk but until now Nagios hasn't hung. Michal ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Nagios and threads
On Wed, 22 Jun 2005, Luigi Rizzo wrote: reading also the continuation of this mail thread, I wonder if there is any relationship with this issue i found a few days ago debugging asterisk. It happens when linking the code with libc_r, but maybe some of the bugs in libc_r were also imported in other thread libraries. No, libpthread and libthr don't have to jump through hoops to avoid blocking on I/O. -- DE ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Nagios and threads
In message: [EMAIL PROTECTED] Daniel Eischen [EMAIL PROTECTED] writes: : We do protect the malloc lock across a fork(), but that's it. With 4.x libc_r, you could easily get hangs accross a fork() if you did anything before the exec (like setup fd's for stdin/out). This was due to internal libc_r state being inconsistant. Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
kld problem
Unloading syscall kernel module can cause a system crash. It occurs when we
unload the module while a process is executing our syscall. Example:
$ cat kldtest.c
#include sys/types.h
#include sys/param.h
#include sys/proc.h
#include sys/module.h
#include sys/sysent.h
#include sys/kernel.h
#include sys/systm.h
#include sys/time.h
#include sys/timetc.h
static int test_nw;
static int test_syscall(struct thread *td, void *arg) {
struct timeval tv;
tv.tv_sec = 15;
tv.tv_usec = 0;
tsleep(test_nw,PWAIT,test,tvtohz(tv));
return 0;
}
static int test_offset = NO_SYSCALL;
static struct sysent test_sysent = {
0, test_syscall
};
static int test_load(struct module *mod, int cmd, void *arg) {
if(cmd != MOD_LOAD cmd != MOD_UNLOAD)
return EOPNOTSUPP;
return 0;
}
SYSCALL_MODULE(test,test_offset,test_sysent,test_load,NULL);
$ cat calltest.c
#include stdio.h
#include sys/types.h
#include sys/module.h
#include sys/syscall.h
int main() {
struct module_stat stat;
stat.version = sizeof(stat);
modstat(modfind(test),stat);
return syscall(stat.data.intval);
}
We load the module, execute calltest, and within 15 seconds unload the
module. We get a kernel panic, because we removed the memory where our
test_syscall was located.
Currently I don't have any idea how to fix it, but it would be nice to
inform about this issue in manual.
Maciek
--
Kwiaty dla Taty..
Wyslij bukiet na Dzien Ojca.. http://link.interia.pl/f1897
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kld problem
i don't know if kld should check if the module is used or not before
unloading it.
but i should.
On 6/22/05, Mauser [EMAIL PROTECTED] wrote:
Unloading syscall kernel module can cause a system crash. It occurs when we
unload the module while a process is executing our syscall. Example:
$ cat kldtest.c
#include sys/types.h
#include sys/param.h
#include sys/proc.h
#include sys/module.h
#include sys/sysent.h
#include sys/kernel.h
#include sys/systm.h
#include sys/time.h
#include sys/timetc.h
static int test_nw;
static int test_syscall(struct thread *td, void *arg) {
struct timeval tv;
tv.tv_sec = 15;
tv.tv_usec = 0;
tsleep(test_nw,PWAIT,test,tvtohz(tv));
return 0;
}
static int test_offset = NO_SYSCALL;
static struct sysent test_sysent = {
0, test_syscall
};
static int test_load(struct module *mod, int cmd, void *arg) {
if(cmd != MOD_LOAD cmd != MOD_UNLOAD)
return EOPNOTSUPP;
return 0;
}
SYSCALL_MODULE(test,test_offset,test_sysent,test_load,NULL);
$ cat calltest.c
#include stdio.h
#include sys/types.h
#include sys/module.h
#include sys/syscall.h
int main() {
struct module_stat stat;
stat.version = sizeof(stat);
modstat(modfind(test),stat);
return syscall(stat.data.intval);
}
We load the module, execute calltest, and within 15 seconds unload the
module. We get a kernel panic, because we removed the memory where our
test_syscall was located.
Currently I don't have any idea how to fix it, but it would be nice to
inform about this issue in manual.
Maciek
--
Kwiaty dla Taty..
Wyslij bukiet na Dzien Ojca.. http://link.interia.pl/f1897
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
--
I'm Searching For Perfection,
So Even If U Need Portability U've To Use Assembly ;-)
http://www.maslanlab.org
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
ipfw2 filtering on bridge
Hi there, I've been running into some problems with what is supposed to be a filtering bridge with IPFW, on FreeBSD 5.4-REL0. IPFW has been compiled into kernel: options BRIDGE options IPFIREWALL options IPFIREWALL_DEFAULT_TO_ACCEPT options IPDIVERT along with the bridging capability. No other firewalling mechanisms are enabled. The bridge is configured and working: net.link.ether.bridge.enable=1 net.link.ether.bridge.config=fxp0,vr0 net.link.ether.bridge_ipfw=1 fxp0 is Internet vr0 is a server with an external IP, called EXT_IP I tried blocking with trivial ruleset: 001000 0 deny icmp from any to any 65535 8518 584248 allow ip from any to any However, pinging through the bridge, from the Internet, works without fear: 64 bytes from EXT_IP: icmp_seq=0 ttl=233 time=85.994 ms 64 bytes from EXT_IP: icmp_seq=1 ttl=233 time=96.220 ms If anyone could help me a bit, I'd be really thankfull. Thanks for the time. Yours Sincerely, -- Alin-Adrian Anton GPG keyID 0x183087BA (B129 E8F4 7B34 15A9 0785 2F7C 5823 ABA0 1830 87BA) gpg --keyserver pgp.mit.edu --recv-keys 0x183087BA It is dangerous to be right when the government is wrong. - Voltaire ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kld problem
In the last episode (Jun 22), Mauser said:
Unloading syscall kernel module can cause a system crash. It occurs when we
unload the module while a process is executing our syscall. Example:
$ cat kldtest.c
...
static int test_syscall(struct thread *td, void *arg) {
struct timeval tv;
tv.tv_sec = 15;
tv.tv_usec = 0;
tsleep(test_nw,PWAIT,test,tvtohz(tv));
return 0;
}
...
static int test_load(struct module *mod, int cmd, void *arg) {
if(cmd != MOD_LOAD cmd != MOD_UNLOAD)
return EOPNOTSUPP;
return 0;
}
In test_load, you can return a nonzero value on MOD_UNLOAD to abort an
unload request. See the module(9) manpage for more details. You may
need to increment a counter or hold a mutex while in the syscall to
make it easy for test_load to determine whether it's safe to unload or
not.
--
Dan Nelson
[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: kld problem
On Wed, 22 Jun 2005 16:52:58 -0500
Dan Nelson [EMAIL PROTECTED] wrote:
In the last episode (Jun 22), Mauser said:
Unloading syscall kernel module can cause a system crash. It occurs
when we unload the module while a process is executing our syscall.
Example:
$ cat kldtest.c
...
static int test_syscall(struct thread *td, void *arg) {
struct timeval tv;
tv.tv_sec = 15;
tv.tv_usec = 0;
tsleep(test_nw,PWAIT,test,tvtohz(tv));
return 0;
}
...
static int test_load(struct module *mod, int cmd, void *arg) {
if(cmd != MOD_LOAD cmd != MOD_UNLOAD)
return EOPNOTSUPP;
return 0;
In test_load, you can return a nonzero value on MOD_UNLOAD to abort an
unload request. See the module(9) manpage for more details. You may
need to increment a counter or hold a mutex while in the syscall to
make it easy for test_load to determine whether it's safe to unload or
not.
Yes, I know, I rtfm ;)
This issue occured to me while writing own security-related kld which
modify some syscalls and perform authorization (something like
rexec,cerb). I think that holding a mutex on each of syscalls would be a
bit inefficient. Furthermore I'll need to unset MP_SAFE flags in
modified syscalls to be 100% certain that nobody unload the module while
executing syscall (mutex _after_ calling syscall won't be enough if i'm
not mistaken).
Maciek
--
OMNIXMAIL! Jesli masz telefon w sieci Era i dostep do WAP, to mozesz
na komorce odbierac poczte ze wszystkich swoich kont poczty e-mail!
OMNIXMAIL jest w Era Omnix: http://link.interia.pl/f1896
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: using vkbd device
Hello Norbert, I did some more testing with kbdmux. 1. I wait for the screen saver becoming active. 2. I press the control key. 3. All keys, I press after that, come as control keys, e.g. I press 'j' or 'J' and see a linefeed, I press 'I' and see a tab. 4. I wait a second time for the screen saver. 5. I press control. 6. The keys are ok now. Does syscons eat up the key but sets the state in kbdmux? hmmm... i can not reproduce it here (on -current). could you please try the latest code. i have included some of your patches and did a compile only test on 4.x system (freefall.freebsd.org). http://www.geocities.com/m_evmenkin/kbdmux-3.tar.gz it also fixes (hopefully) issues with state synchronization (lights, etc.). thanks, max ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Nagios and threads
On Wed, 22 Jun 2005, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Daniel Eischen [EMAIL PROTECTED] writes: : We do protect the malloc lock across a fork(), but that's it. With 4.x libc_r, you could easily get hangs accross a fork() if you did anything before the exec (like setup fd's for stdin/out). This was due to internal libc_r state being inconsistant. I was only referring to libpthread in the above... I don't think libc_r is as robust in that regard. -- DE ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
