GNOME Bugzilla – Bug 750525
gnome-user-share needs mpm_prefork_module
Last modified: 2019-03-20 10:39:36 UTC
Some people downstream would like to not have a hard requirement on prefork because it needs apache built without threads support: --- gnome-user-share-3.14.2/data/dav_user_2.4.conf.orig 2015-06-03 20:21:27.512774376 -0600 +++ gnome-user-share-3.14.2/data/dav_user_2.4.conf 2015-06-03 20:21:33.588774303 -0600 @@ -9,7 +9,6 @@ LimitXMLRequestBody 100000 LoadModule unixd_module ${HTTP_MODULES_PATH}/mod_unixd.so -LoadModule mpm_prefork_module ${HTTP_MODULES_PATH}/mod_mpm_prefork.so LoadModule dav_module ${HTTP_MODULES_PATH}/mod_dav.so LoadModule dav_fs_module ${HTTP_MODULES_PATH}/mod_dav_fs.so LoadModule authn_core_module ${HTTP_MODULES_PATH}/mod_authn_core.so Would be possible to apply this patch? Thanks a lot
Or is prefork needed for some reason?
(In reply to Pacho Ramos from comment #1) > Or is prefork needed for some reason? Because that's how the httpd in my distribution was compiled. (In reply to Pacho Ramos from comment #0) > Some people downstream would like to not have a hard requirement on prefork > because it needs apache built without threads support: > --- gnome-user-share-3.14.2/data/dav_user_2.4.conf.orig 2015-06-03 > 20:21:27.512774376 -0600 > +++ gnome-user-share-3.14.2/data/dav_user_2.4.conf 2015-06-03 > 20:21:33.588774303 -0600 > @@ -9,7 +9,6 @@ > LimitXMLRequestBody 100000 > > LoadModule unixd_module ${HTTP_MODULES_PATH}/mod_unixd.so > -LoadModule mpm_prefork_module ${HTTP_MODULES_PATH}/mod_mpm_prefork.so > LoadModule dav_module ${HTTP_MODULES_PATH}/mod_dav.so > LoadModule dav_fs_module ${HTTP_MODULES_PATH}/mod_dav_fs.so > LoadModule authn_core_module ${HTTP_MODULES_PATH}/mod_authn_core.so > > Would be possible to apply this patch? Not that one. First, patches need to be git-formatted, and attached as such to the bug, but you probably knew that. Second, it needs to make use of conditionals to only load the module if it exists. See IfModule: http://httpd.apache.org/docs/2.4/mod/core.html#ifmodule
Created attachment 315992 [details] [review] Remove mpm_prefork LoadModule line to match dav_user_2.2 Here's a git formatted patch for the issue. It still only removes the line, since the line isn't present in dav_user_2.2.conf and the options that are specific to that module are already wrapped in an IfModule condition (in both dav_user_2.2 and dav_user_2.4). Hopefully this is enough to resolve the issue?
Review of attachment 315992 [details] [review]: $ ./gnome-user-share-webdav AH00534: httpd: Configuration error: No MPM loaded. spawning httpd failed Doesn't work...
Created attachment 316352 [details] [review] Gnome-user-share apache-2.4 mpm configuration patch Ah, I guess I hadn't realized MPMs could be compiled out into separate shared objects (mine was compiled in, hence no need for a LoadModule). This patch attempts to load each of the unix MPM modules in their appropriate pecking order (event is most likely on modern systems, then worker, then prefork, according to [1]) until one is loaded. For each it checks whether the module exists using the module filename (found as the files containing MPM20_MODULE_STUFF), and it then only attempts to load it if it hasn't already been loaded (because if the MPMs are compiled in then everything will already have been taken care of). This should satisfy all the needs of any apache configuration (either compiled in, or compiled as shared objects) for each of the possible unix MPMs. Please let me know if there's another situation I haven't considered... [1] http://httpd.apache.org/docs/current/mpm.html#defaults
Review of attachment 316352 [details] [review]: That doesn't work either: ./gnome-user-share-webdav AH00534: httpd: Configuration error: No MPM loaded. spawning httpd failed No error messages other than that, nothing in the log file. Please make sure to provide git-formatted patches in the future (and possibly tested...).
Sorry about the patch format, I forgot. I can't really test this any better than the original packager (ie only on my distribution). My distribution doesn't support the DSO compiled modules, so I can't test them. It isn't clear whether IfModule defines whether the module "exists" or "exists and is loaded". The error message you received suggests that IfModule works based on "exists" (because it didn't actually load the module but did set the GUS_MODULE_LOADED flag), which means we can't differentiate between when a module has been compiled in (and therefore is already loaded) or just exists as a file. If we try to LoadModule it, it will error if the file doesn't exist, if we don't try to LoadModule it, we may end up with no MPM as you did. I'm not sure this can be fixed with Apache conditional statements (<If "-f filename"> doesn't seem to work), it might require user intervention. Could you please advise how you'd recommend fixing this?
(In reply to Mike Auty from comment #7) > Sorry about the patch format, I forgot. > > I can't really test this any better than the original packager (ie only on > my distribution). My distribution doesn't support the DSO compiled modules, > so I can't test them. Well, the problem is that I can't regress, and break other distributions that already work... > It isn't clear whether IfModule defines whether the module "exists" or > "exists and is loaded". The error message you received suggests that > IfModule works based on "exists" (because it didn't actually load the module > but did set the GUS_MODULE_LOADED flag), which means we can't differentiate > between when a module has been compiled in (and therefore is already loaded) > or just exists as a file. If we try to LoadModule it, it will error if the > file doesn't exist, if we don't try to LoadModule it, we may end up with no > MPM as you did. > > I'm not sure this can be fixed with Apache conditional statements (<If "-f > filename"> doesn't seem to work), it might require user intervention. Could > you please advise how you'd recommend fixing this? I'd drop a mail to the Apache user list to try and figure out how to make this work on both types of compilations. If it's not fixable, your distribution should be patching gnome-user-share to work-around this, so it at least works on that distribution.
Has been there been on progress/feedback on this? My distribution is still getting duplicate bugs on this because we're waiting to see whether upstream can/will patch it. If you could let us know one way or another, that would help us get this resolved.
(In reply to Mike Auty from comment #9) > Has been there been on progress/feedback on this? I'm waiting for somebody who can reproduce the problem to actually fix it. I have plenty of other things to focus on, and this isn't something I'm willing to spend time on. > My distribution is still > getting duplicate bugs on this because we're waiting to see whether upstream > can/will patch it. If you could let us know one way or another, that would > help us get this resolved. The patches you sent make gnome-user-share work on the distribution you use and break it on mine. I'm not interested in shifting the problem, only in having it fixed. I already mentioned that you should try contacting the Apache users list. This is where you're more likely to find help with this issue to get gnome-user-share fixed.
I'm sorry, I misread "I'd" as "I'll" in your last reply and had thought you were doing it.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gnome-user-share/issues/19.