Re: Lighttpd wedged and ignoring SIGKILL
On Mon, Jun 8, 2009 at 8:34 PM, Mel Flynnmel.flynn+fbsd.questi...@mailing.thruhere.net wrote: On Thursday 04 June 2009 18:25:30 L Campbell wrote: PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 85542 www 1 51 0 102M 85360K CPU6 6 16:34 100.00% lighttpd 1) Should this be possible? What is going on here? Change the write-backend. Look in google for lighttpd and sendfile to see why. I was under the impression that that bug was fixed[1]. In any case, I've switched from freebsd-sendfile to writev. I'll send another ping if that doesn't fix it (and probably fiddle around with the event-handler too -- I've read error reports suggesting that freebsd-kqueue handling is broken in Lighttpd). Thanks for the suggestion :) -- [1] http://redmine.lighttpd.net/issues/1913 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Lighttpd wedged and ignoring SIGKILL
On Mon, Jun 8, 2009 at 9:06 PM, L Campbe...@virginia.edu wrote: On Mon, Jun 8, 2009 at 8:34 PM, Mel Flynnmel.flynn+fbsd.questi...@mailing.thruhere.net wrote: Change the write-backend. Look in google for lighttpd and sendfile to see why. I was under the impression that that bug was fixed[1]. In any case, I've switched from freebsd-sendfile to writev. I'll send another ping if that doesn't fix it. writev doesn't seem to have done the trick -- lighttpd went down and took all the other services (ssh, etc) with it, even after a reboot (??!). I'm going to go with the hunch from a thread I found[1] that it could potentially be due to kqueue and switch to writev+poll once the machine comes back up. And then I'm turning my phone off for the night, lmao. Then try to convince the actual sysadmin to switch to Nginx in the morning, because this is only helping to deepen my grudge against Lighttpd. Thanks again for the help guys; I'll post another message in the morning if writev+poll crashes too (in which case faulty hardware would enter my list of suspicions). Bleh. -- [1] http://groups.google.com/group/lucky.freebsd.ports/browse_thread/thread/a6e426a75077e800 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Lighttpd wedged and ignoring SIGKILL
As a fore-note, I'm not subscribed to this list, so please CC me :) I was just tweaking a php.ini file and restarted Lighttpd (via rc.d). The rc script was taking forever to stop it (was waiting for the process to terminate). After a couple minutes, I got impatient and killed the rc script with ^C and issued a `killall -9 lighttpd`. Much to my surprise, this didn't have any effect (and neither did kill -9 with the PID). top showed lighttpd with the unchanging PID USERNAME THR PRI NICE SIZERES STATE C TIME WCPU COMMAND 85542 www1 510 102M 85360K CPU6 6 16:34 100.00% lighttpd Basically, wedged on CPU6. r...@tomoyo uname -a FreeBSD tomoyo 7.1-RELEASE-p5 FreeBSD 7.1-RELEASE-p5 #0: Mon Apr 27 16:58:17 UTC 2009 bsdad...@tomoyo:/usr/src/sys/amd64/compile/TOMOYO amd64 Using SMP and SCHED_ULE. I resolved the issue by rebooting the machine. I guess my questions are twofold: 1) Should this be possible? What is going on here? 2) If this happens again, how should it be resolved? What diagnostics can I run to further diagnose the problem? Thanks a bunch for any help (and don't forget to CC me!) ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: [pkg_add] PACKAGESITE weirdness - URL not correct for dependencies?
On Sat, Mar 28, 2009 at 7:37 AM, Mel Flynn mel.flynn+fbsd.questi...@mailing.thruhere.net wrote: On Thursday 26 March 2009 21:46:07 L Campbell wrote: Okay, so apparently there's some serious weirdness in the logic in src/usr.sbin/pkg_install/lib/url.c, in fileGetURL. This function takes two parameters, base and spec, and has the following behavior -- snip behavior and patch Yes, it is a bit counter-intuitive. However it's documented in the pkg_add(1) manpage that PACKAGESITE should resolve to the full URL where packages can be found (even the trailing slash). The additional stipulation that any dependent packages must be in an ../All/ directory relative to the path of the initial package is an undocumented feature. It's a bit counter-intuitive, but once it works, it works. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
[pkg_add] PACKAGESITE weirdness - URL not correct for dependencies?
I'm running a bunch of jails and running the same set of ports between them. To save myself some CPU time, I've got one jail building packages for everything I need, then serving those packages out over HTTP to the rest of the jails. The package serving jail is at 10.0.0.4, and is serving packages out from it's HTTP root, such that requesting the following URLs properly fetch the desired packages: http://10.0.0.4/lighttpd-1.4.22.tbz http://10.0.0.4/pcre-7.8.tbz I set PACKAGESITE to 'http://10.0.0.4/'; when I attempt to install Lighttpd with pkg_add -rv, I get the following output (snipped to relevant portions): $ pkg_add -rv lighttpd-1.4.22 (..snip..) scheme: [http] user: [] password: [] host: [10.0.0.4] port: [0] document: [/lighttpd-1.4.22.tbz] (..fetches and installs lighttpd-1.4.22 properly..) Package 'lighttpd-1.4.22' depends on 'pcre-7.8' with 'devel/pcre' origin. scheme: [http] user: [] password: [] host: [All] port: [0] document: [/pcre-7.8.tbz] --- All:80 looking up All Error: FTP Unable to get http://All/pcre-7.8.tbz: No address record Somewhere along the process, something breaks and 'host' doesn't get set properly. I'm currently poking through the pkg_install code to figure out wtf is going on, but I figured I'd prod the lists to see if anyone else hit a similar problem (or knows what I'm doing wrong) since I'm not familiar with it. $ uname -a FreeBSD blah 7.1-RELEASE FreeBSD 7.1-RELEASE #0: Thu Jan 1 14:37:25 UTC 2009 r...@logan.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 Thanks :3 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: [pkg_add] PACKAGESITE weirdness - URL not correct for dependencies?
On Thu, Mar 26, 2009 at 3:37 PM, L Campbell ll...@virginia.edu wrote: blah Oh, and please CC me on any replies since I don't follow this list. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: [pkg_add] PACKAGESITE weirdness - URL not correct for dependencies?
Okay, so apparently there's some serious weirdness in the logic in
src/usr.sbin/pkg_install/lib/url.c, in fileGetURL. This function takes
two parameters, base and spec, and has the following behavior --
* if spec is a valid URL, it's used unchanged as the path to the remote package.
* if base is non-NULL, the last two '/'s are chopped off and All/ +
package name + .tbz is used as the result.
* if PKG_ADD_BASE is set in the environment, it's concatenated with
the package name and .tbz
When fileGetURL is called on the dependencies by pkg_do in
add/perform.c, it always gets passed the remote URL of the parent
package as the base and the package name as the spec, so the second
branch is always taken.
Unfortunately, this doesn't work with the PACKAGESITE code in
add/main.c, because fileGetURL is expecting the base argument to be of
the form http://host/directory/package.tbz;, as in
www/lighttpd-1.4.22.tbz. The problem is, when using PACKAGESITE, the
actual URL (in my case) is just http://host/lighttpd-1.4.22.tbz;, so
that gets incorrectly chopped down to http:/ + Add/ +
lighttpd-1.4.22.tbz.
It works fine if your PACKAGESITE puts all the packages in the All/
subdirectory (as I think the official ones do), but at the very least,
that's an undocumented constraint.
My solution was to add another case into fileGetURL which gets
overrides the three currently in there and is invoked if and only if
PACKAGESITE is set in the environment.
The following patch makes it work for me --
--- usr.sbin/pkg_install/lib/url.c.orig 2009-03-26 19:56:12.0 +
+++ usr.sbin/pkg_install/lib/url.c 2009-03-26 20:41:44.0 +
@@ -57,7 +57,21 @@
* to construct a composite one out of that and the basename we were
* handed as a dependency.
*/
- if (base) {
+ if (getenv(PACKAGESITE)) {
+ if (strlcpy(fname, getenv(PACKAGESITE), sizeof(fname))
+ = sizeof(fname)) {
+ return NULL;
+ }
+ if (strlcat(fname, spec, sizeof(fname))
+ = sizeof(fname)) {
+ return NULL;
+ }
+ if (strlcat(fname, .tbz, sizeof(fname))
+ = sizeof(fname)) {
+ return NULL;
+ }
+ }
+ else if (base) {
strcpy(fname, base);
/*
* Advance back two slashes to get to the root of the package
Though I think, in the long-run I'm just going to put all my packages
in http://10.0.0.4/All/ and call it a day -- I hate maintaining a
bunch of patches for stuff.
:(
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
