Re: linux-f10-flashplugin
30.09.2011, 00:05, "Piotr Kubaj" : >> 28.09.2011, 21:10, "Conrad J. Sabatier" : >>> On Wed, 28 Sep 2011 11:50:08 -0500 >>> "Conrad J. Sabatier" wrote: It was a while ago that I did the actual wrapper install, but if I remember right, I simply copied npwrapper.libflashplayer.so from /usr/local/lib/browser_plugins to /home/conrads/.mozilla/plugins. You may want to try doing that and see if firefox/chromium will then recognize it. In theory, the system-wide install > under /usr/local/lib/browser_plugins *should* work, but I seem to recall having problems with it, which was why I tried putting it under ~/.mozilla/plugins. Maybe it has something to do with the fact that it's not a native plugin(?). I don't know, really. But this has worked fine for me ever since, even across upgrades. Hope this helps. Let us know how it turns out. >>> Actually, now that I think of it, I think the way I did it was this: >>> >>> cd /home/conrads/.mozilla/plugins >>> >>> /usr/local/lib/nspluginwrapper/x86_64/freebsd/npconfig >>> -i /usr/local/lib/npapi/linux-f10-flashplugin/libflashplayer.so >>> >>> And npwrapper.libflashplayer.so was created >>> under /home/conrads/.mozilla/plugins. >>> >>> Hope this helps. >> > I've done it. No results. > I also have the same error on 2 computers using 9.0-BETA3. Before the > yesterday upgrade, everything was fine, however. I have linsys and > linproc mounted, linux module compiled into the kernel and Firefox, > Chromium and Opera all show Flash Player in about:plugins. I tested linux-f10-flashplugin on 9.0-BETA3 amd64 yesterday. The system was compiled from fresh sources as well as ports. Firefox 7 and Chromium 14 work fine with the Linux flash plugin. The flash plugin configuration has been created strictly in accordance with the FreeBSD Hanbook. No additional actions required. The problem exists for me with 8-STABLE only. -- Regards, Serguey. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
nsswitch problem ...
Hi ... I've been trying for some time now to allow offline logging in my pc which connects to a LDAP server. I've configured my nsswitch.conf like so: passwd: cache files ldap #compat group: cache files ldap #compat shadow: cache files ldap #compat hosts: cache files mdns4_minimal [NOTFOUND=return] dns mdns4 networks: cache files protocols: db files services: cache db files ethers: db files rpc:db files netgroup: nis My nscd daemon is also configured to hold it's cache for a long period of time. When I reboot my machine I cannot login as an LDAP user eventhough the nscd is running ( using the $id command ). I'm simulating an offline environment shutting down the ethernet link so there's no connection with the ldap server and to test if the nsswitch mechanism works. Unfortunately it doesn't. Checking the /var/log/auth.log when I try to login as an LDAP user I see messages of nss_ldap trying to locate the ldap server, and ignoring my cache. Can anyone help me ?? Thanks ... ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: nsswitch problem ...
Hello, Am 30.09.2011 um 16:00 schrieb Teratux: > My nscd daemon is also configured to hold it's cache for a long period of > time. > When I reboot my machine I cannot login ... reboot == restart of nscd == empty cache, if I'm not mistaken. If nscd has a persistent storage for cache entries, that would be news to me. IIRC it uses only memory. HTH, Patrick -- punkt.de GmbH * Kaiserallee 13a * 76133 Karlsruhe Tel. 0721 9109 0 * Fax 0721 9109 100 i...@punkt.de http://www.punkt.de Gf: Jürgen Egeling AG Mannheim 108285 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: linux-f10-flashplugin
2011/9/30 S.N.Grigoriev : > > 30.09.2011, 00:05, "Piotr Kubaj" : > >>> 28.09.2011, 21:10, "Conrad J. Sabatier" : On Wed, 28 Sep 2011 11:50:08 -0500 "Conrad J. Sabatier" wrote: > It was a while ago that I did the actual wrapper install, but if I > remember right, I simply copied npwrapper.libflashplayer.so > from /usr/local/lib/browser_plugins to /home/conrads/.mozilla/plugins. > You may want to try doing that and see if firefox/chromium will then > recognize it. > > In theory, the system-wide install >> under /usr/local/lib/browser_plugins *should* work, but I seem to > recall having problems with it, which was why I tried putting it > under ~/.mozilla/plugins. Maybe it has something to do with the fact > that it's not a native plugin(?). I don't know, really. But this > has worked fine for me ever since, even across upgrades. > > Hope this helps. Let us know how it turns out. Actually, now that I think of it, I think the way I did it was this: cd /home/conrads/.mozilla/plugins /usr/local/lib/nspluginwrapper/x86_64/freebsd/npconfig -i /usr/local/lib/npapi/linux-f10-flashplugin/libflashplayer.so And npwrapper.libflashplayer.so was created under /home/conrads/.mozilla/plugins. Hope this helps. >>> > I've done it. No results. >> I also have the same error on 2 computers using 9.0-BETA3. Before the >> yesterday upgrade, everything was fine, however. I have linsys and >> linproc mounted, linux module compiled into the kernel and Firefox, >> Chromium and Opera all show Flash Player in about:plugins. > > I tested linux-f10-flashplugin on 9.0-BETA3 amd64 yesterday. > The system was compiled from fresh sources as well as ports. > Firefox 7 and Chromium 14 work fine with the Linux flash plugin. > The flash plugin configuration has been created strictly in accordance > with the FreeBSD Handbook. No additional actions required. > The problem exists for me with 8-STABLE only. For those who missed it, this is a problem in the Linux emulation. See the announcement from the the FreeBSD Security Officer. for details, but the recent security patch triggered the problem by adding check for the _UN data structure which is 4 bytes longer in Linux than on FreeBSD. The emulation layer has been passing the structure unmodified to the kernel and it is now being rejected.The message states that Colin is working on a patch to the emulation code which should be available shortly. http://docs.freebsd.org/cgi/getmsg.cgi?fetch=14130+0+current/freebsd-emulation -- R. Kevin Oberman, Network Engineer - Retired E-mail: kob6...@gmail.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: linux-f10-flashplugin (unrelated "Locale not supported" message)
On Thu, 29 Sep 2011 16:13:50 -0700 Ted Faber wrote: > (process:52979): Gtk-WARNING **: Locale not supported by C library. > Using the fallback 'C' locale. I would expect something like this if you use a valid FreeBSD locale specification which is not valid on Linux. For example on FreeBSD the iso 8859-XX locales have to be written differently. Maybe in your case we have something similar, a locale which exists in FreeBSD with a slightly different name than on Linux (Fedora 10 in the case of the linuxulator). Bye, Alexander. -- http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: linux-f10-flashplugin (unrelated "Locale not supported" message)
On Fri, Sep 30, 2011 at 09:21:12PM +0200, Alexander Leidinger wrote: > On Thu, 29 Sep 2011 16:13:50 -0700 Ted Faber wrote: > > > (process:52979): Gtk-WARNING **: Locale not supported by C library. > > Using the fallback 'C' locale. > > I would expect something like this if you use a valid FreeBSD locale > specification which is not valid on Linux. For example on FreeBSD the > iso 8859-XX locales have to be written differently. Maybe in your case > we have something similar, a locale which exists in FreeBSD with a > slightly different name than on Linux (Fedora 10 in the case of the > linuxulator). FWIW, I use: $ echo $LC_ALL en_US.UTF-8 -- Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG pgpLi3k9VXNqO.pgp Description: PGP signature
Re: linux-f10-flashplugin (unrelated "Locale not supported" message)
On Fri, 30 Sep 2011 12:32:10 -0700 Ted Faber wrote: > On Fri, Sep 30, 2011 at 09:21:12PM +0200, Alexander Leidinger wrote: > > On Thu, 29 Sep 2011 16:13:50 -0700 Ted Faber wrote: > > > > > (process:52979): Gtk-WARNING **: Locale not supported by C > > > library. Using the fallback 'C' locale. > > > > I would expect something like this if you use a valid FreeBSD locale > > specification which is not valid on Linux. For example on FreeBSD > > the iso 8859-XX locales have to be written differently. Maybe in > > your case we have something similar, a locale which exists in > > FreeBSD with a slightly different name than on Linux (Fedora 10 in > > the case of the linuxulator). > > FWIW, I use: > > $ echo $LC_ALL > en_US.UTF-8 FreeBSD /usr/share/locale (en only): ---snip--- drwxr-xr-x 2 root wheel 8B 20 Apr 15:32 en_AU.ISO8859-1/ drwxr-xr-x 2 root wheel 8B 20 Apr 15:32 en_AU.ISO8859-15/ drwxr-xr-x 2 root wheel 8B 20 Apr 15:32 en_AU.US-ASCII/ drwxr-xr-x 2 root wheel 8B 20 Apr 15:32 en_AU.UTF-8/ drwxr-xr-x 2 root wheel 8B 20 Apr 15:32 en_CA.ISO8859-1/ drwxr-xr-x 2 root wheel 8B 20 Apr 15:32 en_CA.ISO8859-15/ drwxr-xr-x 2 root wheel 8B 20 Apr 15:32 en_CA.US-ASCII/ drwxr-xr-x 2 root wheel 8B 20 Apr 15:32 en_CA.UTF-8/ drwxr-xr-x 2 root wheel 8B 20 Apr 15:32 en_GB.ISO8859-1/ drwxr-xr-x 2 root wheel 8B 20 Apr 15:32 en_GB.ISO8859-15/ drwxr-xr-x 2 root wheel 8B 20 Apr 15:32 en_GB.US-ASCII/ drwxr-xr-x 2 root wheel 8B 20 Apr 15:32 en_GB.UTF-8/ drwxr-xr-x 2 root wheel 8B 20 Apr 15:32 en_IE.UTF-8/ drwxr-xr-x 2 root wheel 8B 20 Apr 15:32 en_NZ.ISO8859-1/ drwxr-xr-x 2 root wheel 8B 20 Apr 15:32 en_NZ.ISO8859-15/ drwxr-xr-x 2 root wheel 8B 20 Apr 15:32 en_NZ.US-ASCII/ drwxr-xr-x 2 root wheel 8B 20 Apr 15:32 en_NZ.UTF-8/ drwxr-xr-x 2 root wheel 8B 20 Apr 15:32 en_US.ISO8859-1/ drwxr-xr-x 2 root wheel 8B 20 Apr 15:32 en_US.ISO8859-15/ drwxr-xr-x 2 root wheel 8B 20 Apr 15:32 en_US.US-ASCII/ drwxr-xr-x 2 root wheel 8B 20 Apr 15:32 en_US.UTF-8/ ---snip--- FreeBSD /usr/local/share/locale (en only): ---snip--- drwxr-xr-x 3 root wheel 3B 2 Jul 2010 ca@valencia/ drwxr-xr-x 3 root wheel 3B 11 Feb 2010 en/ drwxr-xr-x 3 root wheel 3B 1 Jul 2010 en@boldquot/ drwxr-xr-x 3 root wheel 3B 1 Jul 2010 en@quot/ drwxr-xr-x 3 root wheel 3B 2 Jul 2010 en@shaw/ drwxr-xr-x 3 root wheel 3B 11 Feb 2010 en_AU/ drwxr-xr-x 3 root wheel 3B 11 Feb 2010 en_CA/ drwxr-xr-x 3 root wheel 3B 11 Feb 2010 en_GB/ drwxr-xr-x 3 root wheel 3B 31 Jan 2011 en_NZ/ drwxr-xr-x 3 root wheel 3B 8 Dez 2010 en_US/ ---snip--- Linuxulator (/comapt/linux)/usr/share (en only): ---snip--- drwxr-xr-x 3 root wheel 3B 21 Nov 2010 ca_ES@valencian/ drwxr-xr-x 3 root wheel 3B 21 Nov 2010 den/ drwxr-xr-x 3 root wheel 3B 21 Nov 2010 en/ drwxr-xr-x 3 root wheel 3B 21 Nov 2010 en@boldquot/ drwxr-xr-x 3 root wheel 3B 21 Nov 2010 en@quot/ drwxr-xr-x 3 root wheel 3B 21 Nov 2010 en_AU/ drwxr-xr-x 3 root wheel 3B 21 Nov 2010 en_CA/ drwxr-xr-x 3 root wheel 3B 21 Nov 2010 en_GB/ drwxr-xr-x 3 root wheel 3B 21 Nov 2010 en_US/ drwxr-xr-x 3 root wheel 3B 21 Nov 2010 enm/ drwxr-xr-x 3 root wheel 3B 21 Nov 2010 men/ drwxr-xr-x 3 root wheel 3B 21 Nov 2010 wen/ drwxr-xr-x 3 root wheel 3B 21 Nov 2010 zen/ ---snip--- A while ago (to be honest, I have to tell some years ago), I was thinking about adding a link-farm to the linux_base which links the FreeBSD names to more or less suitable Linux names. As you can see I never took the time to actually do it. I also never set the locale to some value suitable for linux, so it may be the case that it is not enough to do this... anyone out there willing to have a look at the gtk/glib code which produces this output? The goal is to have a look how gtk/glib determines if the locale is incorrectly set. Bye, Alexander. -- http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
7.3 + kqueue + apache/php + DNS lookup problem
Howdy,
So, this is a bit of an odd one I've got a web server running
apache 2.2.17 and php 5.3.5. The host itself is running 7.3-RELEASE,
i386, and is not busy. I can do DNS queries on the command line all day
long and they are very snappy. Using nslookup, dig, whatever.
The weirdness comes in when the httpd process needs to do a DNS lookup.
With a local cache I'm getting the following:
97625 httpd0.031139 CALL connect(0x55,0x284fd590,0x10)
97625 httpd0.031142 STRU struct sockaddr { AF_INET, 127.0.0.1:53 }
97625 httpd0.031150 RET connect 0
97625 httpd0.031153 CALL sendto(0x55,0x2a7d1000,0x1e,0,0,0)
97625 httpd0.031169 GIO fd 85 wrote 30 bytes
97625 httpd0.031173 RET sendto 30/0x1e
97625 httpd0.031179 CALL clock_gettime(0,0xbfbfb58c)
97625 httpd0.031184 RET clock_gettime 0
97625 httpd0.031188 CALL
kevent(0x54,0xbfbfb678,0x1,0xbfbfb678,0x1,0xbfbfb68c)
97625 httpd3.064266 GIO fd 84 wrote 20 bytes
note the 3 second delay here.
97625 httpd3.064277 GIO fd 84 read 20 bytes
97625 httpd3.064281 RET kevent 1
97625 httpd3.064287 CALL
recvfrom(0x55,0x2a6c4000,0x1,0,0xbfbfb5f8,0xbfbfb694)
97625 httpd3.064293 GIO fd 85 read 30 bytes
97625 httpd3.064296 STRU struct sockaddr { AF_INET, 127.0.0.1:53 }
97625 httpd3.064299 RET recvfrom 30/0x1e
97625 httpd3.064308 CALL close(0x55)
I'm open to suggestions on where to look to improve this situation.
Thanks,
Doug
--
Nothin' ever doesn't change, but nothin' changes much.
-- OK Go
Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) http://SupersetSolutions.com/
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 7.3 + kqueue + apache/php + DNS lookup problem
On Fri, Sep 30, 2011 at 04:31:18PM -0700, Doug Barton wrote:
> Howdy,
>
> So, this is a bit of an odd one I've got a web server running
> apache 2.2.17 and php 5.3.5. The host itself is running 7.3-RELEASE,
> i386, and is not busy. I can do DNS queries on the command line all day
> long and they are very snappy. Using nslookup, dig, whatever.
>
> The weirdness comes in when the httpd process needs to do a DNS lookup.
> With a local cache I'm getting the following:
>
> 97625 httpd0.031139 CALL connect(0x55,0x284fd590,0x10)
> 97625 httpd0.031142 STRU struct sockaddr { AF_INET, 127.0.0.1:53 }
> 97625 httpd0.031150 RET connect 0
> 97625 httpd0.031153 CALL sendto(0x55,0x2a7d1000,0x1e,0,0,0)
> 97625 httpd0.031169 GIO fd 85 wrote 30 bytes
> 97625 httpd0.031173 RET sendto 30/0x1e
> 97625 httpd0.031179 CALL clock_gettime(0,0xbfbfb58c)
> 97625 httpd0.031184 RET clock_gettime 0
> 97625 httpd0.031188 CALL
> kevent(0x54,0xbfbfb678,0x1,0xbfbfb678,0x1,0xbfbfb68c)
> 97625 httpd3.064266 GIO fd 84 wrote 20 bytes
>
> note the 3 second delay here.
>
> 97625 httpd3.064277 GIO fd 84 read 20 bytes
> 97625 httpd3.064281 RET kevent 1
> 97625 httpd3.064287 CALL
> recvfrom(0x55,0x2a6c4000,0x1,0,0xbfbfb5f8,0xbfbfb694)
> 97625 httpd3.064293 GIO fd 85 read 30 bytes
> 97625 httpd3.064296 STRU struct sockaddr { AF_INET, 127.0.0.1:53 }
> 97625 httpd3.064299 RET recvfrom 30/0x1e
> 97625 httpd3.064308 CALL close(0x55)
>
> I'm open to suggestions on where to look to improve this situation.
I'm not familiar with the kqueue event mechanism in BSD. I know it's
great, but I'm just not familiar with how to use it/etc.. If I'm
reading the syscall trace correctly, it looks like the daemon opens up a
socket to 127.0.0.1:53 (named) on fd 0x55/85, writes 30 bytes of data to
it, initiates a kernel event that writes 20 bytes of data to a different
descriptor 0x54/84, reads 20 bytes back from that fd, then reads 30
bytes from descriptor 0x55/85.
I wonder what the kevent() is actually accomplishing here. I wish I
could see within the kevent structs at 0xbfbfb678 and 0xbfbfb678, and
the timespec struct at 0xbfbfb68c.
There's also a part of me that remembers some sort of kevent/kqueue
problem on older FreeBSD that got fixed at one point. The problem is
that I can't remember what that problem was, nor what release fixed it.
As such I don't want to resort to a "upgrade your OS!" response.
Does this happen when httpd tries to do DNS resolution for, say, an
incoming connection to the web server (e.g. trying to resolve the
incoming IP address of the client to an FQDN), or is it happening within
some PHP code (assuming PHP is installed/used as an Apache module)
that's trying to do DNS resolution of some kind?
Are the delays always 3 seconds? If so, that almost sounds like a
timeout of some kind. That's the thing about the kevent() call: I wish
I could see what's in the timespec struct, since that's what defines the
timeout values.
--
| Jeremy Chadwickjdc at parodius.com |
| Parodius Networking http://www.parodius.com/ |
| UNIX Systems Administrator Mountain View, CA, US |
| Making life hard for others since 1977. PGP 4BD6C0CB |
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 7.3 + kqueue + apache/php + DNS lookup problem
On Sep 30, 2011, at 4:31 PM, Doug Barton wrote: > o, this is a bit of an odd one I've got a web server running > apache 2.2.17 and php 5.3.5. The host itself is running 7.3-RELEASE, > i386, and is not busy. I can do DNS queries on the command line all day > long and they are very snappy. Using nslookup, dig, whatever. Are you using prefork or worker/threaded MPM with Apache? While some PHP modules claim to be threadsafe, experience has left me convinced that neither threaded PHP nor threaded mod_perl is reliable under even minimal load. If you haven't tried using prefork MPM, consider using it, and maybe add fastcgi if you need to. > The weirdness comes in when the httpd process needs to do a DNS lookup. [ ... ] > I'm open to suggestions on where to look to improve this situation. One of the major problems with doing any DNS lookups in Apache is that you can easily encounter a DoS as all of the child processes try to resolve addresses; a malware scan coming from an IP with broken reverse DNS can cause things to grind to a halt for a few seconds. If at all possible, do not perform any DNS resolution in Apache, either for Allow/Deny rules in Location blocks, or for log processing. Regards, -- -Chuck ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 7.3 + kqueue + apache/php + DNS lookup problem
Thanks Jeremy and Chuck. Answers below.
On 09/30/2011 17:37, Jeremy Chadwick wrote:
> On Fri, Sep 30, 2011 at 04:31:18PM -0700, Doug Barton wrote:
>> Howdy,
>>
>> So, this is a bit of an odd one I've got a web server running
>> apache 2.2.17 and php 5.3.5. The host itself is running 7.3-RELEASE,
>> i386, and is not busy. I can do DNS queries on the command line all day
>> long and they are very snappy. Using nslookup, dig, whatever.
>>
>> The weirdness comes in when the httpd process needs to do a DNS lookup.
>> With a local cache I'm getting the following:
>>
>> 97625 httpd0.031139 CALL connect(0x55,0x284fd590,0x10)
>> 97625 httpd0.031142 STRU struct sockaddr { AF_INET, 127.0.0.1:53 }
>> 97625 httpd0.031150 RET connect 0
>> 97625 httpd0.031153 CALL sendto(0x55,0x2a7d1000,0x1e,0,0,0)
>> 97625 httpd0.031169 GIO fd 85 wrote 30 bytes
>> 97625 httpd0.031173 RET sendto 30/0x1e
>> 97625 httpd0.031179 CALL clock_gettime(0,0xbfbfb58c)
>> 97625 httpd0.031184 RET clock_gettime 0
>> 97625 httpd0.031188 CALL
>> kevent(0x54,0xbfbfb678,0x1,0xbfbfb678,0x1,0xbfbfb68c)
>> 97625 httpd3.064266 GIO fd 84 wrote 20 bytes
>>
>> note the 3 second delay here.
>>
>> 97625 httpd3.064277 GIO fd 84 read 20 bytes
>> 97625 httpd3.064281 RET kevent 1
>> 97625 httpd3.064287 CALL
>> recvfrom(0x55,0x2a6c4000,0x1,0,0xbfbfb5f8,0xbfbfb694)
>> 97625 httpd3.064293 GIO fd 85 read 30 bytes
>> 97625 httpd3.064296 STRU struct sockaddr { AF_INET, 127.0.0.1:53 }
>> 97625 httpd3.064299 RET recvfrom 30/0x1e
>> 97625 httpd3.064308 CALL close(0x55)
>>
>> I'm open to suggestions on where to look to improve this situation.
>
> I'm not familiar with the kqueue event mechanism in BSD. I know it's
> great, but I'm just not familiar with how to use it/etc.. If I'm
> reading the syscall trace correctly, it looks like the daemon opens up a
> socket to 127.0.0.1:53 (named) on fd 0x55/85, writes 30 bytes of data to
> it, initiates a kernel event that writes 20 bytes of data to a different
> descriptor 0x54/84, reads 20 bytes back from that fd, then reads 30
> bytes from descriptor 0x55/85.
>
> I wonder what the kevent() is actually accomplishing here. I wish I
> could see within the kevent structs at 0xbfbfb678 and 0xbfbfb678, and
> the timespec struct at 0xbfbfb68c.
>
> There's also a part of me that remembers some sort of kevent/kqueue
> problem on older FreeBSD that got fixed at one point. The problem is
> that I can't remember what that problem was, nor what release fixed it.
> As such I don't want to resort to a "upgrade your OS!" response.
That's not necessarily off the table, but doing that would have to be
because we're sure it would fix the problem.
> Does this happen when httpd tries to do DNS resolution for, say, an
> incoming connection to the web server (e.g. trying to resolve the
> incoming IP address of the client to an FQDN), or is it happening within
> some PHP code (assuming PHP is installed/used as an Apache module)
> that's trying to do DNS resolution of some kind?
It's a php module doing a lookup for the hostname of the back-end mysql
server.
> Are the delays always 3 seconds?
Pretty much.
> If so, that almost sounds like a timeout of some kind.
That was my first thought, but the answer always comes eventually.
To answer Chuck's questions, no threading is involved, and it's not
apache doing the lookups.
Doug
--
Nothin' ever doesn't change, but nothin' changes much.
-- OK Go
Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) http://SupersetSolutions.com/
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
