From toredo at saustall3.de Fri Jul 3 13:33:57 2015 From: toredo at saustall3.de (Toredo) Date: Fri, 03 Jul 2015 13:33:57 +0200 Subject: [mpm-itk] What do MaxRequestsPerChild and MaxSpareServers mean to mpm-itk? Message-ID: <55967325.8060903@saustall3.de> Hi there! On the mpm-itk website I read it supports all configuration options from mpm-prefork. However, as I understand it, when itk receives a request, it is passed to a spare fork which then changes uid and executes the request and exits. But doesn't this mean that MaxRequestsPerChild is always 1 and MaxSpareServers is always == MinSpareServers? From sgunderson at bigfoot.com Fri Jul 3 14:14:47 2015 From: sgunderson at bigfoot.com (Steinar H. Gunderson) Date: Fri, 3 Jul 2015 14:14:47 +0200 Subject: [mpm-itk] What do MaxRequestsPerChild and MaxSpareServers mean to mpm-itk? In-Reply-To: <55967325.8060903@saustall3.de> References: <55967325.8060903@saustall3.de> Message-ID: <20150703121447.GA21315@sesse.net> On Fri, Jul 03, 2015 at 01:33:57PM +0200, Toredo wrote: > Hi there! On the mpm-itk website I read it supports all configuration > options from mpm-prefork. However, as I understand it, when itk receives a > request, it is passed to a spare fork which then changes uid and executes > the request and exits. > > But doesn't this mean that MaxRequestsPerChild is always 1 and > MaxSpareServers is always == MinSpareServers? The former question is a question of definition (the Apache child lives on, but the grandchild dies as soon as the connection is done -- which could be several requests, of course). The answer to the second question is a clear no, though: The child is waiting for the grandchild to process its request; it cannot handle any other requests in that timeframe, and thus does not count as a spare server. Even if it did, there are several parts of the query processing that happen in the upper child. /* Steinar */ -- Homepage: http://www.sesse.net/ From sgunderson at bigfoot.com Fri Jul 3 14:14:47 2015 From: sgunderson at bigfoot.com (Steinar H. Gunderson) Date: Fri, 3 Jul 2015 14:14:47 +0200 Subject: [mpm-itk] What do MaxRequestsPerChild and MaxSpareServers mean to mpm-itk? In-Reply-To: <55967325.8060903@saustall3.de> References: <55967325.8060903@saustall3.de> Message-ID: <20150703121447.GA21315@sesse.net> On Fri, Jul 03, 2015 at 01:33:57PM +0200, Toredo wrote: > Hi there! On the mpm-itk website I read it supports all configuration > options from mpm-prefork. However, as I understand it, when itk receives a > request, it is passed to a spare fork which then changes uid and executes > the request and exits. > > But doesn't this mean that MaxRequestsPerChild is always 1 and > MaxSpareServers is always == MinSpareServers? The former question is a question of definition (the Apache child lives on, but the grandchild dies as soon as the connection is done -- which could be several requests, of course). The answer to the second question is a clear no, though: The child is waiting for the grandchild to process its request; it cannot handle any other requests in that timeframe, and thus does not count as a spare server. Even if it did, there are several parts of the query processing that happen in the upper child. /* Steinar */ -- Homepage: http://www.sesse.net/ From toredo at saustall3.de Fri Jul 3 14:42:10 2015 From: toredo at saustall3.de (Toredo) Date: Fri, 03 Jul 2015 14:42:10 +0200 Subject: [mpm-itk] What do MaxRequestsPerChild and MaxSpareServers mean to mpm-itk? In-Reply-To: <20150703121447.GA21315@sesse.net> References: <55967325.8060903@saustall3.de> <20150703121447.GA21315@sesse.net> Message-ID: <55968322.9070306@saustall3.de> So does this mean mpm_itk introduces an additional level of forking? I thought that in prefork Apache works in a way that one process running as root forks itself, those children switch their uid to User/Group as configured, get handled over requests which they parse and process. Further I thought ITK just checks the vHost and used it's AssignUserID option instead of User/Group from main config. So at which point do those grandchildren come into play? Am 03.07.2015 um 14:14 schrieb Steinar H. Gunderson: > On Fri, Jul 03, 2015 at 01:33:57PM +0200, Toredo wrote: >> Hi there! On the mpm-itk website I read it supports all configuration >> options from mpm-prefork. However, as I understand it, when itk receives a >> request, it is passed to a spare fork which then changes uid and executes >> the request and exits. >> >> But doesn't this mean that MaxRequestsPerChild is always 1 and >> MaxSpareServers is always == MinSpareServers? > > The former question is a question of definition (the Apache child lives on, > but the grandchild dies as soon as the connection is done -- which could be > several requests, of course). The answer to the second question is a clear > no, though: The child is waiting for the grandchild to process its request; > it cannot handle any other requests in that timeframe, and thus does not > count as a spare server. Even if it did, there are several parts of the query > processing that happen in the upper child. > > /* Steinar */ > From sgunderson at bigfoot.com Fri Jul 3 15:00:38 2015 From: sgunderson at bigfoot.com (Steinar H. Gunderson) Date: Fri, 3 Jul 2015 15:00:38 +0200 Subject: [mpm-itk] What do MaxRequestsPerChild and MaxSpareServers mean to mpm-itk? In-Reply-To: <55968322.9070306@saustall3.de> References: <55967325.8060903@saustall3.de> <20150703121447.GA21315@sesse.net> <55968322.9070306@saustall3.de> Message-ID: <20150703130038.GA37669@sesse.net> On Fri, Jul 03, 2015 at 02:42:10PM +0200, Toredo wrote: > So does this mean mpm_itk introduces an additional level of forking? Yes. > I thought that in prefork Apache works in a way that one process running as > root forks itself, those children switch their uid to User/Group as > configured, get handled over requests which they parse and process. No. They get sockets, not requests; they are responsible for reading and parsing the requests themselves. And there is a fair amount of work to start a child beyond the fork (you can have more or less arbitrary hooks). > Further I thought ITK just checks the vHost and used it's AssignUserID > option instead of User/Group from main config. So at which point do those > grandchildren come into play? How would you know what vhost the request belongs to before you've run through all the steps to parse it and apply the necessary parts of the config? You could have the child die immediately, but it would require writing prefork's spare server logic (it handles rapid amounts of server deaths very poorly), which is pretty much out of the question now that in 2.4 mpm-itk isn't even its own MPM, just a module that hooks into prefork. /* Steinar */ -- Homepage: http://www.sesse.net/ From toredo at saustall3.de Fri Jul 3 15:22:35 2015 From: toredo at saustall3.de (Toredo) Date: Fri, 03 Jul 2015 15:22:35 +0200 Subject: [mpm-itk] What do MaxRequestsPerChild and MaxSpareServers mean to mpm-itk? In-Reply-To: <20150703130038.GA37669@sesse.net> References: <55967325.8060903@saustall3.de> <20150703121447.GA21315@sesse.net> <55968322.9070306@saustall3.de> <20150703130038.GA37669@sesse.net> Message-ID: <55968C9B.9050904@saustall3.de> Steinar H. Gunderson wrote on 03.07.2015 15:00: > On Fri, Jul 03, 2015 at 02:42:10PM +0200, Toredo wrote: >> >So does this mean mpm_itk introduces an additional level of forking? > Yes. > [...] > You could have the child die immediately, but it would require writing > prefork's spare server logic (it handles rapid amounts of server deaths very > poorly), which is pretty much out of the question now that in 2.4 mpm-itk > isn't even its own MPM, just a module that hooks into prefork. OK, now I understand better what's going on behind the scenes. Thanks for pointing that out. > No. They get sockets, not requests; That was clear, just considered it irrelevant for the mail. > The former question is a question of definition (the Apache child lives on, > but the grandchild dies as soon as the connection is done -- which could be > several requests, of course). When it comes to MaxRequestsPerChild, Apache defines "Request" as connection. The documentation reads: For KeepAlive requests, only the first request is counted towards this limit. In effect, it changes the behavior to limit the number of connections per child. From remko at FreeBSD.org Sat Jul 4 00:59:03 2015 From: remko at FreeBSD.org (Remko Lodder) Date: Sat, 4 Jul 2015 00:59:03 +0200 Subject: [mpm-itk] Connection timeout issues In-Reply-To: <20141217194254.GA29066@sesse.net> References: <4F4CE507-D9F3-458D-BAE0-FE950DC6C64C@FreeBSD.org> <20141217194254.GA29066@sesse.net> Message-ID: <943CF07F-EA40-45EC-ADB4-458148AB30E2@FreeBSD.org> > On 17 Dec 2014, at 20:42, Steinar H. Gunderson wrote: > > On Wed, Dec 17, 2014 at 08:30:17PM +0100, Remko Lodder wrote: >> So far both Peter and I did not receive feedback, yet. Can people confirm >> that they have this problem as well? Steinar, have you taken notice of this >> and can you share what we can do to help you debug this ? > > I have never seen anything like this. I'm too busy with other things these > days, so I cannot help you apart from the obvious (e.g. see what happens on > tcpdump, strace the server, instrument the clients with information as of > what happens, and so on). > > /* Steinar */ Hi, This issue still plays, and not many people responded (at all). Does that mean this issue is not a real issue but just on some corporate servers and mine? There had (seemingly) been no development of the plugin recently, did it die? Thanks Remko > -- > Homepage: http://www.sesse.net/ > > _______________________________________________ > mpm-itk mailing list > mpm-itk at err.no > http://lists.err.no/mailman/listinfo/mpm-itk -- /"\ Best regards, | remko at FreeBSD.org \ / Remko Lodder | remko at EFnet X http://www.evilcoder.org/ | / \ ASCII Ribbon Campaign | Against HTML Mail and News -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 841 bytes Desc: Message signed with OpenPGP using GPGMail URL: From sgunderson at bigfoot.com Sat Jul 4 01:17:51 2015 From: sgunderson at bigfoot.com (Steinar H. Gunderson) Date: Sat, 4 Jul 2015 01:17:51 +0200 Subject: [mpm-itk] Connection timeout issues In-Reply-To: <943CF07F-EA40-45EC-ADB4-458148AB30E2@FreeBSD.org> References: <4F4CE507-D9F3-458D-BAE0-FE950DC6C64C@FreeBSD.org> <20141217194254.GA29066@sesse.net> <943CF07F-EA40-45EC-ADB4-458148AB30E2@FreeBSD.org> Message-ID: <20150703231751.GB38169@sesse.net> On Sat, Jul 04, 2015 at 12:59:03AM +0200, Remko Lodder wrote: >> I have never seen anything like this. I'm too busy with other things these >> days, so I cannot help you apart from the obvious (e.g. see what happens on >> tcpdump, strace the server, instrument the clients with information as of >> what happens, and so on). > This issue still plays, and not many people responded (at all). Does that mean > this issue is not a real issue but just on some corporate servers and mine? Hard to know; like I said, you will need to debug it yourself. > There had (seemingly) been no development of the plugin recently, did it die? Development has always been in a pretty uneven tempo, to be honest. Save for the bug you are talking about, which I do not see myself and have no way of reproducing (making it impossible to fix) there are simply no major things left that I want to do. So does that bug make the project dead? That would presumably depend on how crippling it is and how many users it affects. Neither is clear to me. /* Steinar */ -- Homepage: http://www.sesse.net/ From remko at FreeBSD.org Sat Jul 4 01:27:43 2015 From: remko at FreeBSD.org (Remko Lodder) Date: Sat, 4 Jul 2015 01:27:43 +0200 Subject: [mpm-itk] Connection timeout issues In-Reply-To: <20150703231751.GB38169@sesse.net> References: <4F4CE507-D9F3-458D-BAE0-FE950DC6C64C@FreeBSD.org> <20141217194254.GA29066@sesse.net> <943CF07F-EA40-45EC-ADB4-458148AB30E2@FreeBSD.org> <20150703231751.GB38169@sesse.net> Message-ID: <1300E37C-44D3-4CC3-92AC-7ADA1FE6BE63@FreeBSD.org> > On 04 Jul 2015, at 01:17, Steinar H. Gunderson wrote: > > On Sat, Jul 04, 2015 at 12:59:03AM +0200, Remko Lodder wrote: >>> I have never seen anything like this. I'm too busy with other things these >>> days, so I cannot help you apart from the obvious (e.g. see what happens on >>> tcpdump, strace the server, instrument the clients with information as of >>> what happens, and so on). >> This issue still plays, and not many people responded (at all). Does that mean >> this issue is not a real issue but just on some corporate servers and mine? > > Hard to know; like I said, you will need to debug it yourself. ack, I?ll retry to look at this soon-ish :-). The one thing we could find is that it affects https sessions with Safari (on mac os x). Using that triggers the problems. Which simply replicates by doing a POST to the server (for ex. logging into a certain application triggers it easily, the screen just goes blank). > >> There had (seemingly) been no development of the plugin recently, did it die? > > Development has always been in a pretty uneven tempo, to be honest. Save for Fair enough :-) > the bug you are talking about, which I do not see myself and have no way of > reproducing (making it impossible to fix) there are simply no major things > left that I want to do. So does that bug make the project dead? That would > presumably depend on how crippling it is and how many users it affects. > Neither is clear to me. Also fair enough, if the product is stable and fine, then that is just fine indeed. As said I?ll try to investigate why this occurs on our server(s). To see whether my ?claim? holds through.. Thanks! Remko > > /* Steinar */ > -- > Homepage: http://www.sesse.net/ > > _______________________________________________ > mpm-itk mailing list > mpm-itk at err.no > http://lists.err.no/mailman/listinfo/mpm-itk -- /"\ Best regards, | remko at FreeBSD.org \ / Remko Lodder | remko at EFnet X http://www.evilcoder.org/ | / \ ASCII Ribbon Campaign | Against HTML Mail and News -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 841 bytes Desc: Message signed with OpenPGP using GPGMail URL: From sgunderson at bigfoot.com Sat Jul 4 01:38:27 2015 From: sgunderson at bigfoot.com (Steinar H. Gunderson) Date: Sat, 4 Jul 2015 01:38:27 +0200 Subject: [mpm-itk] Connection timeout issues In-Reply-To: <1300E37C-44D3-4CC3-92AC-7ADA1FE6BE63@FreeBSD.org> References: <4F4CE507-D9F3-458D-BAE0-FE950DC6C64C@FreeBSD.org> <20141217194254.GA29066@sesse.net> <943CF07F-EA40-45EC-ADB4-458148AB30E2@FreeBSD.org> <20150703231751.GB38169@sesse.net> <1300E37C-44D3-4CC3-92AC-7ADA1FE6BE63@FreeBSD.org> Message-ID: <20150703233827.GA20832@sesse.net> On Sat, Jul 04, 2015 at 01:27:43AM +0200, Remko Lodder wrote: > ack, I?ll retry to look at this soon-ish :-). The one thing we could find is that > it affects https sessions with Safari (on mac os x). Using that triggers the problems. > Which simply replicates by doing a POST to the server (for ex. logging into a certain > application triggers it easily, the screen just goes blank). Well, as I understand your bug report, it affects only a combination of two specific operating systems, neither of which I use (and one of which you even need to buy special hardware for), plus easily one of the most complicated libraries on the face of the planet.[1] :-) Needless to say, it does not come very high up on my list to try to reproduce and fix on a Friday evening. This is not to say that I do not appreciate your efforts! If I had any good guesses at all as of what the problem might be (weird pthread_atfork handlers?), I'd be happy to share them. [1] There was also a report of similar issues on OpenSUSE, but as I understand them, this was a issue that is since fixed in PHP. /* Steinar */ -- Homepage: http://www.sesse.net/ From henk at hjts.nl Tue Jul 7 08:04:23 2015 From: henk at hjts.nl (Henk te Sligte) Date: Tue, 07 Jul 2015 08:04:23 +0200 Subject: [mpm-itk] Vhost works locally, but not from NFS server Message-ID: Hi all, I have been on the #httpd channel but they refered me to you. I'm hoping you can help me out. I have two directories with the exact same permissions: root at WEB01:/# namei -mo /websites/comsi.nl/htdocs/index.html f: /websites/comsi.nl/htdocs/index.html drwxr-xr-x root root / drwx------ comsi.nl websites websites drwx------ comsi.nl websites comsi.nl drwx------ comsi.nl websites htdocs -rw------- comsi.nl websites index.html root at WEB01:/# namei -mo /wex/comsi.nl/htdocs/index.html f: /wex/comsi.nl/htdocs/index.html drwxr-xr-x root root / drwx------ comsi.nl websites wex drwx------ comsi.nl websites comsi.nl drwx------ comsi.nl websites htdocs -rw------- comsi.nl websites index.html If I configure the vhost to use /wex/comsi.nl/htdocs as the documentroot, the website is displayed. But when I configure it to use a mounted nfs share (/websites/comsi.nl/htdocs), I get the error: [Tue Jul 07 09:45:12.145217 2015] [core:error] [pid 3783] (13)Permission denied: [client 83.163.173.137:8436] AH00035: access to /index.html denied (filesystem path '/websites/comsi.nl/htdocs') because search permissions are missing on a component of the path This is my vhost config: AssignUserID comsi.nl websites ServerName comsi.nl ServerAlias www.comsi.nl DocumentRoot /websites/comsi.nl/htdocs/ Require all granted >From strace logs I can see that a stat call to the index.html file fails with error 13. My idea is that somehow, when I serve the website from a local directory the stat call is executed as root, but when I serve the website from the nfs share, it is executed as www-data:www-data. Does that make any sense to you? I hope someone can help me out! Greetings, Henk te Sligte -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgunderson at bigfoot.com Tue Jul 7 10:55:02 2015 From: sgunderson at bigfoot.com (Steinar H. Gunderson) Date: Tue, 7 Jul 2015 10:55:02 +0200 Subject: [mpm-itk] Vhost works locally, but not from NFS server In-Reply-To: References: Message-ID: <20150707085502.GA13780@sesse.net> On Tue, Jul 07, 2015 at 08:04:23AM +0200, Henk te Sligte wrote: > From strace logs I can see that a stat call to the index.html file fails > with error 13. My idea is that somehow, when I serve the website from a > local directory the stat call is executed as root, but when I serve the > website from the nfs share, it is executed as www-data:www-data. > > Does that make any sense to you? I hope someone can help me out! This is a classic case of NFS root squashing; the NFS server converts ?root? into nobody/nogroup by default. https://en.wikipedia.org/wiki/Unix_security#Root_squash /* Steinar */ -- Homepage: http://www.sesse.net/