Re: php
Did you open PRs for the ports that don’t compile for you? ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
php
the large ports update seems to have broken a lot of things which use php-72 (yes, it serves them right:), e.g. wordpress 5, nfsen, ... randy, waiting patiently for someone to clean this one up ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: php version
On 04/07/15 16:37, Cristiano Deana wrote: > Hi, > > please help me understand. > > In /usr/ports/UPDATING we have: > > --- > # grep -A11 ^20150220 /usr/ports/UPDATING | more > 20150220: > AFFECTS: users of PHP > > The default PHP version has been updated from 5.4 to 5.6. > > If you use binary packages you should make a list of php packages > before running 'pkg upgrade': > > # pkg info php5\* > ~/installed-php-ports-list > > After the upgrade, check with such list if all your php extensions > are still installed, and reinstall them if needed. > --- > # grep PHP_DEFAULT /usr/ports/Mk/bsd.default-versions.mk PHP_DEFAULT?= 5.6 This is the default port the system will pickup to satisfy dependencies. If another one is already installed tha tone will be used. For binary packages, which are build in a clean environment, it means you will get this one version, unless you override that with: DEFAULT_VERSIONS= php=5.6 in the building system configuration files. (the per jail make.conf) -- Guido Falsi ___ 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: php version
On 04/07/2015 9:37 am, Cristiano Deana wrote: Hi, please help me understand. In /usr/ports/UPDATING we have: --- # grep -A11 ^20150220 /usr/ports/UPDATING | more 20150220: AFFECTS: users of PHP The default PHP version has been updated from 5.4 to 5.6. If you use binary packages you should make a list of php packages before running 'pkg upgrade': # pkg info php5\* > ~/installed-php-ports-list After the upgrade, check with such list if all your php extensions are still installed, and reinstall them if needed. --- but, also: --- # grep -B1 ^PORTVERSION /usr/ports/lang/php5/Makefile PORTNAME= php5 PORTVERSION=5.4.38 --- same with pkg: --- # pkg install -n php5 Updating FreeBSD repository catalogue... FreeBSD repository is up-to-date. All repositories are up-to-date. The following 1 packages will be affected (of 0 checked): New packages to be INSTALLED: php5: 5.4.39 The process will require 15 MiB more space. 2 MiB to be downloaded. This in a 10.1-RELENG. Is UPDATING wrong? Thank you PHP 5.6 is in /usr/ports/lang/php56 If you install another port/pkg that depends on PHP and don't have a version already installed the defaults tell it which version to use. I am guessing its up to the individual port maintainers if they are going to have a port/pkg entry that links to the default. -- Thanks, Dean E. Weimer http://www.dweimer.net/ ___ 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"
php version
Hi, please help me understand. In /usr/ports/UPDATING we have: --- # grep -A11 ^20150220 /usr/ports/UPDATING | more 20150220: AFFECTS: users of PHP The default PHP version has been updated from 5.4 to 5.6. If you use binary packages you should make a list of php packages before running 'pkg upgrade': # pkg info php5\* > ~/installed-php-ports-list After the upgrade, check with such list if all your php extensions are still installed, and reinstall them if needed. --- but, also: --- # grep -B1 ^PORTVERSION /usr/ports/lang/php5/Makefile PORTNAME= php5 PORTVERSION=5.4.38 --- same with pkg: --- # pkg install -n php5 Updating FreeBSD repository catalogue... FreeBSD repository is up-to-date. All repositories are up-to-date. The following 1 packages will be affected (of 0 checked): New packages to be INSTALLED: php5: 5.4.39 The process will require 15 MiB more space. 2 MiB to be downloaded. This in a 10.1-RELENG. Is UPDATING wrong? Thank you -- Cris, member of G.U.F.I Italian FreeBSD User Group http://www.gufi.org/ ___ 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: Running a script via PHP
and just to be safe wrap it all up in a VIMAGE jail On 1 October 2013 14:39, Ronald Klop wrote: > On Fri, 27 Sep 2013 23:50:02 +0200, Charles Swiger > wrote: > > Hi-- >> >> On Sep 27, 2013, at 2:18 AM, Michael BlackHeart >> wrote: >> >>> Hello there, >>> It's quite off-topic, but I'm using freebsd-stable,so >>> >>> The priblem is - running a script that requires root privileges via PHP >>> (or >>> probably CGI - I do not care, just want it to be secure and working). >>> >> >> Unfortunately the combination of PHP, doing something which needs root, >> and >> security are inherently contradictory. >> >> The least risky approach would be to invoke the needed command via sudo, >> or >> possibly a small setuid-root C wrapper program which launches only the >> needed script >> with root permissions. Use sudo unless your C wrapper is careful enough >> to use >> exec() and not system(), sanitizes $PATH and other env variables, and >> guards against >> games with $IFS, shell metachars, and such. >> >> Regards, >> > > Use sudo, because your home grown C wrapper will make all the mistakes > which are already solved in sudo. Or will be spotted in the future in sudo > and will never be spotted in your program. > Chances are high that future requirements of your C wrapper will turn it > in a little sudo. > > Ronald. > > __**_ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/**mailman/listinfo/freebsd-**stable<http://lists.freebsd.org/mailman/listinfo/freebsd-stable> > To unsubscribe, send any mail to > "freebsd-stable-unsubscribe@**freebsd.org > " > ___ 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: Running a script via PHP
On Fri, 27 Sep 2013 23:50:02 +0200, Charles Swiger wrote: Hi-- On Sep 27, 2013, at 2:18 AM, Michael BlackHeart wrote: Hello there, It's quite off-topic, but I'm using freebsd-stable,so The priblem is - running a script that requires root privileges via PHP (or probably CGI - I do not care, just want it to be secure and working). Unfortunately the combination of PHP, doing something which needs root, and security are inherently contradictory. The least risky approach would be to invoke the needed command via sudo, or possibly a small setuid-root C wrapper program which launches only the needed script with root permissions. Use sudo unless your C wrapper is careful enough to use exec() and not system(), sanitizes $PATH and other env variables, and guards against games with $IFS, shell metachars, and such. Regards, Use sudo, because your home grown C wrapper will make all the mistakes which are already solved in sudo. Or will be spotted in the future in sudo and will never be spotted in your program. Chances are high that future requirements of your C wrapper will turn it in a little sudo. Ronald. ___ 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: Running a script via PHP
Hi-- On Sep 27, 2013, at 2:18 AM, Michael BlackHeart wrote: > Hello there, > It's quite off-topic, but I'm using freebsd-stable,so > > The priblem is - running a script that requires root privileges via PHP (or > probably CGI - I do not care, just want it to be secure and working). Unfortunately the combination of PHP, doing something which needs root, and security are inherently contradictory. The least risky approach would be to invoke the needed command via sudo, or possibly a small setuid-root C wrapper program which launches only the needed script with root permissions. Use sudo unless your C wrapper is careful enough to use exec() and not system(), sanitizes $PATH and other env variables, and guards against games with $IFS, shell metachars, and such. 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: Running a script via PHP
On Fri, 27 Sep 2013 11:18:40 +0200, Michael BlackHeart wrote: Hello there, It's quite off-topic, but I'm using freebsd-stable,so The priblem is - running a script that requires root privileges via PHP (or probably CGI - I do not care, just want it to be secure and working). It's all about minidlna service (I use upnp to so mediatomb and other are no options). On FreeBSD it should be resync-ed manually, so I've got a simple script placed in /etc/periodic/daily: more 957.dlna_update #!/bin/sh #Script to daily update minidlna DB a="$*" if (/usr/local/etc/rc.d/minidlna stop 1>/dev/null);then sleep 10 if /usr/local/etc/rc.d/minidlna rescan;then /usr/bin/logger -t minidlna "DB updated." exit 0 else /usr/bin/logger -t minidlna "Error. Failed to update DB." exit 1 fi else /usr/bin/logger -t minidlna "Error. Failed to update DB." exit 1 fi And it's working fine to me. But it uses service infrastructure. So when I'm trying to run via PHP it fails. For example running under unprivileged user: id uid=1001(amd_miek) gid=0(wheel) groups=0(wheel),5(operator) -rwsr-sr-x 1 root wheel 394 27 сен 10:58 957.dlna_update* sh -x 957.dlna_update + a='' + /usr/local/etc/rc.d/minidlna stop kill: 10786: Operation not permitted + /usr/bin/logger -t minidlna 'Error. Failed to update DB.' + exit 1 What is the best way to run it via WEB? You can't setuid a shell script. The executable actually is '/bin/sh' which just reads the shell script. So you should setuid /bin/sh which is a security problem. You can use sudo to do this. (/usr/ports/security/sudo) Ronald. ___ 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"
Running a script via PHP
Hello there, It's quite off-topic, but I'm using freebsd-stable,so The priblem is - running a script that requires root privileges via PHP (or probably CGI - I do not care, just want it to be secure and working). It's all about minidlna service (I use upnp to so mediatomb and other are no options). On FreeBSD it should be resync-ed manually, so I've got a simple script placed in /etc/periodic/daily: more 957.dlna_update #!/bin/sh #Script to daily update minidlna DB a="$*" if (/usr/local/etc/rc.d/minidlna stop 1>/dev/null);then sleep 10 if /usr/local/etc/rc.d/minidlna rescan;then /usr/bin/logger -t minidlna "DB updated." exit 0 else /usr/bin/logger -t minidlna "Error. Failed to update DB." exit 1 fi else /usr/bin/logger -t minidlna "Error. Failed to update DB." exit 1 fi And it's working fine to me. But it uses service infrastructure. So when I'm trying to run via PHP it fails. For example running under unprivileged user: id uid=1001(amd_miek) gid=0(wheel) groups=0(wheel),5(operator) -rwsr-sr-x 1 root wheel 394 27 сен 10:58 957.dlna_update* sh -x 957.dlna_update + a='' + /usr/local/etc/rc.d/minidlna stop kill: 10786: Operation not permitted + /usr/bin/logger -t minidlna 'Error. Failed to update DB.' + exit 1 What is the best way to run it via WEB? ___ 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"
PHP-gnupg in jail - apache and tty
Hello, Currently I'm facing a wierd problem. I should have an environment in a jail where a PHP script (with pecl-gnupg) is able to sign messages with PGP. However it turned out, that PGP needs a tty in the jail, which is available if I use tmux or ssh login to the jail and signing from shell works. From the apache-php side, I got a "data signing failed" and nothing more useful. Of course I tried ktrace, but I couldn't find anything useful. I know that Apache should have a real login shell if php-gnupg is used, so it has one. (Yes I know it's bad, but it's a dedicated environment for this web application only.) On Linux I could do a tty with mknod in a chroot and signing worked with php-gnupg. Anyone has any idea to start with? Thanks, Andras ___ 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 10/02/2011 12:10, Matthew Seaman wrote: On 01/10/2011 02:18, Doug Barton wrote: 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. Hmmm... Is this a function of DNS traffic being via UDP? Presumably you're not seeing the same sort of delays when eg. apache connects to mysql via TCP. Hard to think of another UDP protocol you could use to test -- SNMP perhaps? Or somehow forcing the DNS traffic to go via TCP? Tricky to make that happen when the resolver is on localhost. Of course, since DNS will only fall back to TCP after trying UDP, that's going to be even slower overall than your current situation, but the point here is to examine the truss output for timing details specifically around where the TCP query is issued. Cheers, Matthew What is the exact query issued and what was the response? I see recvfrom returned 30 bytes in Doug's original mail which seems awfully short for a meaningful DNS response. Cheers Michiel ___ 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 01/10/2011 02:18, Doug Barton wrote: >> 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. Hmmm... Is this a function of DNS traffic being via UDP? Presumably you're not seeing the same sort of delays when eg. apache connects to mysql via TCP. Hard to think of another UDP protocol you could use to test -- SNMP perhaps? Or somehow forcing the DNS traffic to go via TCP? Tricky to make that happen when the resolver is on localhost. Of course, since DNS will only fall back to TCP after trying UDP, that's going to be even slower overall than your current situation, but the point here is to examine the truss output for timing details specifically around where the TCP query is issued. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate JID: matt...@infracaninophile.co.uk Kent, CT11 9PW signature.asc Description: OpenPGP digital signature
Re: 7.3 + kqueue + apache/php + DNS lookup problem
Something stupid and ridiculous, like the socket watermark points are set incorrectly? It'd also be helpful to see exactly what the knotes were. Adrian ___ 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 Sun, Oct 02, 2011 at 10:18:30AM +0200, Damien Fleuriot wrote: > On 1 October 2011 03:18, Doug Barton wrote: > > 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 > > > > Check your bind/unbound logs to ensure the queries are actually > successful on their first try. > > Is your DNS using forwarders ? views ? How would this explain 100% quick/reliable lookups when done from tools like nslookup and host? Same box and same resolver (127.0.0.1:53), yet different behaviour (nslookup/host vs. PHP). -- | 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 1 October 2011 03:18, Doug Barton wrote: > 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 > Check your bind/unbound logs to ensure the queries are actually successful on their first try. Is your DNS using forwarders ? views ? ___ 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"
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
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"
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"
Dtrace with PHP scripts works on FreeBSD8-STABLE!
Hello,
I was able to compile [1] and and run PHP Dtrace provider on
FreeBSD-STABLE. Everything works as expected and looks very cool. It
works both from Apache (mod_php) and cli. If there are port commiters
with dtrace experience - please, take it.
Below there is a small demo:
This is a test script:
PrintTest();
class demoClass{
function demoClass(){
@chdir("/notexists");
}
function PrintTest(){
echo "TEST\n";
}
}
?>
This is the most basic output to demonstrate how provider works:
# dtrace -n 'php*::: /arg0/
{printf("\t\t%s%s%s",copyinstr(arg3),copyinstr(arg4),copyinstr(arg0))}'
dtrace: description 'php*::: ' matched 24 probes
dtrace: buffer size lowered to 2m
CPU IDFUNCTION:NAME
2 44455 php_dtrace_execute_internal:function-entry
file_get_contents
2 44457 php_dtrace_execute_internal:function-return
file_get_contents
2 44456 php_dtrace_execute:function-entry
demoClass::demoClass
2 44455 php_dtrace_execute_internal:function-entry chdir
2 44457 php_dtrace_execute_internal:function-return chdir
2 44458 php_dtrace_execute:function-return
demoClass::demoClass
2 44456 php_dtrace_execute:function-entry
demoClass::PrintTest
2 44458 php_dtrace_execute:function-return
demoClass::PrintTest
As you could see there is information about all functions (and
classnames) in our test.
Also there is a possibility to trace syscalls used by PHP function. This
is output from ./php_syscolors.d (with minor modifications):
for the file_get_contents (reads file to variable):
1 16019/100898 6 test.php:4func ->
file_get_contents
1 16019/100898 18 ":-syscall-> __getcwd
1 16019/100898 8 ":-syscall <- __getcwd
1 16019/100898 8 ":-syscall->
clock_gettime
1 16019/100898 4 ":-syscall <- clock_gettime
1 16019/100898 5 ":-syscall-> open
1 16019/100898 9 ":-syscall <- open
1 16019/100898 5 ":-syscall-> fstat
1 16019/100898 5 ":-syscall <- fstat
1 16019/100898 4 ":-syscall-> lseek
1 16019/100898 4 ":-syscall <- lseek
1 16019/100898 5 ":-syscall-> fstat
1 16019/100898 4 ":-syscall <- fstat
1 16019/100898 4 ":-syscall-> read
1 16019/100898 6 ":-syscall <- read
1 16019/100898 9 ":-syscall-> read
1 16019/100898 5 ":-syscall <- read
1 16019/100898 4 ":-syscall-> read
1 16019/100898 4 ":-syscall <- read
1 16019/100898 5 ":-syscall-> close
1 16019/100898 10 ":-syscall <- close
1 16019/100898 8 test.php:4func <- file_get_contents
Of course it is possible to use aggregations, filtering and all other
dtrace features.
Problems: I found that buffer size in dtrace is always about 2m. I am
using a lot of events while trying to debug running web server.
Todo: latest PHP alpha releases include dtrace support internally (and
it is extended, compared to this pecl extension). Currently build
failing on BSD and i had no time to investigate problem source (i think
they are using some ugly linker hacks). It would be great to get it
fixed before PHP release to have it in FreeBSD out of the box.
[1] http://www.freebsd.org/cgi/query-pr.cgi?pr=158983
___
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: php-cgi frozen with sbwait when SMP enable
On Tue, Nov 25, 2008 at 6:40 AM, Ken Chen <[EMAIL PROTECTED]> wrote: > Change to configuration to solve this problem: > > #server.network-backend = "freebsd-sendfile" > server.network-backend = "writev" > > http://redmine.lighttpd.net/boards/2/topics/show/141 Maybe this patch is related? http://redmine.lighttpd.net/issues/show/1813 Scott ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: php-cgi frozen with sbwait when SMP enable
Ken Chen wrote: > Change to configuration to solve this problem: > > #server.network-backend = "freebsd-sendfile" > server.network-backend = "writev" > > http://redmine.lighttpd.net/boards/2/topics/show/141 Good to know. Please consider posting a PR. signature.asc Description: OpenPGP digital signature
Re: php-cgi frozen with sbwait when SMP enable
Change to configuration to solve this problem: #server.network-backend = "freebsd-sendfile" server.network-backend = "writev" http://redmine.lighttpd.net/boards/2/topics/show/141 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: php-cgi frozen with sbwait when SMP enable
Thank Jeremy, I will try.
2008/11/12 Jeremy Chadwick <[EMAIL PROTECTED]>
> On Tue, Nov 11, 2008 at 10:09:38PM +0800, Ken Chen wrote:
> > I think the parent php-cgi are very health. I have tried:
> >
> > There are total 49 php-cgi processes are running or frozen, the '1 wait'
> is
> > parent .
> >
> > web4# ps alx | grep php-cgi | grep -v grep | awk '{print $9}' | sort |
> uniq
> > -c | sort -n
> > 1 biowr
> >1 wait
> > 15 sbwait
> > 32 accept
> >
> > Kill one of frozen php-cgi processes.
> >
> > web4# kill -9 61392
> >
> > Check again the amount of php-cgi processes, there are still 49 php-cgi
> > procerss.
> >
> > web4# ps alx | grep php-cgi | grep -v grep | awk '{print $9}' | sort |
> uniq
> > -c | sort -n
> >1 biord
> >1 bo_wwa
> >1 wait
> >4 -
> > 17 sbwait
> > 25 accept
>
> I would recommend you try the lighttpd and fastcgi mailing lists at this
> point.
>
> --
> | Jeremy Chadwickjdc at parodius.com |
> | Parodius Networking http://www.parodius.com/ |
> | UNIX Systems Administrator Mountain View, CA, USA |
> | 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 "[EMAIL PROTECTED]"
Re: php-cgi frozen with sbwait when SMP enable
On Tue, Nov 11, 2008 at 10:09:38PM +0800, Ken Chen wrote:
> I think the parent php-cgi are very health. I have tried:
>
> There are total 49 php-cgi processes are running or frozen, the '1 wait' is
> parent .
>
> web4# ps alx | grep php-cgi | grep -v grep | awk '{print $9}' | sort | uniq
> -c | sort -n
>1 biowr
>1 wait
> 15 sbwait
> 32 accept
>
> Kill one of frozen php-cgi processes.
>
> web4# kill -9 61392
>
> Check again the amount of php-cgi processes, there are still 49 php-cgi
> procerss.
>
> web4# ps alx | grep php-cgi | grep -v grep | awk '{print $9}' | sort | uniq
> -c | sort -n
>1 biord
>1 bo_wwa
>1 wait
>4 -
> 17 sbwait
> 25 accept
I would recommend you try the lighttpd and fastcgi mailing lists at this
point.
--
| Jeremy Chadwickjdc at parodius.com |
| Parodius Networking http://www.parodius.com/ |
| UNIX Systems Administrator Mountain View, CA, USA |
| 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 "[EMAIL PROTECTED]"
Re: php-cgi frozen with sbwait when SMP enable
The report from lighttpd looks fine:
cache.cached-itmes: 98293
cache.hitrate(%): 96
cache.memory-inuse(KB): 6143
fastcgi.active-requests: 16
fastcgi.backend.0.0.connected: 419008
fastcgi.backend.0.0.died: 0
fastcgi.backend.0.0.disabled: 0
fastcgi.backend.0.0.load: 16
fastcgi.backend.0.0.overloaded: 0
fastcgi.backend.0.load: 17
fastcgi.requests: 419008
But at this moment:
web4# ps alx | grep php-cgi | grep -v grep | awk '{print $9}' | sort |
uniq -c | sort -n
1 biord
1 wait
2 -
16 sbwait
29 accept
web4# ps alx | grep php-cgi | grep -v grep | grep sbwait
65534 61392 61384 1 4 -15 182328 69312 sbwait I<??0:53.39
/usr/local/bin/php-cgi
65534 61399 61384 0 4 -15 182328 71112 sbwait I<??1:09.60
/usr/local/bin/php-cgi
65534 61409 61384 0 4 -15 182328 72812 sbwait I<??1:39.40
/usr/local/bin/php-cgi
65534 61411 61384 0 4 -15 183352 74536 sbwait I<??1:49.08
/usr/local/bin/php-cgi
65534 61412 61384 0 4 -15 183352 74508 sbwait I<?? 1:33.31
/usr/local/bin/php-cgi
65534 61414 61384 0 4 -15 182328 62860 sbwait I<?? 0:28.81
/usr/local/bin/php-cgi
65534 61418 61384 0 4 -15 182328 71448 sbwait I< ??1:17.56
/usr/local/bin/php-cgi
65534 61426 61384 0 4 -15 183352 60456 sbwait I< ??0:22.16
/usr/local/bin/php-cgi
65534 71529 61384 0 4 -15 182328 74144 sbwait I<??0:36.87
/usr/local/bin/php-cgi
65534 71555 61384 0 4 -15 182328 72820 sbwait I<??0:19.19
/usr/local/bin/php-cgi
65534 71556 61384 0 4 -15 182328 74452 sbwait I<??0:38.27
/usr/local/bin/php-cgi
65534 71590 61384 0 4 -15 182328 76828 sbwait I<??0:57.42
/usr/local/bin/php-cgi
65534 71594 61384 0 4 -15 182328 75576 sbwait I<??0:46.50
/usr/local/bin/php-cgi
65534 71595 61384 0 4 -15 182328 84048 sbwait I<??1:52.15
/usr/local/bin/php-cgi
65534 77285 61384 0 4 -15 182328 88280 sbwait S<??0:15.22
/usr/local/bin/php-cgi
65534 77288 61384 3 4 -15 182328 88808 sbwait S<??0:14.43
/usr/local/bin/php-cgi
65534 77317 61384 0 4 -15 182328 88912 sbwait S<??0:12.79
/usr/local/bin/php-cgi
65534 77323 61384 0 4 -15 182328 89140 sbwait S<??0:13.51
/usr/local/bin/php-cgi
65534 77359 61384 6 4 -15 182328 88200 sbwait S<??0:13.04
/usr/local/bin/php-cgi
65534 77372 61384 2 4 -15 182328 89200 sbwait S<??0:12.16
/usr/local/bin/php-cgi
65534 77392 61384 1 4 -15 181304 87200 sbwait S<??0:11.02
/usr/local/bin/php-cgi
65534 77401 61384 1 4 -15 182328 88800 sbwait S<??0:12.49
/usr/local/bin/php-cgi
The PID of php-cgi which are less than 71595 are frozen.
2008/11/10 Anton - Valqk <[EMAIL PROTECTED]>
> You can try taking look to lighttpd status and fcgi processes status
> like this:
> server.modules += ( "mod_status" )
> status.status-url = "/server-status"
> status.statistics-url = "/sstatus1"
>
> status.statistics-url gives info for each fastcgi like this:
>
> fastcgi.active-requests: 0
> fastcgi.backend.backend1.0.connected: 12493970
> fastcgi.backend.backend1.0.died: 0
> fastcgi.backend.backend1.0.disabled: 0
> fastcgi.backend.backend1.0.load: 0
> fastcgi.backend.backend1.0.overloaded: 0
> fastcgi.backend.backend1.load: 1
> fastcgi.requests: 19479062
>
>
> etc... read what each means on lighttpd site...
> pls tell what caused this, it'd be very interesting to me!
>
> cheers,
> valqk.
>
> Ken Chen wrote:
> > I capture something.
> >
> > Please check the PID 57776. It's CPU time never change since my previous
> > mail here.
> >
> > web4# ps alx | grep php-cgi | grep -v grep | grep sbwait
> > 65534 57776 47240 0 4 0 182328 84984 sbwait I ??2:02.12
> > /usr/local/bin/php-cgi
> > 65534 57801 47240 0 4 0 182328 82408 sbwait I ??0:19.97
> > /usr/local/bin/php-cgi
> > 65534 57809 47240 0 4 0 182328 84096 sbwait I ??1:12.03
> > /usr/local/bin/php-cgi
> > 65534 57823 47240 0 4 0 182328 84492 sbwait I ??2:04.21
> > /usr/local/bin/php-cgi
> > 65534 57833 47240 0 4 0 183352 83316 sbwait I ??0:28.62
> > /usr/local/bin/php-cgi
> > 65534 57866 47240 0 4 0 182328 79952 sbwait I ??0:05.92
> > /usr/local/bin/php-cgi
> > 65534 57870 47240 0 4 0 182328 83184 sbwait I ??0:56.83
> > /usr/local/bin/php-cgi
> > 65534 57871 47240 0 4 0 182328 83388 sbwait I ??0:54.96
> > /usr/local/bin/php-cgi
> > 65534 57891 47240 0 4 0 182328 84436 sbwait I ??1:58.32
> > /usr/local/bin/php-cgi
> > 65534 57925 47240 0 4 0 182328 84380 sbwait I ??2:03.53
> > /usr/local/bin/php-cgi
&
Re: php-cgi frozen with sbwait when SMP enable
I think the parent php-cgi are very health. I have tried:
There are total 49 php-cgi processes are running or frozen, the '1 wait' is
parent .
web4# ps alx | grep php-cgi | grep -v grep | awk '{print $9}' | sort | uniq
-c | sort -n
1 biowr
1 wait
15 sbwait
32 accept
Kill one of frozen php-cgi processes.
web4# kill -9 61392
Check again the amount of php-cgi processes, there are still 49 php-cgi
procerss.
web4# ps alx | grep php-cgi | grep -v grep | awk '{print $9}' | sort | uniq
-c | sort -n
1 biord
1 bo_wwa
1 wait
4 -
17 sbwait
25 accept
2008/11/10 Anton - Valqk <[EMAIL PROTECTED]>
> Oh, just saw that, this could be caused by dead parent php-cgi processes
> (just a guess).
> I used to run lighttpd with span-fcgi executable and it happens very
> often to have dead parents (of php-cgi childs) that must be killed by
> killall php-cgi (eg. restart _ALL_ php-cgi processes, pretty stupid!!!
> but if you have dead parent you can't know which childs to kill)...
> If you run your php-cgi processes just from the lighttpd(and lighttpd
> manages php-cgi processes) try running it with fcgi-spawn and write a
> script to check parents of the php-cgi backends and you'll see if that's
> the cause of having 'hang' phps :(
>
> pls tell me what is it. I'm interested!
>
> cheers,
> valqk.
> Ken Chen wrote:
> > Hi Jeremy,
> >
> > A health FastCGI process have a lifetime, so the PIDs of all php-cgi
> > processes should in a short range.
> >
> > There are some 'php-cgi' fall in 'sbwait' state, and stay there forever.
> The
> > frozen 'php-cgi' can't accept new request, so never retire.
> >
> > Please forgive my poor English.
> >
> > 2008/11/7 Jeremy Chadwick <[EMAIL PROTECTED]>
> >
> >
> >> On Fri, Nov 07, 2008 at 07:29:37PM +0800, Ken Chen wrote:
> >>
> >>> Hello,
> >>>
> >>> I have 4 web servers with lighttpd to serve one web site with DNS load
> >>> sharing. On the 2 SMP-enable web servers, there will be many php-cgi
> >>>
> >> frozen
> >>
> >>> in 'sbwait' state every day. It means the php-cgi stay in 'sbwait'
> state,
> >>> and never be back to 'accept' or other state. If I restart them, there
> >>>
> >> will
> >>
> >>> be frozen php-cgi appear some hours later.
> >>>
> >>> There is no problem on the other single CPU web servers which running
> >>>
> >> same
> >>
> >>> php scripts and same configuration and version of PHP.
> >>>
> >>> Why and any solution?
> >>>
> >> I'm not understanding what the problem is (and I've seen the output you
> >> provided later in the thread). Are you stating the problem is that you
> >> see many php-cgi processes? Or are you worried they're not doing
> >> anything? Does the website function, lock up, or anything like that?
> >> If not, what's the issue? :-)
> >>
> >> --
> >> | Jeremy Chadwickjdc at parodius.com |
> >> | Parodius Networking http://www.parodius.com/ |
> >> | UNIX Systems Administrator Mountain View, CA, USA |
> >> | 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 "[EMAIL PROTECTED]
> "
> >
> >
>
>
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: php-cgi frozen with sbwait when SMP enable
Anton - Valqk wrote: > You can try taking look to lighttpd status and fcgi processes status > like this: > server.modules += ( "mod_status" ) > status.status-url = "/server-status" > status.statistics-url = "/sstatus1" > > status.statistics-url gives info for each fastcgi like this: > > fastcgi.active-requests: 0 > fastcgi.backend.backend1.0.connected: 12493970 > fastcgi.backend.backend1.0.died: 0 > fastcgi.backend.backend1.0.disabled: 0 > fastcgi.backend.backend1.0.load: 0 > fastcgi.backend.backend1.0.overloaded: 0 > fastcgi.backend.backend1.load: 1 > fastcgi.requests: 19479062 > > > etc... read what each means on lighttpd site... > pls tell what caused this, it'd be very interesting to me! Yes, though I don't use lighttpd right now, I plan to one day so I'm also interested in the cause and solution for this problem. signature.asc Description: OpenPGP digital signature
Re: php-cgi frozen with sbwait when SMP enable
You can try taking look to lighttpd status and fcgi processes status like this: server.modules += ( "mod_status" ) status.status-url = "/server-status" status.statistics-url = "/sstatus1" status.statistics-url gives info for each fastcgi like this: fastcgi.active-requests: 0 fastcgi.backend.backend1.0.connected: 12493970 fastcgi.backend.backend1.0.died: 0 fastcgi.backend.backend1.0.disabled: 0 fastcgi.backend.backend1.0.load: 0 fastcgi.backend.backend1.0.overloaded: 0 fastcgi.backend.backend1.load: 1 fastcgi.requests: 19479062 etc... read what each means on lighttpd site... pls tell what caused this, it'd be very interesting to me! cheers, valqk. Ken Chen wrote: > I capture something. > > Please check the PID 57776. It's CPU time never change since my previous > mail here. > > web4# ps alx | grep php-cgi | grep -v grep | grep sbwait > 65534 57776 47240 0 4 0 182328 84984 sbwait I ??2:02.12 > /usr/local/bin/php-cgi > 65534 57801 47240 0 4 0 182328 82408 sbwait I ??0:19.97 > /usr/local/bin/php-cgi > 65534 57809 47240 0 4 0 182328 84096 sbwait I ??1:12.03 > /usr/local/bin/php-cgi > 65534 57823 47240 0 4 0 182328 84492 sbwait I ??2:04.21 > /usr/local/bin/php-cgi > 65534 57833 47240 0 4 0 183352 83316 sbwait I ??0:28.62 > /usr/local/bin/php-cgi > 65534 57866 47240 0 4 0 182328 79952 sbwait I ??0:05.92 > /usr/local/bin/php-cgi > 65534 57870 47240 0 4 0 182328 83184 sbwait I ??0:56.83 > /usr/local/bin/php-cgi > 65534 57871 47240 0 4 0 182328 83388 sbwait I ??0:54.96 > /usr/local/bin/php-cgi > 65534 57891 47240 0 4 0 182328 84436 sbwait I ??1:58.32 > /usr/local/bin/php-cgi > 65534 57925 47240 0 4 0 182328 84380 sbwait I ??2:03.53 > /usr/local/bin/php-cgi > 65534 65944 47240 0 4 0 182328 84184 sbwait I ??0:39.97 > /usr/local/bin/php-cgi > 65534 65952 47240 0 4 0 182328 84408 sbwait I ?? 0:21.37 > /usr/local/bin/php-cgi > 65534 66007 47240 0 4 0 183352 90960 sbwait I ??1:16.81 > /usr/local/bin/php-cgi > 65534 66014 47240 5 4 0 182328 92748 sbwait S ??1:41.23 > /usr/local/bin/php-cgi > 65534 66038 47240 1 4 0 182328 91900 sbwait I ??1:38.04 > /usr/local/bin/php-cgi > 65534 66060 47240 0 4 0 182328 90048 sbwait I ??1:15.46 > /usr/local/bin/php-cgi > 65534 66078 47240 3 4 0 182328 92224 sbwait S ??1:39.66 > /usr/local/bin/php-cgi > web4# top -b > last pid: 70768; load averages: 1.62, 1.65, 1.43 up 4+15:56:06 > 22:53:48 > 85 processes: 1 running, 84 sleeping > > Mem: 492M Active, 1204M Inact, 218M Wired, 60M Cache, 112M Buf, 27M Free > Swap: 2019M Total, 20K Used, 2019M Free > > > PID USERNAME THR PRI NICE SIZERES STATE C TIME WCPU COMMAND > 69544 nobody 1 8 0 203M 38500K nanslp 1 6:31 11.33% php > 47290 nobody 1 4 0 101M98M kqread 1 30:42 2.98% lighttpd > 66526 nobody 1 40 178M 92796K accept 1 1:40 1.12% php-cgi > 66077 nobody 1 40 178M 92512K accept 0 1:49 1.07% php-cgi > 65921 nobody 1 40 178M 92696K accept 0 1:43 0.98% php-cgi > 65968 nobody 1 40 178M 92484K accept 0 1:43 0.93% php-cgi > 66017 nobody 1 40 178M 92444K accept 0 1:50 0.88% php-cgi > 65979 nobody 1 40 178M 92676K accept 1 1:44 0.88% php-cgi > 66424 nobody 1 40 178M 92928K accept 1 1:36 0.88% php-cgi > 65938 nobody 1 40 178M 92336K accept 1 1:52 0.73% php-cgi > 65951 nobody 1 40 178M 92704K accept 0 1:48 0.73% php-cgi > 66016 nobody 1 40 178M 92232K accept 1 1:41 0.73% php-cgi > 65950 nobody 1 40 178M 93192K accept 0 1:51 0.68% php-cgi > 65999 nobody 1 40 178M 92940K accept 1 1:46 0.63% php-cgi > 66008 nobody 1 40 178M 93000K accept 1 1:46 0.63% php-cgi > 69286 nobody 1 40 178M 92208K accept 1 0:37 0.63% php-cgi > 47289 nobody 1 40 73400K 70640K kqread 1 12:02 0.59% lighttpd > 65980 nobody 1 40 178M 93156K accept 1 1:51 0.59% php-cgi > 2008/11/7 Ivan Voras <[EMAIL PROTECTED]> > > >> Ken Chen wrote: >> >>> Oh.. sorry, I forgot to provide the information of my environment. >>> >>> web4# php-cgi -v >>> PHP 5.2.6 (cgi-fcgi) (built: Nov 2 2008 11:16:30) >>> Copyright (c) 1997-2008 The PHP Group >>> Zend Engine v2.2.0, Copyright (c) 1998-2008 Zend Technologies >>> with XCache v1.2.2, Copyright (c) 2005-2007, by mOo >>> web4# /usr/local/lighttpd/sbin/lighttpd -v >>> lighttpd-1.4.
Re: php-cgi frozen with sbwait when SMP enable
Ken Chen wrote: > I capture something. > > Please check the PID 57776. It's CPU time never change since my previous > mail here. > > web4# ps alx | grep php-cgi | grep -v grep | grep sbwait > 65534 57776 47240 0 4 0 182328 84984 sbwait I ?? 2:02.12 > /usr/local/bin/php-cgi You're right and it is strange. I don't know why this would happen but some things that come to mind are: * Does lighttpd have some kind of status page or a diagnostic utility to show you the states of FastCGI processes? * Does lighttpd have a facility to "reap" old PHP processes? For example, mod_fcgid has a maximum lifetime setting for FastCGI processes. * You could try sending a SIGABRT to the php-cgi process to get a core dump and inspect it. Without debugging symbols it will probably give you the name of the function it's been waiting in. signature.asc Description: OpenPGP digital signature
Re: php-cgi frozen with sbwait when SMP enable
I capture something. Please check the PID 57776. It's CPU time never change since my previous mail here. web4# ps alx | grep php-cgi | grep -v grep | grep sbwait 65534 57776 47240 0 4 0 182328 84984 sbwait I ??2:02.12 /usr/local/bin/php-cgi 65534 57801 47240 0 4 0 182328 82408 sbwait I ??0:19.97 /usr/local/bin/php-cgi 65534 57809 47240 0 4 0 182328 84096 sbwait I ??1:12.03 /usr/local/bin/php-cgi 65534 57823 47240 0 4 0 182328 84492 sbwait I ??2:04.21 /usr/local/bin/php-cgi 65534 57833 47240 0 4 0 183352 83316 sbwait I ??0:28.62 /usr/local/bin/php-cgi 65534 57866 47240 0 4 0 182328 79952 sbwait I ??0:05.92 /usr/local/bin/php-cgi 65534 57870 47240 0 4 0 182328 83184 sbwait I ??0:56.83 /usr/local/bin/php-cgi 65534 57871 47240 0 4 0 182328 83388 sbwait I ??0:54.96 /usr/local/bin/php-cgi 65534 57891 47240 0 4 0 182328 84436 sbwait I ??1:58.32 /usr/local/bin/php-cgi 65534 57925 47240 0 4 0 182328 84380 sbwait I ??2:03.53 /usr/local/bin/php-cgi 65534 65944 47240 0 4 0 182328 84184 sbwait I ??0:39.97 /usr/local/bin/php-cgi 65534 65952 47240 0 4 0 182328 84408 sbwait I ??0:21.37 /usr/local/bin/php-cgi 65534 66007 47240 0 4 0 183352 90960 sbwait I ??1:16.81 /usr/local/bin/php-cgi 65534 66014 47240 5 4 0 182328 92748 sbwait S ??1:41.23 /usr/local/bin/php-cgi 65534 66038 47240 1 4 0 182328 91900 sbwait I ??1:38.04 /usr/local/bin/php-cgi 65534 66060 47240 0 4 0 182328 90048 sbwait I ??1:15.46 /usr/local/bin/php-cgi 65534 66078 47240 3 4 0 182328 92224 sbwait S ??1:39.66 /usr/local/bin/php-cgi web4# top -b last pid: 70768; load averages: 1.62, 1.65, 1.43 up 4+15:56:06 22:53:48 85 processes: 1 running, 84 sleeping Mem: 492M Active, 1204M Inact, 218M Wired, 60M Cache, 112M Buf, 27M Free Swap: 2019M Total, 20K Used, 2019M Free PID USERNAME THR PRI NICE SIZERES STATE C TIME WCPU COMMAND 69544 nobody 1 80 203M 38500K nanslp 1 6:31 11.33% php 47290 nobody 1 40 101M98M kqread 1 30:42 2.98% lighttpd 66526 nobody 1 40 178M 92796K accept 1 1:40 1.12% php-cgi 66077 nobody 1 40 178M 92512K accept 0 1:49 1.07% php-cgi 65921 nobody 1 40 178M 92696K accept 0 1:43 0.98% php-cgi 65968 nobody 1 40 178M 92484K accept 0 1:43 0.93% php-cgi 66017 nobody 1 40 178M 92444K accept 0 1:50 0.88% php-cgi 65979 nobody 1 40 178M 92676K accept 1 1:44 0.88% php-cgi 66424 nobody 1 40 178M 92928K accept 1 1:36 0.88% php-cgi 65938 nobody 1 40 178M 92336K accept 1 1:52 0.73% php-cgi 65951 nobody 1 40 178M 92704K accept 0 1:48 0.73% php-cgi 66016 nobody 1 40 178M 92232K accept 1 1:41 0.73% php-cgi 65950 nobody 1 40 178M 93192K accept 0 1:51 0.68% php-cgi 65999 nobody 1 40 178M 92940K accept 1 1:46 0.63% php-cgi 66008 nobody 1 40 178M 93000K accept 1 1:46 0.63% php-cgi 69286 nobody 1 40 178M 92208K accept 1 0:37 0.63% php-cgi 47289 nobody 1 40 73400K 70640K kqread 1 12:02 0.59% lighttpd 65980 nobody 1 40 178M 93156K accept 1 1:51 0.59% php-cgi 2008/11/7 Ivan Voras <[EMAIL PROTECTED]> > Ken Chen wrote: > > Oh.. sorry, I forgot to provide the information of my environment. > > > > web4# php-cgi -v > > PHP 5.2.6 (cgi-fcgi) (built: Nov 2 2008 11:16:30) > > Copyright (c) 1997-2008 The PHP Group > > Zend Engine v2.2.0, Copyright (c) 1998-2008 Zend Technologies > > with XCache v1.2.2, Copyright (c) 2005-2007, by mOo > > web4# /usr/local/lighttpd/sbin/lighttpd -v > > lighttpd-1.4.19 - a light and fast webserver > > Build-Date: Sep 1 2008 16:58:51 > > web4# uname -a > > FreeBSD web4..com 7.0-RELEASE-p5 FreeBSD 7.0-RELEASE-p5 #11: Mon Nov > 3 > > 01:10:36 CST 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/WEB4 i386 > > web4# ps alx | grep php-cgi | grep -v grep | grep sbwait > > 65534 57776 47240 0 4 0 182328 84984 sbwait I ??2:02.12 > > /usr/local/bin/php-cgi > > 65534 57801 47240 0 4 0 182328 82408 sbwait I ??0:19.97 > > /usr/local/bin/php-cgi > > 65534 57809 47240 0 4 0 182328 84096 sbwait I ?? 1:12.03 > > /usr/local/bin/php-cgi > > 65534 57823 47240 0 4 0 182328 84492 sbwait I ??2:04.21 > > /usr/local/bin/php-cgi > > 65534 57833 47240 0 4 0 183352 83316 sbwait I ??0:28.62 > > /usr/local/bin/php-cgi > > 65534 57866 47240 0 4 0 182328 79952 sbwait I ??0:05.92 > > /usr/local/bin/php-cgi > > 65534 57870 47240 0 4 0 182328 83184 sbwait I ??0:56.83 > > /usr/local
Re: php-cgi frozen with sbwait when SMP enable
Ken Chen wrote: > Oh.. sorry, I forgot to provide the information of my environment. > > web4# php-cgi -v > PHP 5.2.6 (cgi-fcgi) (built: Nov 2 2008 11:16:30) > Copyright (c) 1997-2008 The PHP Group > Zend Engine v2.2.0, Copyright (c) 1998-2008 Zend Technologies > with XCache v1.2.2, Copyright (c) 2005-2007, by mOo > web4# /usr/local/lighttpd/sbin/lighttpd -v > lighttpd-1.4.19 - a light and fast webserver > Build-Date: Sep 1 2008 16:58:51 > web4# uname -a > FreeBSD web4..com 7.0-RELEASE-p5 FreeBSD 7.0-RELEASE-p5 #11: Mon Nov 3 > 01:10:36 CST 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/WEB4 i386 > web4# ps alx | grep php-cgi | grep -v grep | grep sbwait > 65534 57776 47240 0 4 0 182328 84984 sbwait I ??2:02.12 > /usr/local/bin/php-cgi > 65534 57801 47240 0 4 0 182328 82408 sbwait I ??0:19.97 > /usr/local/bin/php-cgi > 65534 57809 47240 0 4 0 182328 84096 sbwait I ??1:12.03 > /usr/local/bin/php-cgi > 65534 57823 47240 0 4 0 182328 84492 sbwait I ??2:04.21 > /usr/local/bin/php-cgi > 65534 57833 47240 0 4 0 183352 83316 sbwait I ??0:28.62 > /usr/local/bin/php-cgi > 65534 57866 47240 0 4 0 182328 79952 sbwait I ??0:05.92 > /usr/local/bin/php-cgi > 65534 57870 47240 0 4 0 182328 83184 sbwait I ??0:56.83 > /usr/local/bin/php-cgi > 65534 57871 47240 0 4 0 182328 83388 sbwait I ??0:54.96 > /usr/local/bin/php-cgi > 65534 57891 47240 0 4 0 182328 84436 sbwait I ??1:58.32 > /usr/local/bin/php-cgi > 65534 57925 47240 0 4 0 182328 84380 sbwait I ??2:03.53 > /usr/local/bin/php-cgi > 65534 65944 47240 0 4 0 182328 84184 sbwait I ??0:39.97 > /usr/local/bin/php-cgi > 65534 65952 47240 0 4 0 182328 84408 sbwait I ??0:21.37 > /usr/local/bin/php-cgi This does seem a bit unusual, but seeing that your execution times are not null it might that the PHP servers are actually doing some useful work. You should have a mixture of various states in PHP - do they show up in top? My own example is: last pid: 77421; load averages: 2.82, 2.59, 2.13 up 55+16:58:49 15:48:16 209 processes: 2 running, 206 sleeping, 1 zombie CPU: 49.8% user, 0.0% nice, 2.8% system, 0.0% interrupt, 47.4% idle Mem: 1493M Active, 1583M Inact, 278M Wired, 139M Cache, 112M Buf, 505M Free Swap: 4500M Total, 416M Used, 4084M Free, 9% Inuse PID USERNAME THR PRI NICE SIZERES STATE C TIME WCPU COMMAND 75863 www 1 4 0 162M 50020K sbwait 3 2:54 36.77% php-cgi 76830 www 1 103 0 156M 41556K CPU2 3 1:28 36.77% php-cgi 76834 www 1 4 0 163M 56628K sbwait 0 2:23 33.59% php-cgi 76019 www 1 4 0 150M 38948K accept 3 3:12 20.56% php-cgi 76825 www 1 4 0 158M 42912K accept 2 1:21 18.16% php-cgi 76846 www 1 4 0 162M 42600K sbwait 1 1:07 14.36% php-cgi 76835 www 1 4 0 151M 39948K accept 2 1:28 12.60% php-cgi 76829 www 1 40 150M 36564K sbwait 2 1:46 2.98% php-cgi This is unusually high load, a spike, for this server but it has many cores and it's stable. It's also running 7.1-PRERELEASE. signature.asc Description: OpenPGP digital signature
Re: php-cgi frozen with sbwait when SMP enable
Hi Jeremy, A health FastCGI process have a lifetime, so the PIDs of all php-cgi processes should in a short range. There are some 'php-cgi' fall in 'sbwait' state, and stay there forever. The frozen 'php-cgi' can't accept new request, so never retire. Please forgive my poor English. 2008/11/7 Jeremy Chadwick <[EMAIL PROTECTED]> > On Fri, Nov 07, 2008 at 07:29:37PM +0800, Ken Chen wrote: > > Hello, > > > > I have 4 web servers with lighttpd to serve one web site with DNS load > > sharing. On the 2 SMP-enable web servers, there will be many php-cgi > frozen > > in 'sbwait' state every day. It means the php-cgi stay in 'sbwait' state, > > and never be back to 'accept' or other state. If I restart them, there > will > > be frozen php-cgi appear some hours later. > > > > There is no problem on the other single CPU web servers which running > same > > php scripts and same configuration and version of PHP. > > > > Why and any solution? > > I'm not understanding what the problem is (and I've seen the output you > provided later in the thread). Are you stating the problem is that you > see many php-cgi processes? Or are you worried they're not doing > anything? Does the website function, lock up, or anything like that? > If not, what's the issue? :-) > > -- > | Jeremy Chadwickjdc at parodius.com | > | Parodius Networking http://www.parodius.com/ | > | UNIX Systems Administrator Mountain View, CA, USA | > | 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 "[EMAIL PROTECTED]"
Re: php-cgi frozen with sbwait when SMP enable
On Fri, Nov 07, 2008 at 07:29:37PM +0800, Ken Chen wrote: > Hello, > > I have 4 web servers with lighttpd to serve one web site with DNS load > sharing. On the 2 SMP-enable web servers, there will be many php-cgi frozen > in 'sbwait' state every day. It means the php-cgi stay in 'sbwait' state, > and never be back to 'accept' or other state. If I restart them, there will > be frozen php-cgi appear some hours later. > > There is no problem on the other single CPU web servers which running same > php scripts and same configuration and version of PHP. > > Why and any solution? I'm not understanding what the problem is (and I've seen the output you provided later in the thread). Are you stating the problem is that you see many php-cgi processes? Or are you worried they're not doing anything? Does the website function, lock up, or anything like that? If not, what's the issue? :-) -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | 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 "[EMAIL PROTECTED]"
Re: php-cgi frozen with sbwait when SMP enable
Oh.. sorry, I forgot to provide the information of my environment. web4# php-cgi -v PHP 5.2.6 (cgi-fcgi) (built: Nov 2 2008 11:16:30) Copyright (c) 1997-2008 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2008 Zend Technologies with XCache v1.2.2, Copyright (c) 2005-2007, by mOo web4# /usr/local/lighttpd/sbin/lighttpd -v lighttpd-1.4.19 - a light and fast webserver Build-Date: Sep 1 2008 16:58:51 web4# uname -a FreeBSD web4..com 7.0-RELEASE-p5 FreeBSD 7.0-RELEASE-p5 #11: Mon Nov 3 01:10:36 CST 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/WEB4 i386 web4# ps alx | grep php-cgi | grep -v grep | grep sbwait 65534 57776 47240 0 4 0 182328 84984 sbwait I ??2:02.12 /usr/local/bin/php-cgi 65534 57801 47240 0 4 0 182328 82408 sbwait I ??0:19.97 /usr/local/bin/php-cgi 65534 57809 47240 0 4 0 182328 84096 sbwait I ??1:12.03 /usr/local/bin/php-cgi 65534 57823 47240 0 4 0 182328 84492 sbwait I ??2:04.21 /usr/local/bin/php-cgi 65534 57833 47240 0 4 0 183352 83316 sbwait I ??0:28.62 /usr/local/bin/php-cgi 65534 57866 47240 0 4 0 182328 79952 sbwait I ??0:05.92 /usr/local/bin/php-cgi 65534 57870 47240 0 4 0 182328 83184 sbwait I ??0:56.83 /usr/local/bin/php-cgi 65534 57871 47240 0 4 0 182328 83388 sbwait I ??0:54.96 /usr/local/bin/php-cgi 65534 57891 47240 0 4 0 182328 84436 sbwait I ??1:58.32 /usr/local/bin/php-cgi 65534 57925 47240 0 4 0 182328 84380 sbwait I ??2:03.53 /usr/local/bin/php-cgi 65534 65944 47240 0 4 0 182328 84184 sbwait I ??0:39.97 /usr/local/bin/php-cgi 65534 65952 47240 0 4 0 182328 84408 sbwait I ??0:21.37 /usr/local/bin/php-cgi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: php-cgi frozen with sbwait when SMP enable
Ken Chen wrote: > Hello, > > I have 4 web servers with lighttpd to serve one web site with DNS load > sharing. On the 2 SMP-enable web servers, there will be many php-cgi frozen > in 'sbwait' state every day. It means the php-cgi stay in 'sbwait' state, > and never be back to 'accept' or other state. If I restart them, there will > be frozen php-cgi appear some hours later. You didn't give any information about your environment, specifically versions of FreeBSD, PHP and lighttpd you use, and in what way you use PHP (I'm guessing you're using FastCGI). > There is no problem on the other single CPU web servers which running same > php scripts and same configuration and version of PHP. > > Why and any solution? AFAIK sbwait is socket buffer wait, meaning the process is waiting for some data over a socket (and, in your case, it's not getting it). I'm using php-cgi in FastCGI mode (with mod_fcgid on Apache) on about a dozen servers, all SMP, without problems. Some Apaches are worker-threaded and some use the event MPM. It very much looks like your problem could be a bug in lighttpd. signature.asc Description: OpenPGP digital signature
php-cgi frozen with sbwait when SMP enable
Hello, I have 4 web servers with lighttpd to serve one web site with DNS load sharing. On the 2 SMP-enable web servers, there will be many php-cgi frozen in 'sbwait' state every day. It means the php-cgi stay in 'sbwait' state, and never be back to 'accept' or other state. If I restart them, there will be frozen php-cgi appear some hours later. There is no problem on the other single CPU web servers which running same php scripts and same configuration and version of PHP. Why and any solution? Thanks! Regards, Ken ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: minimizing downtime on upgrades? (for example: mysql 4.1 -> 5.0 or php)
Chuck Swiger wrote: On May 22, 2007, at 12:03 PM, Olivier Mueller wrote: So I can only do that after the installation of mysql50-client, which means all the services will have to be stopped during the compilation of mysql50-server, which usually takes some time. Isn't there a better way? How do you handle such cases? Pretty much as you suggest below: Same questions for php upgrades: on php5 upgrade, all the other php5-* packages have to be compiled too, and keeping the webserver running during this time is probably not the best idea. What I'm going to try is to prepare packages of the ports I have to upgrade on a dev/test server, and then install them with pkg_add: is that the "right way" ? You have a build box that you generate new tarballs of the packages you want to update (via "make package", "make package-recursive", "portupgrade -p", etc), which you can then test and make sure they behave sensibly, and then use these to rapidly update your production machines with minimal downtime. I have found that the ports-mgmt/tinderbox port is very useful for building and maintaining up to date packages with custom patchs, or non default knobs set. I have a pair of dedicated build servers that it runs on but I cant see a reason why it could not run on any old system on your network. You can then use pkg_add/pkg_delete to do the upgrade very quickly. Tom ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: minimizing downtime on upgrades? (for example: mysql 4.1 -> 5.0 or php)
Olivier Mueller wrote: > Isn't there a better way? How do you handle such cases? We go to extra lengths and allow only pkg installs on servers. That way we are sure, that no random library pollution takes place. It also makes stuff better reproducable. Sadly packages are somewhat neclected and there is still no good pkg_update tool > What I'm going to try is to prepare packages of the ports I have to > upgrade on a dev/test server, and then install them with pkg_add: is > that the "right way" ? A good way would be to test this very update with packages on a test box. That is, install mysql4, produce your mysql5 packages somewhere else (or use a chroot or jail). Then see if pkg-updating works for mysql. Ulrich Spoerlein -- "The trouble with the dictionary is you have to know how the word is spelled before you can look it up to see how it is spelled." -- Will Cuppy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: minimizing downtime on upgrades? (for example: mysql 4.1 -> 5.0 or php)
On May 22, 2007, at 12:03 PM, Olivier Mueller wrote: So I can only do that after the installation of mysql50-client, which means all the services will have to be stopped during the compilation of mysql50-server, which usually takes some time. Isn't there a better way? How do you handle such cases? Pretty much as you suggest below: Same questions for php upgrades: on php5 upgrade, all the other php5-* packages have to be compiled too, and keeping the webserver running during this time is probably not the best idea. What I'm going to try is to prepare packages of the ports I have to upgrade on a dev/test server, and then install them with pkg_add: is that the "right way" ? You have a build box that you generate new tarballs of the packages you want to update (via "make package", "make package-recursive", "portupgrade -p", etc), which you can then test and make sure they behave sensibly, and then use these to rapidly update your production machines with minimal downtime. -- -Chuck ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: minimizing downtime on upgrades? (for example: mysql 4.1 -> 5.0 or php)
On 05/22/07 21:03, Olivier Mueller wrote: Some "freebsd-beginner" questions about how to maintain a production server up to date day after day, with a practical example: now I have to update a 6.1-based server from mysql 4.1 to mysql 5.0, minimizing the downtime during the upgrade. In the past under other OS'es I would have taken the mysql source, compiled the whole, and then on upgrade time: - stopped the services (httpd, etc.) - mysqldump of all tables - stopped mysqld - removed the old version (+backup) - 'make install'ed the new one - started mysqld - imported the db and restarted the other services -> 2-3 minutes downtime, depending on the size of the databases Now I can't really do that under FreeBSD: if I want to prepare (just "make" in the ports directory) the mysql50-server part, it answers: Oliver, try something like: portupgrade -o databases/mysql50-client mysql-client portupgrade -o databases/mysql50-server mysql-server Make sure you're doing a backup of your SQL data *before* you're doing this as the MySQL server (AFAIR) is being halted at upgrade time (short after compiling everything has finished). The portupgrade commands mentioned above might just be half of the work as other ports might need an upgrade, too. I did the same some weeks ago but can't remember if there was any extra work needed. HTH Volker ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
minimizing downtime on upgrades? (for example: mysql 4.1 -> 5.0 or php)
Hello, Some "freebsd-beginner" questions about how to maintain a production server up to date day after day, with a practical example: now I have to update a 6.1-based server from mysql 4.1 to mysql 5.0, minimizing the downtime during the upgrade. In the past under other OS'es I would have taken the mysql source, compiled the whole, and then on upgrade time: - stopped the services (httpd, etc.) - mysqldump of all tables - stopped mysqld - removed the old version (+backup) - 'make install'ed the new one - started mysqld - imported the db and restarted the other services -> 2-3 minutes downtime, depending on the size of the databases Now I can't really do that under FreeBSD: if I want to prepare (just "make" in the ports directory) the mysql50-server part, it answers: [EMAIL PROTECTED] /usr/ports/databases/mysql50-server]# make ===> mysql-server-5.0.41 cannot install: MySQL versions mismatch: mysql41-client is installed and wanted version is mysql50-client. *** Error code 1 Stop in /usr/ports/databases/mysql50-server. So I can only do that after the installation of mysql50-client, which means all the services will have to be stopped during the compilation of mysql50-server, which usually takes some time. Isn't there a better way? How do you handle such cases? Same questions for php upgrades: on php5 upgrade, all the other php5-* packages have to be compiled too, and keeping the webserver running during this time is probably not the best idea. What I'm going to try is to prepare packages of the ports I have to upgrade on a dev/test server, and then install them with pkg_add: is that the "right way" ? Thanks in advance for your advices & regards, Olivier ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: php apache2 config
Try commenting out the line for 'doc_root' in your php.ini Matthew Herzog wrote: When I load a file named php4.info I can see all my php build information. If I change that same file's name to phpinfo.php, I get a "premature end of script headers" error. The file contains this text only: and is owned by apache. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]" cheers, -- Rob Dosogne Systems Administrator http://www.truthsolo.net/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: php apache2 config
Matthew Herzog wrote: When I load a file named php4.info I can see all my php build information. If I change that same file's name to phpinfo.php, I get a "premature end of script headers" error. The file contains this text only: and is owned by apache. This is purely a guess since I know nothing about php or apache... Is phpinfo() causing a recursive call to phpinfo.php by chance? Graham ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: php apache2 config
- Matthew Herzog <[EMAIL PROTECTED]> wrote: > When I load a file named php4.info I can see all my php build > information. > > If I change that same file's name to phpinfo.php, I get a "premature > end of script headers" > error. The file contains this text only: > > phpinfo(); > ?> > > and is owned by apache. This posting does not seem FreeBSD related, or even contain a question. I guess you want to fix your PHP install. It appears that your configuration is incorrect. Tom ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
php apache2 config
When I load a file named php4.info I can see all my php build information. If I change that same file's name to phpinfo.php, I get a "premature end of script headers" error. The file contains this text only: and is owned by apache. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: php in free(): error: junk pointer, too high to make sense - SOLVED
On Thursday 23 November 2006 16:52, Ivan Voras wrote: > Dominik Zalewski wrote: > > Hi All, > > > > I'm using FreeBSD 6.1 release on i386. I have a problem with pear and > > apache. Here is what I'm getting: > > > > [EMAIL PROTECTED] ~]# pear list > > Installed packages, channel pear.php.net: > > = > > PackageVersion State > > Archive_Tar1.3.1 stable > > Console_Getopt 1.2 stable > > DB 1.7.6 stable > > Date 1.4.7 stable > > Log 1.9.9 stable > > PEAR 1.4.11 stable > > XML_RPC1.5.0 stable > > php in free(): error: junk pointer, too high to make sense > > Abort trap: 6 (core dumped) > > > > apache 2.2.3 and php-4.4.4_1 is working fine but everytime I restart it > > throws core dump. > > > > Any ideas? > > See a recent thread in freebsd-ports mailing list. It may be related to > a known problem with PHP which is exposed by certain ordering of > extensions in extensions.ini. Try reversing the order of extensions, put > session extension on the top, just before mysql or something else - > there doesn't seem to be a rule about it. > > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "[EMAIL PROTECTED]" I deinstall php4-recode packge , restarted apache and the problem gone ! No more core dumps from pear and apache :) I found solution here: http://www.takizo.com/blog/category/php/ Looks like with php5 it cause problems too but I didnt test it. Thank you, Dominik ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: php in free(): error: junk pointer, too high to make sense
Dominik Zalewski wrote: > Hi All, > > I'm using FreeBSD 6.1 release on i386. I have a problem with pear and apache. > Here is what I'm getting: > > [EMAIL PROTECTED] ~]# pear list > Installed packages, channel pear.php.net: > = > PackageVersion State > Archive_Tar1.3.1 stable > Console_Getopt 1.2 stable > DB 1.7.6 stable > Date 1.4.7 stable > Log1.9.9 stable > PEAR 1.4.11 stable > XML_RPC1.5.0 stable > php in free(): error: junk pointer, too high to make sense > Abort trap: 6 (core dumped) > > apache 2.2.3 and php-4.4.4_1 is working fine but everytime I restart it > throws > core dump. > > Any ideas? > See a recent thread in freebsd-ports mailing list. It may be related to a known problem with PHP which is exposed by certain ordering of extensions in extensions.ini. Try reversing the order of extensions, put session extension on the top, just before mysql or something else - there doesn't seem to be a rule about it. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: php in free(): error: junk pointer, too high to make sense
Dominik Zalewski wrote: > I'm using FreeBSD 6.1 release on i386. I have a problem with pear and apache. > Here is what I'm getting: > > [EMAIL PROTECTED] ~]# pear list > Installed packages, channel pear.php.net: > = > PackageVersion State > Archive_Tar1.3.1 stable > Console_Getopt 1.2 stable > DB 1.7.6 stable > Date 1.4.7 stable > Log1.9.9 stable > PEAR 1.4.11 stable > XML_RPC1.5.0 stable > php in free(): error: junk pointer, too high to make sense > Abort trap: 6 (core dumped) > > apache 2.2.3 and php-4.4.4_1 is working fine but everytime I restart it > throws > core dump. > > Any ideas? I have seen this with PHP for a long time, with PHP 4.x-5.x. While it isn't the exact same context in which you're getting the error, the source may be the same. After I rebuild PHP extensions and restart Apache (1.3 or 2.2, doesn't matter which) or invoke PHP from the command line, PHP crashes and/or takes Apache down with it. Here are the errors that tend to show up for me: * exited on signal 11 (core dumped) * exited on signal 6 (core dumped) * seg fault or similar nasty error detected in the parent process * httpd in free(): error: junk pointer, too high to make sense I'm not sure if it's a problem inherent to how the ports system builds and installs the extensions or if it's just a problem in general. I had read somewhere that rebuilding extensions in a certain order would fix it. However, after some experimenting I found that rebuilding the extensions doesn't really matter, but the order of the extensions being loaded does. Rebuilding fixed it because when a php extension port is rebuilt, it gets placed at the end of extensions.ini. I solved the problem by editing /usr/local/etc/php/extensions.ini and placing the lines for mysql, imap, and sockets at the end and in that order: ... extension=mysql.so extension=imap.so extension=sockets.so I'm not sure if the conflict is only with those three, or with others as well, but that fixes it on my servers. I tried it on three different setups, and before the change they all crashed and after the change they're all running OK. I was never sure if I should file a PR about it because it could easily be a PHP problem and have nothing to do with FreeBSD or the ports system specifically. I haven't had time to research it any more to get enough information to figure out where the problem lies and with whom the bug report should be filed (i.e. try building directly and not from ports, install Fedora and try there, etc) Hope this helps! If not, it will at least be in the archives for future searches. Jim ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
php in free(): error: junk pointer, too high to make sense
Hi All, I'm using FreeBSD 6.1 release on i386. I have a problem with pear and apache. Here is what I'm getting: [EMAIL PROTECTED] ~]# pear list Installed packages, channel pear.php.net: = PackageVersion State Archive_Tar1.3.1 stable Console_Getopt 1.2 stable DB 1.7.6 stable Date 1.4.7 stable Log1.9.9 stable PEAR 1.4.11 stable XML_RPC1.5.0 stable php in free(): error: junk pointer, too high to make sense Abort trap: 6 (core dumped) apache 2.2.3 and php-4.4.4_1 is working fine but everytime I restart it throws core dump. Any ideas? Thank you in advance, Dominik ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: linux locales to freebsd: symlink to make php setlocale() happy ?
Olivier Mueller wrote: > While moving some more customers from a linux to a freebsd-based > hosting, like some others I had a problem with php pages using > setlocale(). > > According to 'locale -a', it looks like that for de_DE (german): > > Linux (suse): >de_DE >de_DE.utf8 >[EMAIL PROTECTED] > > FreeBSD (6.1): >de_DE.ISO8859-1 >de_DE.ISO8859-15 >de_DE.UTF-8 There's no standard for locale names (and it shouldn't be necessary anyway). > And in the customers code, the call which hadn't worked anymore is: > setlocale (LC_ALL, '[EMAIL PROTECTED]', 'de_DE', 'de', 'ge'). It's bad design to hardcode locale names in programs. It's much better (and standard practice) to pick up the locale from the environment variables, so they can be configured in the environment, without having to hack the program. > I could tell the customer to update his code and add "de_DE.ISO8859-1" > to his setlocale() list, You could also tell the customer to fix that crap and use environment variables. :-) > but he will ask me "why isn't it like before?" The answer is "because your program was written in a non- portable way and needs to be fixed". > So what would be the "cleanest" solution? The cleanest solution is certainly to fix the program. > Is there an options somewhere > to add the "standard" de_DE-like label (xx_XX) to all languages? Not that I'm aware of. It's not a standard anyway, and I even consider it bad practice because the character set specification is missing, so it's ambiguous. > Or should I use symlinks like: > [EMAIL PROTECTED] /usr/share/locale]# ln -s de_DE.ISO8859-1 de_DE Well, that would be a work-around that should work. It's not really a "clean solution", though. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "If you aim the gun at your foot and pull the trigger, it's UNIX's job to ensure reliable delivery of the bullet to where you aimed the gun (in this case, Mr. Foot)." -- Terry Lambert, FreeBSD-hackers mailing list. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
linux locales to freebsd: symlink to make php setlocale() happy ?
Bonjour, While moving some more customers from a linux to a freebsd-based hosting, like some others I had a problem with php pages using setlocale(). According to 'locale -a', it looks like that for de_DE (german): Linux (suse): de_DE de_DE.utf8 [EMAIL PROTECTED] FreeBSD (6.1): de_DE.ISO8859-1 de_DE.ISO8859-15 de_DE.UTF-8 And in the customers code, the call which hadn't worked anymore is: setlocale (LC_ALL, '[EMAIL PROTECTED]', 'de_DE', 'de', 'ge'). I could tell the customer to update his code and add "de_DE.ISO8859-1" to his setlocale() list, but he will ask me "why isn't it like before?" and on systems with hundreds of virtualhosts (and different customers), this can't really be done. So what would be the "cleanest" solution? Is there an options somewhere to add the "standard" de_DE-like label (xx_XX) to all languages? Or should I use symlinks like: [EMAIL PROTECTED] /usr/share/locale]# ln -s de_DE.ISO8859-1 de_DE Regards, Olivier ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
php 4 update - SOLVED
I just needed to put a line in /usr/local/etc/portaudit.conf and regenerate portaudit db. from portaudit.conf: # this vulnerability has been fixed in your FreeBSD version portaudit_fixed="edabe438-542f-11db-a5ae-00508d6a62df" and then: portaudit -Fda && portupgrade php4 Done :) I found solution at: http://ezine.daemonnews.org/200501/freebsd_apps.html Thanks anyway, Dominik ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: php on 5.4
You need to give the command 'bt' to gdb for some usefull output. bt stands for backtrace. Ronald. On Wed, 01 Jun 2005 18:11:54 +0200, Steve Rieger <[EMAIL PROTECTED]> wrote: hi all am wondering is anybody else thats running fbsd 5.4 php4 apache1, and about 10 php extensions, are noticing any issues when i run anything via php command line it cores, and the gdb gives me this from the core file 55F_10_25_4_27# gdb /usr/local/bin/php php.core GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd"...(no debugging symbols found)... Core was generated by `php'. Program terminated with signal 6, Aborted. Reading symbols from /usr/local/lib/libcrypto.so.3...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libcrypto.so.3 Reading symbols from /usr/local/lib/libssl.so.3...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libssl.so.3 Reading symbols from /lib/libcrypt.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/libcrypt.so.2 Reading symbols from /lib/libm.so.3...(no debugging symbols found)...done. Loaded symbols for /lib/libm.so.3 Reading symbols from /lib/libc.so.5...(no debugging symbols found)...done. Loaded symbols for /lib/libc.so.5 Reading symbols from /usr/lib/libstdc++.so.4...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libstdc++.so.4 Reading symbols from /usr/local/lib/php/20020429/interbase.so...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/php/20020429/interbase.so Reading symbols from /usr/local/lib/libfbembed.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libfbembed.so.1 Reading symbols from /lib/libncurses.so.5...(no debugging symbols found)...done. Loaded symbols for /lib/libncurses.so.5 Reading symbols from /libexec/ld-elf.so.1...(no debugging symbols found)...done. Loaded symbols for /libexec/ld-elf.so.1 #0 0x2838237b in kill () from /lib/libc.so.5 (gdb) Quit -- Steve Rieger (212) 804-1131 (Work) (646) 335-8915 (Cell) chozrim (aim) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]" -- Ronald Klop Amsterdam, The Netherlands ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
php on 5.4
hi all am wondering is anybody else thats running fbsd 5.4 php4 apache1, and about 10 php extensions, are noticing any issues when i run anything via php command line it cores, and the gdb gives me this from the core file 55F_10_25_4_27# gdb /usr/local/bin/php php.core GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd"...(no debugging symbols found)... Core was generated by `php'. Program terminated with signal 6, Aborted. Reading symbols from /usr/local/lib/libcrypto.so.3...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libcrypto.so.3 Reading symbols from /usr/local/lib/libssl.so.3...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libssl.so.3 Reading symbols from /lib/libcrypt.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/libcrypt.so.2 Reading symbols from /lib/libm.so.3...(no debugging symbols found)...done. Loaded symbols for /lib/libm.so.3 Reading symbols from /lib/libc.so.5...(no debugging symbols found)...done. Loaded symbols for /lib/libc.so.5 Reading symbols from /usr/lib/libstdc++.so.4...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libstdc++.so.4 Reading symbols from /usr/local/lib/php/20020429/interbase.so...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/php/20020429/interbase.so Reading symbols from /usr/local/lib/libfbembed.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libfbembed.so.1 Reading symbols from /lib/libncurses.so.5...(no debugging symbols found)...done. Loaded symbols for /lib/libncurses.so.5 Reading symbols from /libexec/ld-elf.so.1...(no debugging symbols found)...done. Loaded symbols for /libexec/ld-elf.so.1 #0 0x2838237b in kill () from /lib/libc.so.5 (gdb) Quit -- Steve Rieger (212) 804-1131 (Work) (646) 335-8915 (Cell) chozrim (aim) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
apache php child pid exit signal Bus error (10)
Hello,
I just upgraded a lot of ports on a 4.9-STABLE machine and many php
scripts will not run. phpinfo() works but most scripts kill apache and
the following is on httpd-error.log
[Tue Feb 22 04:30:33 2005] [notice] child pid 92055 exit signal Bus
error (10)
[Tue Feb 22 04:30:46 2005] [notice] child pid 92056 exit signal Bus
error (10)
httpd in free(): warning: junk pointer, too high to make sense
[Tue Feb 22 04:30:47 2005] [notice] child pid 92105 exit signal Bus
error (10)
This is all on a FreeBSD 4.9-STABLE #0: Thu Oct 30 18:26:33 GMT 2003
apache+mod_ssl-1.3.33+2.8.22 The Apache 1.3 webserver with SSL/TLS
functionality
apache-ant-1.6.2Java- and XML-based build tool, conceptually similar
to mak
php4-4.3.10_2 PHP Scripting Language (Apache Module and CLI)
This server has an uptime of 466 days, 8:06, 4 users, load averages:
2.05, 2.21, 2.12
I tried to start apache with truss and all I can see is that the line
below looks suspicious but other than that I have no ideas...
How can I provide more information?
How can I trace the httpd child processes? Should I?
Before I put in the DNS request to switch over to the
yet-untested-in-real-life backup server can someone tell me how to get
apache php working again on this machine before all my users wake up?
Thanks!
stat("/var/run/httpd.pid",0xbfbff700) ERR#2 'No such file or directory'
truss -o help.log /usr/local/sbin/apachectl startssl
getpid() = 91339 (0x164cb)
geteuid()= 0 (0x0)
getppid()= 91337 (0x164c9)
readlink("/etc/malloc.conf","J",63) = 1 (0x1)
mmap(0x0,4096,0x3,0x1002,-1,0x0) = 671817728 (0x280b2000)
break(0x80c1000) = 0 (0x0)
break(0x80c2000) = 0 (0x0)
stat("/var/mail/root",0xbfbff9d0) ERR#2 'No such file or directory'
getuid() = 0 (0x0)
geteuid()= 0 (0x0)
getgid() = 0 (0x0)
getegid()= 0 (0x0)
open("/usr/local/sbin/apachectl",0x0,01002652540) = 4 (0x4)
fcntl(0x4,0x0,0xa) = 10 (0xa)
close(4) = 0 (0x0)
fcntl(0xa,0x2,0x1) = 0 (0x0)
sigaction(SIGINT,0x0,0xbfbff9c8) = 0 (0x0)
sigaction(SIGINT,0xbfbff9c8,0xbfbff9b0) = 0 (0x0)
sigaction(SIGINT,0x0,0xbfbff9c8) = 0 (0x0)
sigaction(SIGINT,0xbfbff9c8,0x0) = 0 (0x0)
sigaction(SIGQUIT,0x0,0xbfbff9b8)= 0 (0x0)
sigaction(SIGQUIT,0xbfbff9b8,0xbfbff9a0) = 0 (0x0)
sigaction(SIGQUIT,0x0,0xbfbff9b8)= 0 (0x0)
sigaction(SIGQUIT,0xbfbff9b8,0x0)= 0 (0x0)
sigaction(SIGTERM,0x0,0xbfbff9c8)= 0 (0x0)
sigaction(SIGTERM,0xbfbff9c8,0xbfbff9b0) = 0 (0x0)
sigaction(SIGWINCH,0x0,0xbfbff9b8) = 0 (0x0)
sigaction(SIGWINCH,0xbfbff9b8,0xbfbff9a0)= 0 (0x0)
sigaction(SIGSYS,0xbfbff538,0xbfbff520) = 0 (0x0)
__getcwd(0xbfbff6a0,0x400) = 0 (0x0)
sigaction(SIGSYS,0xbfbff520,0x0) = 0 (0x0)
read(0xa,0x80bee20,0x3ff)= 1023 (0x3ff)
read(0xa,0x80bee20,0x3ff)= 1023 (0x3ff)
break(0x80c3000) = 0 (0x0)
read(0xa,0x80bee20,0x3ff)= 1023 (0x3ff)
stat("/sbin/limits",0xbfbff660)ERR#2 'No such file or
directory'
stat("/usr/sbin/limits",0xbfbff660)ERR#2 'No such file or directory'
stat("/bin/limits",0xbfbff660) ERR#2 'No such file or
directory'
stat("/usr/bin/limits",0xbfbff660) = 0 (0x0)
break(0x80c4000) = 0 (0x0)
pipe() = 4 (0x4)
fork() = 91405 (0x1650d)
SIGNAL 20
close(5) = 0 (0x0)
read(0x4,0xbfbff850,0x80)= 128 (0x80)
read(0x4,0xbfbff850,0x80)= 103 (0x67)
read(0x4,0xbfbff850,0x80)= 0 (0x0)
close(4) = 0 (0x0)
getpgrp()= 91337 (0x164c9)
wait4(0x,0xbfbff7bc,0x2,0x0) = 91405 (0x1650d)
break(0x80c5000) = 0 (0x0)
fcntl(0x1,0x0,0xa) = 11 (0xb)
open("/dev/null",0x601,0666) = 4 (0x4)
close(1) = 0 (0x0)
fcntl(0x4,0x0,0x1) = 1 (0x1)
close(4)
Re: High CPU-load with apache 1.3.33+mod-ssl, mod-php
On Thu, 2005-02-17 at 09:15 -0500, First Last wrote: > > Hello list, > > > > Im running FreeBSD 5.3 on a 1.4GHz/256mb P4. I've done make buildworld > > and make buildkernel with these options in make.conf: > > > > --- > > # -- use.perl generated deltas -- # > > # Created: Wed Feb 16 14:46:12 2005 > > # Setting to use base perl from ports: > > PERL_VER=5.8.5 > > PERL_VERSION=5.8.5 > > PERL_ARCH=mach > > NOPERL=yo > > NO_PERL=yo > > NO_PERL_WRAPPER=yo > > > > CPUTYPE=p4 > > CFLAGS= -O2 -pipe -funroll-loops -ffast-math > > COPTFLAGS= -O2 -pipe -funroll-loops -ffast-math > > NOPROFILE=true > > --- > > > > I've installed apache13-modssl, mysql41-server, squirrelmail, phpMyAdmin > > and everything that is required for these packages to run. (Everything > > from ports, compiled with the make.conf above). httpd.conf and php.ini and > > other configfiles are stock, unchanged. > > > > Now, everything works like a charm, excpet that whenever i run phpMyAdmin > > or Squirrelmail, the cpu-load gets quite high, and stays high for several > > seconds (7-10) after the page has finished loading. Note that the onlyone > > using the system is my self. > > > > The exact same setup on a linuxsystem doesen't come near the FreeBSDsystem > > in cpuload. > > > Why do you say that's its because of apache, can it be a mysql issue, ?? I didn't notice that apache was blamed. :-) > IS THERE ANYTHING IN DMESG You might try running top when accessing these pages to see what's going on. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: High CPU-load with apache 1.3.33+mod-ssl, mod-php
> Hello list, > > Im running FreeBSD 5.3 on a 1.4GHz/256mb P4. I've done make buildworld > and make buildkernel with these options in make.conf: > > --- > # -- use.perl generated deltas -- # > # Created: Wed Feb 16 14:46:12 2005 > # Setting to use base perl from ports: > PERL_VER=5.8.5 > PERL_VERSION=5.8.5 > PERL_ARCH=mach > NOPERL=yo > NO_PERL=yo > NO_PERL_WRAPPER=yo > > CPUTYPE=p4 > CFLAGS= -O2 -pipe -funroll-loops -ffast-math > COPTFLAGS= -O2 -pipe -funroll-loops -ffast-math > NOPROFILE=true > --- > > I've installed apache13-modssl, mysql41-server, squirrelmail, phpMyAdmin > and everything that is required for these packages to run. (Everything > from ports, compiled with the make.conf above). httpd.conf and php.ini and > other configfiles are stock, unchanged. > > Now, everything works like a charm, excpet that whenever i run phpMyAdmin > or Squirrelmail, the cpu-load gets quite high, and stays high for several > seconds (7-10) after the page has finished loading. Note that the onlyone > using the system is my self. > > The exact same setup on a linuxsystem doesen't come near the FreeBSDsystem > in cpuload. > Why do you say that's its because of apache, can it be a mysql issue, ?? IS THERE ANYTHING IN DMESG ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
High CPU-load with apache 1.3.33+mod-ssl, mod-php
Hello list, Im running FreeBSD 5.3 on a 1.4GHz/256mb P4. I've done make buildworld and make buildkernel with these options in make.conf: --- # -- use.perl generated deltas -- # # Created: Wed Feb 16 14:46:12 2005 # Setting to use base perl from ports: PERL_VER=5.8.5 PERL_VERSION=5.8.5 PERL_ARCH=mach NOPERL=yo NO_PERL=yo NO_PERL_WRAPPER=yo CPUTYPE=p4 CFLAGS= -O2 -pipe -funroll-loops -ffast-math COPTFLAGS= -O2 -pipe -funroll-loops -ffast-math NOPROFILE=true --- I've installed apache13-modssl, mysql41-server, squirrelmail, phpMyAdmin and everything that is required for these packages to run. (Everything from ports, compiled with the make.conf above). httpd.conf and php.ini and other configfiles are stock, unchanged. Now, everything works like a charm, excpet that whenever i run phpMyAdmin or Squirrelmail, the cpu-load gets quite high, and stays high for several seconds (7-10) after the page has finished loading. Note that the onlyone using the system is my self. The exact same setup on a linuxsystem doesen't come near the FreeBSDsystem in cpuload. Anyone got a clue? Thanks! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: mktime() bug? result strtotime() fail in PHP
Hi, Peter Jeremy wrote: Also FreeBSD 5.3-STABLE? I don't have a 5.3-STABLE system to confirm but if it doesn't return -1 it is wrong. Then, it's wrong. What timestamp should it return? 2004-11-02 00:00:00 doesn't exist for you, therefore there is no possible value for seconds since epoch that will convert to this time. The manpage states: until tm_mon and tm_year are determined. The mktime() function returns the specified calendar time; if the calendar time cannot be represented, it returns -1; Since 2004-11-02 00:00:00 cannot be represented, then it should return -1. Maybe you should explain why having mktime() correctly report an error is a problem for you. Because of that: -- Marcus Grando Grupos Internet S/A marcus(at)corp.grupos.com.br ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: mktime() bug? result strtotime() fail in PHP
On Mon, 2005-Feb-14 10:05:50 -0200, Marcus Grando wrote: >Peter Jeremy wrote: >>To be pedantic, FreeBSD 4.11 is correct and the others are wrong. If > ^^ >Also FreeBSD 5.3-STABLE? I don't have a 5.3-STABLE system to confirm but if it doesn't return -1 it is wrong. >>DST started at 2004-11-02 00:00 local time then you can't convert a local >>time of 2004-11-02 00:00:00 because that time doesn't exist - your local >>time goes 2004-11-01 23:59:59, 2004-11-02 01:00:00, 2004-11-02 01:00:01. > >I know, but timestamp return is better of that -1. What timestamp should it return? 2004-11-02 00:00:00 doesn't exist for you, therefore there is no possible value for seconds since epoch that will convert to this time. The manpage states: until tm_mon and tm_year are determined. The mktime() function returns the specified calendar time; if the calendar time cannot be represented, it returns -1; Since 2004-11-02 00:00:00 cannot be represented, then it should return -1. Maybe you should explain why having mktime() correctly report an error is a problem for you. -- Peter Jeremy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: mktime() bug? result strtotime() fail in PHP
On Mon, 14 Feb 2005 22:35, Marcus Grando wrote: > Hi, > > Peter Jeremy wrote: > > To be pedantic, FreeBSD 4.11 is correct and the others are wrong. If > >^^ > Also FreeBSD 5.3-STABLE? > > > DST started at 2004-11-02 00:00 local time then you can't convert a local > > time of 2004-11-02 00:00:00 because that time doesn't exist - your local > > time goes 2004-11-01 23:59:59, 2004-11-02 01:00:00, 2004-11-02 01:00:01. > > I know, but timestamp return is better of that -1. Not really.. You asked it to do an illegal operation. There are 2 choices - 1) return and error, 2) have the computer try and guess what you really meant. 2 leads to all sorts of bad things like other programs working around it to get proper functionality etc.. -- 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 pgpoXbmBMjGdq.pgp Description: PGP signature
Re: mktime() bug? result strtotime() fail in PHP
Hi, Peter Jeremy wrote: To be pedantic, FreeBSD 4.11 is correct and the others are wrong. If ^^ Also FreeBSD 5.3-STABLE? DST started at 2004-11-02 00:00 local time then you can't convert a local time of 2004-11-02 00:00:00 because that time doesn't exist - your local time goes 2004-11-01 23:59:59, 2004-11-02 01:00:00, 2004-11-02 01:00:01. I know, but timestamp return is better of that -1. -- Marcus Grando Grupos Internet S/A marcus(at)corp.grupos.com.br ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: mktime() bug? result strtotime() fail in PHP
On Fri, 2005-Feb-11 21:16:00 -0200, Marcus Grando wrote: >I have problems with mktime() on FreeBSD 4.11-STABLE and daylight timezone. > >My timezone is "America/Sao_Paulo", daylight begin on 2004-11-02 00:00 >and terminate on 2005-02-20 00:00. > >The problem is: >If run this code[1] on FreeBSD 4.11-STABLE, then return -1, if run on >FreeBSD 5.3-STABLE, then return 1099364400 (correct) and if run on >Linux, then return 1099364400 (correct). To be pedantic, FreeBSD 4.11 is correct and the others are wrong. If DST started at 2004-11-02 00:00 local time then you can't convert a local time of 2004-11-02 00:00:00 because that time doesn't exist - your local time goes 2004-11-01 23:59:59, 2004-11-02 01:00:00, 2004-11-02 01:00:01. server% TZ=':/usr/share/zoneinfo/America/Sao_Paulo' perl -e 'print scalar localtime 1099364400,"\n";' Tue Nov 2 01:00:00 2004 server% TZ=':/usr/share/zoneinfo/America/Sao_Paulo' perl -e 'print scalar localtime 1099364399,"\n";' Mon Nov 1 23:59:59 2004 server% -- Peter Jeremy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
mktime() bug? result strtotime() fail in PHP
Hi,
I have problems with mktime() on FreeBSD 4.11-STABLE and daylight timezone.
My timezone is "America/Sao_Paulo", daylight begin on 2004-11-02 00:00
and terminate on 2005-02-20 00:00.
The problem is:
If run this code[1] on FreeBSD 4.11-STABLE, then return -1, if run on
FreeBSD 5.3-STABLE, then return 1099364400 (correct) and if run on
Linux, then return 1099364400 (correct).
In PHP, strtotime() call mktime(), because that return error.
Is a bug on mktime()?
-- code[1] --
#include
#include
int main()
{
struct tm local;
local.tm_sec = 0;
local.tm_min = 0;
local.tm_hour = 0;
local.tm_mday = 2;
local.tm_mon = 10;
local.tm_year = 104;
local.tm_isdst = -1;
printf("%i\n", mktime(&local));
}
-- code[1] --
Regards
--
Marcus Grando
Grupos Internet S/A
marcus(at)corp.grupos.com.br
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: PHP vulnerability and portupgrade
Mark Andrews said: >> Thanks a lot for your reply. If I understand things correctly, I need to >> maintain two cvsup files - one that tracks security issues in the base >> FreeBSD 5.3 system (tag=RELENG_5_3, src-all) and one for the ports >> collection (tag=. , ports-all). Then every time I receive a FreeBSD >> security advisory I run cvsup on the former, and every time portaudit tells >> me about a new security issue in the ports collection, I run cvsup on the >> latter, then use portupgrade to upgrade vulnerable ports. >> >> Is this correct? > > Essentually. When you install portaudit it will be run as > part of the daily periodic jobs provided the FreeBSD version > is new enough (which 5.3 is). Portaudit gets added to the daily periodic scripts on 4.10 also. And contrary to name, portaudit will also watch for vulnerabilities in the base system. For example, the cvs issue from awhile back showed up in my portaudit results. Thus, it's not strictly necessary to always keep your base system source up to date as long as your system is stable and you're watching the portaudit results. -- Charles Ulrich Ideal Solution, LLC - http://www.idealso.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: PHP vulnerability and portupgrade
On Wed, 22 Dec 2004 09:52:01 +0800, Ladislav Bodnar <[EMAIL PROTECTED]> said: > Thanks a lot for your reply. If I understand things correctly, I need to > maintain two cvsup files - one that tracks security issues in the base > FreeBSD 5.3 system (tag=RELENG_5_3, src-all) and one for the ports > collection (tag=. , ports-all). Then every time I receive a FreeBSD > security advisory I run cvsup on the former, and every time portaudit tells > me about a new security issue in the ports collection, I run cvsup on the > latter, then use portupgrade to upgrade vulnerable ports. > > Is this correct? To do it easier, you can set some variables in /etc/make.conf as follows: SUP_UPDATE= yes SUP=/usr/local/bin/cvsup SUPFLAGS= -g -L 2 SUPHOST=cvsup.jp.FreeBSD.org (<- change as you like) SUPFILE=/usr/share/examples/cvsup/stable-supfile PORTSSUPFILE= /usr/share/examples/cvsup/ports-supfile Then type 'make update' in /usr/src. Your source tree will be updated using stable-supfile, and your ports tree will be updated using ports-supfile. Maybe you need to edit stable-supfile to retrieve RELENG_5_3. See /usr/share/examples/etc/make.conf and /usr/share/examples/cvsup/README for the detail. Regards, -- Yoshiaki Kasahara Computing and Communications Center, Kyushu University [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: PHP vulnerability and portupgrade
> On Wednesday 22 December 2004 09:06, Mark Andrews wrote: > > > Hello, > > > > > > Due to the recently discovered vulnerability in PHP versions older than > > > 4.3.10 and 5.0.3, I decided to take a look at portupgrade to see if it > > > is a good way to keep the ports collection up-to-date with respect to > > > security issues. I ran cvsup on the security branch (tag=RELENG_5_3), > > > then portsdb -Uu. However, portupgrade didn't find any ports that > > > needed an upgrade. > > > > > > Am I doing something wrong or is portupgrade not the best tool to keep > > > up with security advisories in ports? > > > > cvsup of ports does not use tag=RELENG_5_3. > > > > e.g. > > *default host=cvsup.FreeBSD.org > > *default base=/usr > > *default prefix=/usr > > *default release=cvs > > *default delete use-rel-suffix > > *default tag=. > > ports-all > > > > Use portaudit to track security issues in ports. > > Thanks a lot for your reply. If I understand things correctly, I need to > maintain two cvsup files - one that tracks security issues in the base > FreeBSD 5.3 system (tag=RELENG_5_3, src-all) and one for the ports > collection (tag=. , ports-all). Then every time I receive a FreeBSD > security advisory I run cvsup on the former, and every time portaudit tells > me about a new security issue in the ports collection, I run cvsup on the > latter, then use portupgrade to upgrade vulnerable ports. > > Is this correct? Essentually. When you install portaudit it will be run as part of the daily periodic jobs provided the FreeBSD version is new enough (which 5.3 is). How you treat each reported issue is up to you. Some do not have a fix yet. You need to decide if you can live with vulnerability or not. > I went through the security chapter of the FreeBSD handbook, but I found it > disappointing that it doesn't explain how to keep a FreeBSD system > up-to-date of security issues. Also, "The Complete FreeBSD" book by Greg > Lehey doesn't even mention the existence of portaudit. > > Thanks again :-) > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "[EMAIL PROTECTED]" -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: PHP vulnerability and portupgrade
On Wednesday 22 December 2004 09:06, Mark Andrews wrote: > > Hello, > > > > Due to the recently discovered vulnerability in PHP versions older than > > 4.3.10 and 5.0.3, I decided to take a look at portupgrade to see if it > > is a good way to keep the ports collection up-to-date with respect to > > security issues. I ran cvsup on the security branch (tag=RELENG_5_3), > > then portsdb -Uu. However, portupgrade didn't find any ports that > > needed an upgrade. > > > > Am I doing something wrong or is portupgrade not the best tool to keep > > up with security advisories in ports? > > cvsup of ports does not use tag=RELENG_5_3. > > e.g. > *default host=cvsup.FreeBSD.org > *default base=/usr > *default prefix=/usr > *default release=cvs > *default delete use-rel-suffix > *default tag=. > ports-all > > Use portaudit to track security issues in ports. Thanks a lot for your reply. If I understand things correctly, I need to maintain two cvsup files - one that tracks security issues in the base FreeBSD 5.3 system (tag=RELENG_5_3, src-all) and one for the ports collection (tag=. , ports-all). Then every time I receive a FreeBSD security advisory I run cvsup on the former, and every time portaudit tells me about a new security issue in the ports collection, I run cvsup on the latter, then use portupgrade to upgrade vulnerable ports. Is this correct? I went through the security chapter of the FreeBSD handbook, but I found it disappointing that it doesn't explain how to keep a FreeBSD system up-to-date of security issues. Also, "The Complete FreeBSD" book by Greg Lehey doesn't even mention the existence of portaudit. Thanks again :-) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: PHP vulnerability and portupgrade
> Hello, > > Due to the recently discovered vulnerability in PHP versions older than > 4.3.10 and 5.0.3, I decided to take a look at portupgrade to see if it is a > good way to keep the ports collection up-to-date with respect to security > issues. I ran cvsup on the security branch (tag=RELENG_5_3), then portsdb > -Uu. However, portupgrade didn't find any ports that needed an upgrade. > > Am I doing something wrong or is portupgrade not the best tool to keep up > with security advisories in ports? cvsup of ports does not use tag=RELENG_5_3. e.g. *default host=cvsup.FreeBSD.org *default base=/usr *default prefix=/usr *default release=cvs *default delete use-rel-suffix *default tag=. ports-all Use portaudit to track security issues in ports. > Thank you for your help :-) > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "[EMAIL PROTECTED]" -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
PHP vulnerability and portupgrade
Hello, Due to the recently discovered vulnerability in PHP versions older than 4.3.10 and 5.0.3, I decided to take a look at portupgrade to see if it is a good way to keep the ports collection up-to-date with respect to security issues. I ran cvsup on the security branch (tag=RELENG_5_3), then portsdb -Uu. However, portupgrade didn't find any ports that needed an upgrade. Am I doing something wrong or is portupgrade not the best tool to keep up with security advisories in ports? Thank you for your help :-) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: php-extensions: How adding additional module?
On Track Technicial Support schrieb:
make config
thanks for that hint!
but what's the best way to upgrade (eg to 4.3.9)?
something like
pkg_info | grep ^php4- | awk '{ print $1}' | xargs portupgrade -b
???
Regards,
Thomas.
I do think that the whole new PHP ports system needs to be re-done. It seems
to have very serious problems. Most notably, there is no way to compile
modules in statically without editing the Makefile (some need to be static
or it causes problems) and there is no working pear support without doing it
manually.
- Original Message -
From: "Thoamas Krause -CI-" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Sunday, August 15, 2004 11:06 AM
Subject: php-extensions: How adding additional module?
Hello,
I've installed php4-4.3.8 and php4-extensions-1.0, but I forgot
xslt support. Is there an easy way to intall php-modules
later?
What I've done, seems not to be the best way:
- pkg_delete php4-extensions-1.0
- edit /var/db/ports/php4/options: changed
WITHOUT_XSLT=true to WITH_XSLT=true
- cd /usr/ports/lang/php4-extensions && make install clean
Regards,
Thomas.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: portupgrade and PHP
Pat Lashley wrote: >> Do you happen to know where I can get the complete list? > > > Copy /usr/ports/lang/php4/scripts/php4_options to /root and edit > it to set your preferred defaults. Ahh, I did a "locate php4-options" which of course won't find "php4_options" Thanks again! ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: portupgrade and PHP
:: > How can I continually compile PHP with the same :: > options as the last time? :: :: Edit /usr/ports/lang/php4/Makefile and change the line :: PHP4_OPTIONS?= according to your needs. Except that the next time you upgrade your ports tree, your changes will be overwritten. Check out the /usr/local/etc/pkgtools.conf file. This is how you can use your own make(1) options using portupgrade consistently. The options you can use for each port can be found in its respective Makefile. Cheers - Erick ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: portupgrade and PHP
Hi. > How can I continually compile PHP with the same > options as the last time? > Edit /usr/ports/lang/php4/Makefile and change the line PHP4_OPTIONS?= according to your needs. regards Claus Yahoo! Mail (http://dk.mail.yahoo.com) - Gratis: 6 MB lagerplads, spamfilter og virusscan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: portupgrade and PHP
On 03 Nov 2003, Rick Updegrove wrote: > When I run portupgrade -ra and PHP needs upgrading I am faced with > having to select all the options I want PHP compiled with (again). I > hate this. > > How can I continually compile PHP with the same options as the last time? If you haven't cvsup'ped your ports in awhile to the latest available, I highly recommend doing so. Check out /usr/ports/lang/php4/Makefile and you'll see different ways to deal with this problem. My Makefile is v 1.32 from 2003/10/13 05:59:45 and has all the scoop on how to avoid this problem. -- Mark Nippere-contacts: Computing and Information Services [EMAIL PROTECTED] Texas A&M Universityhttp://ops.tamu.edu/nipsy/ College Station, TX 77843-3142 AIM/Yahoo: texasnipsy ICQ: 66971617 (979)575-3193 MSN: [EMAIL PROTECTED] -BEGIN GEEK CODE BLOCK- GG/IT d- s++:+ a- C++$ UBL+++$ P--->+++ L+++$ E--- W++ N+ o K++ w(---) O++ M V(--) PS+++(+) PE(--) Y+ PGP++(+) t 5 X R tv b+++ DI+(++) D+ G e h r++ y+(**) --END GEEK CODE BLOCK-- ---begin random quote of the moment--- "We are not enemies, but friends. We must not be enemies. Though passion may have strained, it must not break our bonds of affection. The mystic cords of memory will swell when again touched as surely they will be by the better angels of our nature." -- modified quote of Abraham Lincoln from his first inaugural address, 04 March 1861; taken from "American History X" end random quote of the moment ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
portupgrade and PHP
Hello, When I run portupgrade -ra and PHP needs upgrading I am faced with having to select all the options I want PHP compiled with (again). I hate this. How can I continually compile PHP with the same options as the last time? Thanks! Rick ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: apach_ssl+php(+ipv6), howto?
On Wed, Dec 13, 2000 at 09:58:58PM +0200, Nevermind wrote: > Hello, Hans de Hartog! > > On Wed, Dec 13, 2000 at 07:21:15PM +0100, you wrote: > > > I want apache with ssl, php (and if possible, ipv6). > > If I install apache+mod_ssl and after that mod_php, > > a (re?)install of vanilla apache is done. Do I have > > to worry about that? If I also want apache_ipv6, > > can someone please tell me which packages to install > > (and in what sequence). > That's the way I've done it > > Server Version: Apache/1.3.12 (Unix) PHP/4.0.3pl1 mod_ssl/2.6.6 OpenSSL/0.9.5a >rus/PL29.7 Apache/1.3.14 (Unix) mod_python/2.6.3 Python /2.0 AuthMySQL/2.20 mod_perl/1.24 PHP/4.0.3pl1 PHP/3.0.17 mod_ssl/2.7.1 OpenSSL/0.9.6 (sorry the above is long...) I did it this way: First installed apache13+modssl, but with a minor tweak: Because of mod_perl and perl(1) being configured to handle large files, I added the appropriate parameters to the Makefile (mod_perl will complain in the configuration phase otherwise) and then simply installed mod_php3, mod_php4, mod_perl and mod_python and mod_auth_mysql (I think in that order) from ports *without doing anything special at all*. and it seemed to work. I have not tried ipv6 though. However, if you already installed apache+modssl before from ports, you should take care that the name of the binary and also the docs location etc has changed, you need to update that in the config file. -- Regards: Szilveszter ADAM Szeged University Szeged Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: apach_ssl+php(+ipv6), howto?
Hello, Hans de Hartog! On Wed, Dec 13, 2000 at 07:21:15PM +0100, you wrote: > I want apache with ssl, php (and if possible, ipv6). > If I install apache+mod_ssl and after that mod_php, > a (re?)install of vanilla apache is done. Do I have > to worry about that? If I also want apache_ipv6, > can someone please tell me which packages to install > (and in what sequence). That's the way I've done it Server Version: Apache/1.3.12 (Unix) PHP/4.0.3pl1 mod_ssl/2.6.6 OpenSSL/0.9.5a rus/PL29.7 First I've installed apache with mod_ssl. (I've used diffrent prefix, not standard one) then I've copied apxs to the place, mod_php4 wants it to be. (just look in mod_php4's Makefile. then make configure in mod_php4 then cd to work dir, ./configure width different prefix and make install there (not in ports's tree dir) (Sorry, I maybe need more coffee and I wanna sleep and home, so if my posting won't understood I'll try again tomorrow :>> ) -- Alexandr P. Kovalenko http://nevermind.kiev.ua/ NEVE-RIPE To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
apach_ssl+php(+ipv6), howto?
I want apache with ssl, php (and if possible, ipv6). If I install apache+mod_ssl and after that mod_php, a (re?)install of vanilla apache is done. Do I have to worry about that? If I also want apache_ipv6, can someone please tell me which packages to install (and in what sequence). Thanks for your insight, Hans de Hartog To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Apache/PHP ports
On Fri, Oct 13, 2000 at 10:33:22AM +0200, [EMAIL PROTECTED] wrote: > > The ports system doesn't use symlinks. > > So why don't delete the old one? The files are gone, the directory structure probably remains because of a README.html file or extra stuff left over. I use cvs and not cvsup so I'm not really familiar with what cvsup does with dead directories. -- Bill Fumerola - Network Architect, BOFH / Chimes, Inc. [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Apache/PHP ports
> > And why not symlink apache_php3&4 to mod_php??? > > The ports system doesn't use symlinks. So why don't delete the old one? > > Anyway you time-response is amazing. =) > > I'm a species of the "American night owl". I'm italian and here is 10:30 AM, anyway thanks again =) Paolo To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: apach+ssl+php port
From: "Vincent Poy" <[EMAIL PROTECTED]> > Hmmm, I remember there were some issues about fp extensions back > in November 1999 about DES and MD5 passwords.. > Back in November 1999, we only had the BSDI extentsion, and fpsrvadm.exe was/is compiled statically with the DES libcrypt. This required the Apache server to be compiled statically with libdescrypt, or libcrypt linked to libdescrypt on FreeBSD in order to authenticate Frontpage users. Now that we have the FreeBSD extentsions, fpsrvadm.exe is compiled dynamically with libcrypt. Unfortunately, RTR forgot to test fpsrvadm.exe with libscrypt, thus MD5 passwords didn't work. Scot PS. This doesn't belong on STABLE anymore, so adjust you replies accordingly. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: apach+ssl+php port
From: "fbsd stable" <[EMAIL PROTECTED]> > ... one question though, if i have just the plain > apache-1.3.12 installed and would want to install it > with FP extensions, would i have to uninstall > apache-1.3.12 first then install apache13-fp ?or is it > ok to install the apache13-fp port right away? i am > running FBSD-4.1 stable though ... > To go from apache13 -> apache13-fp: 1. Build the apache13-fp port cd /usr/ports/www/apache13-fp make build 2. Edit /usr/local/etc/apache/httpd.conf, change "AllowOverride: None" to "AllowOverride: All" for the Document Root. NOTE: Needed for fpsrvadm.exe during install. 3. Stop apache13 & uninstall apache13 /usr/local/etc/rc.d/apache.sh stop pkg_delete apache-1.3.12 4. Install apache13-fp make install 5. Compare httpd.conf with httpd.conf-default 6. Start apache13-fp /usr/local/etc/rc.d/apache.sh start Scot To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: apach+ssl+php port
From: "Vincent Poy" <[EMAIL PROTECTED]> > I noticed on your website that both you and Matthew Dodd were > working on Apache and modules: mod_ssl, mod_frontpage, mod_php3, mod_php4, > and mod_jserv. > > Aren't these already available? > mod_jserv (aka apache-jserv), mod_php3, mod_php4 are currently available in the ports collection. mod_frontpage - requires a patched Apache server (from website only) mod_ssl - requires an apache+eapi server (from website only) The ports on the website are a bit out of date, and will require a bit of work to bring them back to fully functional ports. Scot To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: apach+ssl+php port
On Fri, 15 Sep 2000, Scot W. Hetzel wrote: > From: "Vincent Poy" <[EMAIL PROTECTED]> > > > Vincent Poy wrote: > > > > > > > > On Fri, 15 Sep 2000, Bill Moran wrote: > > > > > Thanks to all who responded. That seems to do the trick. I'd forgotten > > > > > all about the mod_* directories. Reminding me of this has probably saved > > > > > me a lot of extra work. > > > > > > > > Okay, here's a question. What happens if one also wants FrontPage > > > > 2000 support in addition to the above? > > With the current ports collection you can't create an > apache-fp-ssl-php installation. Thanks for clarifying that. > > I'm just wondering if it's possible to install the apache13-fp > > port first then add in the modules in the ports collection. > > You can however create an apache-fp-php installation. > > Were working on breaking up the apache13-* ports so that eventually, > you can create an apache-fp-ssl-php installation from the ports > collection. I noticed on your website that both you and Matthew Dodd were working on Apache and modules: mod_ssl, mod_frontpage, mod_php3, mod_php4, and mod_jserv. Aren't these already available? Cheers, Vince - [EMAIL PROTECTED] - Vice President __ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] WurldLink Corporation / / / / | / | __] ] San Francisco - Honolulu - Hong Kong / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[] Almighty1@IRC - oahu.DAL.NET Hawaii's DALnet IRC Network Server Admin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: -lc vs. -lc_r (building Apache-PHP)
On 27-Dec-99 Chris Malayter wrote: > Along this line of problems, > > I am having serious problems compileing a usable apache binary when > compileing modphp with IMAP support. It works fine for me when I just > compile any other service or combination of services. > > Here's the error: > > Configuring for Apache, Version 1.3.9 > + using installation path layout: Apache (config.layout) > + activated php3 module (modules/php3/libphp3.a) Creating Makefile > Creating Configuration.apaci in src Creating Makefile in src > + configured for FreeBSD 3.4 platform > + setting C compiler to gcc > + setting C pre-processor to gcc -E > + checking for system header files > + adding selected modules > o php3_module uses ConfigStart/End > + checking sizeof various data types > + doing sanity check on compiler and options ** A test compilation with > your Makefile configuration ** failed. This is most likely because your C > compiler ** is not ANSI. Apache requires an ANSI C Compiler, such ** as > gcc. The above error message from your compiler ** will also provide a > clue. > Aborting! > venus# Trying this again, hopefully that last one didn't go out (it was content free). I've seen this many times. Part of the problem is that apache's configure script won't pass --verbose to it's helper scripts which only leaves you clueless as to what's happening. If you go into the src directory and and run the following: $ ./helpers/TestCompile -v sanity you'll see the reason why it won't compile. 9 times out of 10 it's caused by a header file in the wrong place - or apache not knowing where it is. I don't recall what I did to fix it, but it was probably something like copying the file to a standard directory or creating a symlink. Vince. -- == Vince Vielhaber -- KA8CSHemail: [EMAIL PROTECTED]http://www.pop4.net 128K ISDN: $24.95/mo or less - 56K Dialup: $17.95/mo or less at Pop4 Online Campground Directoryhttp://www.camping-usa.com Online Giftshop Superstorehttp://www.cloudninegifts.com == To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: -lc vs. -lc_r (building Apache-PHP)
On Mon, 27 Dec 1999, Mikhail Teterin wrote:
...
> What's the magic and why doesn't the port know it? Why is -lc even in
> play if some of the components (-lmysqlclient) require -lc_r? Yours,
libmysqlclient does not require -lc_r, because the library does not use
threads. Only mysqld is threaded.
> -mi
>
> FreeBSD rtfm.newton 3.4-STABLE FreeBSD 3.4-STABLE #0: Fri Dec 17 08:49:51 EST 1999
>
Tom
PKGNAME=apache+php+mod_ssl-${VERSION_APACHE}+${VERSION_PHP}+${VERSION_MODSSL}
DISTFILES+= mod_ssl-${VERSION_MODSSL}-${VERSION_APACHE}${EXTRACT_SUFX}
BUILD_DEPENDS+= openssl:${PORTSDIR}/security/openssl \
mm-config:${PORTSDIR}/devel/mm \
${PREFIX}/lib/libmm.a:${PORTSDIR}/devel/mm
LIB_DEPENDS+= crypto.1:${PORTSDIR}/security/openssl \
ssl.1:${PORTSDIR}/security/openssl
RUN_DEPENDS+= openssl:${PORTSDIR}/security/openssl
VERSION_MODSSL= 2.4.9
RESTRICTED= "Contains cryptography"
CONFIGURE_ARGS+=--enable-module=ssl \
--enable-module=define
CONFIGURE_ENV+= SSL_BASE='SYSTEM' EAPI_MM='SYSTEM' PATH="${PREFIX}/bin:${PATH}"
PLIST= ${PKGDIR}/PLIST.modssl
SSL=ssl
TYPE= test
CRT=
KEY=
pre-patch:
@cd ${WRKDIR}/mod_ssl-${VERSION_MODSSL}-${VERSION_APACHE} \
&& ${ECHO_MSG} "===> Applying mod_ssl-${VERSION_MODSSL} extension" \
&& ./configure --with-apache=../${DISTNAME} --expert
post-patch:
@cd ${WRKSRC} \
&& find . -type f -name "*.orig" -print | xargs ${RM} -f
post-build:
@cd ${WRKSRC} \
&& ${ECHO_MSG} "===> Creating Dummy Certificate for Server (SnakeOil)" \
&& ${ECHO_MSG} " [use 'make certificate' to create a real one]" \
&& ${MAKE} certificate TYPE=dummy >/dev/null 2>&1
certificate:
@cd ${WRKSRC} \
&& ${ECHO_MSG} "===> Creating Test Certificate for Server" \
&& ${MAKE} certificate TYPE=$(TYPE) CRT=$(CRT) KEY=$(KEY)
BUILD_DEPENDS+= ${PREFIX}/lib/libgd.a:${PORTSDIR}/graphics/gd
PHP_CONF_ARGS+= --with-gd=${PREFIX}
LIB_DEPENDS+= ttf.4:${PORTSDIR}/print/freetype
PHP_CONF_ARGS+= --with-ttf=${PREFIX}
PHP_CONF_ARGS+= --with-zlib
LIB_DEPENDS+= mcrypt.2:${PORTSDIR}/security/libmcrypt
PHP_CONF_ARGS+= --with-mcrypt=${PREFIX}
LIB_DEPENDS+= mhash.1:${PORTSDIR}/security/mhash
PHP_CONF_ARGS+= --with-mhash=${PREFIX}
BUILD_DEPENDS+= ${PREFIX}/lib/libc-client4.a:${PORTSDIR}/mail/imap-uw
PHP_CONF_ARGS+= --with-imap=${PREFIX}
LIB_DEPENDS+= mysqlclient.6:${PORTSDIR}/databases/mysql322-client
PHP_CONF_ARGS+= --with-mysql=${PREFIX}
BUILD_DEPENDS+= ${PREFIX}/lib/libexpat.a:${PORTSDIR}/textproc/expat
BUILD_DEPENDS+= ${PREFIX}/include/xml/xmlparse.h:${PORTSDIR}/textproc/expat
BUILD_DEPENDS+= ${PREFIX}/include/xml/xmltok.h:${PORTSDIR}/textproc/expat
PHP_CONF_ARGS+= --with-xml=${PREFIX}
Re: -lc vs. -lc_r (building Apache-PHP)
Along this line of problems, I am having serious problems compileing a usable apache binary when compileing modphp with IMAP support. It works fine for me when I just compile any other service or combination of services. Here's the error: Configuring for Apache, Version 1.3.9 + using installation path layout: Apache (config.layout) + activated php3 module (modules/php3/libphp3.a) Creating Makefile Creating Configuration.apaci in src Creating Makefile in src + configured for FreeBSD 3.4 platform + setting C compiler to gcc + setting C pre-processor to gcc -E + checking for system header files + adding selected modules o php3_module uses ConfigStart/End + checking sizeof various data types + doing sanity check on compiler and options ** A test compilation with your Makefile configuration ** failed. This is most likely because your C compiler ** is not ANSI. Apache requires an ANSI C Compiler, such ** as gcc. The above error message from your compiler ** will also provide a clue. Aborting! venus# Here's my uname: FreeBSD venus.terahertz.net 3.4-STABLE FreeBSD 3.4-STABLE #3: Mon Dec 27 08:34:56 CST 1999 [EMAIL PROTECTED]:/usr/src/sys/compile/VENUS i386 I tried doing this under 3.3-RELEASE and had the same error from apache. I have tried upgrading my IMAP libs, with no luck. I have tried downgrading apache, and php, and get the same result. Has anyone else experienced this? Chris Malayter [EMAIL PROTECTED] Administrator, TeraHertz Communications To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: -lc vs. -lc_r (building Apache-PHP)
Tom once stated: => => What's the magic and why doesn't the port know it? Why is -lc even => => in play if some of the components (-lmysqlclient) require -lc_r? => => Yours, => = => = libmysqlclient does not require -lc_r, because the library does => =not use threads. Only mysqld is threaded. => => Thank you, Tom, for this correction. However, this does not change => much. Some other extension wants threads then... = = Uhh.. highly unlikely. Almost none of PHP3 is thread-safe, and only a =bit of Apache is thread-safe. I doubt that anything in the Apache-PHP =port wants or needs threads. I did not put it in there myself :) At least one of the many extensions selected (I included the Makefile.inc with my original report) dragged the c_r with it... -mi To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: -lc vs. -lc_r (building Apache-PHP)
On Mon, 27 Dec 1999, Mikhail Teterin wrote: > Tom once stated: > > =On Mon, 27 Dec 1999, Mikhail Teterin wrote: > = > =... > => What's the magic and why doesn't the port know it? Why is -lc even in > => play if some of the components (-lmysqlclient) require -lc_r? Yours, > = > = libmysqlclient does not require -lc_r, because the library does not > =use threads. Only mysqld is threaded. > > Thank you, Tom, for this correction. However, this does not change much. > Some other extension wants threads then... Uhh.. highly unlikely. Almost none of PHP3 is thread-safe, and only a bit of Apache is thread-safe. I doubt that anything in the Apache-PHP port wants or needs threads. Tom To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
