Bug 1128328 - No user/group apache results in httpd systemd-tmpfiles-setup.service failure
Summary: No user/group apache results in httpd systemd-tmpfiles-setup.service failure
Alias: None
Product: Fedora
Classification: Fedora
Component: httpd
Version: 21
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Jan Kaluža
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2014-08-09 06:17 UTC by Bruce Jerrick
Modified: 2014-09-23 04:51 UTC (History)
4 users (show)

Fixed In Version: httpd-2.4.10-9.fc21
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2014-09-23 04:51:07 UTC

Attachments (Terms of Use)

Description Bruce Jerrick 2014-08-09 06:17:48 UTC
Description of problem:
The preinstall scriptlet of httpd no longer does a useradd, and as a
result, systemd-tmpfiles-setup.service fails at boot time due to the
lack of UID/GID "httpd".
Also, 'rpm -V httpd' reports a few files with incorrect UID and/or GID.

Version-Release number of selected component:

How reproducible:

Steps to Reproduce:
1.  Install F21, including package 'httpd'.
2a. Observe systemd boot messages.
2b. Run: grep -A1 "Create Volatile Files" /var/log/boot.log
3.  Run: systemctl status systemd-tmpfiles-setup.service
4.  Run: rpm -V httpd

Actual results:
/var/log/boot.log will contain:
    [FAILED] Failed to start Create Volatile Files and Directories.
    See 'systemctl status systemd-tmpfiles-setup.service' for details.
'systemctl status systemd-tmpfiles-setup' will include:
    systemd-tmpfiles[498]: [/usr/lib/tmpfiles.d/httpd.conf:1] Unknown group 'apache'.
    systemd-tmpfiles[498]: [/usr/lib/tmpfiles.d/httpd.conf:2] Unknown user 'apache'.
'rpm -V httpd' will include:
    missing     /run/httpd
    missing     /run/httpd/htcacheclean
    ......G..    /usr/sbin/suexec
    .....UG..    /var/cache/httpd
    .....UG..    /var/cache/httpd/proxy
    .....UG..    /var/lib/dav
(the first two are a result of the systemd-tmpfiles-setup.service failure)

Expected results:
None of the above.

Additional info:
/etc/tmpfiles.d/zoneminder.conf also causes a similar complaint from
systemd-tmpfiles-setup.service, because it also uses UID/GID "apache".
zoneminder requires httpd, so fixing httpd will fix it also.

(BTW, the useradd command in the preinstall scriptlet of F20
httpd-2.4.10-1.fc20 also creates the /etc/group entry.)

Comment 1 Jan Kaluža 2014-08-14 17:38:48 UTC
Thanks for the report, it's regression caused by bad copy-paste when adding httpd-filesystem package, I've just fixed in rawhide and will merge with f21 soon.

Comment 2 Jan Kaluža 2014-08-15 07:49:07 UTC
I've been thinking about it more and I have one question. Does it install httpd-filesystem package for you? Because the %pre script has been moved into httpd-filesystem package and httpd should require this package, so after the installation, you should not end up with system without "apache" user.

What can happen and what I've fixed is situation, where httpd package is installed before httpd-filesystem package and therefore apache user does not exist during httpd package installation. This explains why the directories are not right, but probably does not explain why systemd-tmpfiles-setup.service fails.

Comment 3 Bruce Jerrick 2014-08-16 06:54:25 UTC
Thanks for the info -- I see it's not just a simple omission.

This will just add to the mystery:

Here's 'rpm -q --last' for httpd* (F21 Development kickstart install):

httpd-manual-2.4.10-2.fc21.noarch             Sat Aug  9 10:44:18 2014
httpd-2.4.10-2.local_0.fc21.x86_64            Sat Aug  9 10:24:50 2014
httpd-tools-2.4.10-2.fc21.x86_64              Sat Aug  9 10:23:55 2014
httpd-filesystem-2.4.10-2.fc21.noarch         Sat Aug  9 10:22:33 2014

And for an F22 Rawhide install:

httpd-manual-2.4.10-2.fc22.noarch             Fri Aug  8 14:44:06 2014
httpd-2.4.10-2.fc22.x86_64                    Fri Aug  8 14:18:16 2014
httpd-tools-2.4.10-2.fc22.x86_64              Fri Aug  8 14:16:55 2014
httpd-filesystem-2.4.10-2.fc22.noarch         Fri Aug  8 14:14:52 2014

I don't have access to any packages right now, but I'll poke around
and see what I can find.

(BTW, I added keyword "httpd" to the summary.)

Comment 4 Bruce Jerrick 2014-08-16 07:00:35 UTC
In the kickstart %packages for both installs shown above, I have these
listed explicictly, in this order:


(Which probably doesn't matter.)

Comment 5 Jan Kaluža 2014-08-18 05:23:24 UTC
Can you try to reproduce it with following testing repository please?


Comment 6 Bruce Jerrick 2014-08-20 06:14:44 UTC
I composed the following ("Here's the problem") before I had a chance to see
  your -4 fix.  That's essentially the same as what I did (except that I missed
  making httpd-filesystem also be Requires(pre)).
BTW, is this first line redundant with the Requires(pre)?
  Requires: httpd-filesystem ...
  Requires(pre): httpd-filesystem ...
It will be a few days before I can get back to you on the -4 release, but
  except for the question of redundancy, I'm sure it will fix the problem
  (now where have I heard that before?).
Here's the problem:
'useradd' comes from shadow-utils, and it was installed *after* httpd-filesystem:

  httpd-2.4.10-2.fc21.x86_64             Sat Aug  9 10:24:50 2014
  shadow-utils-    Sat Aug  9 10:22:46 2014
  httpd-filesystem-2.4.10-2.fc21.noarch  Sat Aug  9 10:22:33 2014

The fix is simple:
In the spec file, the "Requires(pre): /usr/sbin/useradd" should be moved to the
  "%package filesystem" section.

That change did the trick for me (based on a -2 release, prior to the extra
  useradd in httpd itself).

Comment 9 Bruce Jerrick 2014-09-01 11:58:01 UTC
(I'm sorry for the delay.)

Everything as is expected with your -4 fixes.
The relevant packages from 'rpm -qa --last':

With 790 packages (quasi-minimal):
  httpd-manual-2.4.10-4.fc21.noarch        Wed Aug 20 18:20:26 2014
  system-config-httpd-1.5.5-7.fc21.noarch  Wed Aug 20 18:20:11 2014
  httpd-2.4.10-4.fc21.x86_64               Wed Aug 20 18:19:25 2014
  httpd-filesystem-2.4.10-4.fc21.noarch    Wed Aug 20 18:18:54 2014
  shadow-utils-      Wed Aug 20 18:18:46 2014
  httpd-tools-2.4.10-4.fc21.x86_64         Wed Aug 20 18:18:35 2014
  fedora-logos-httpd-21.0.3-2.fc21.noarch  Wed Aug 20 18:17:46 2014

With 4511 packages:
  httpd-manual-2.4.10-4.fc21.noarch         Wed Aug 20 19:11:06 2014
  system-config-httpd-1.5.5-7.fc21.noarch   Wed Aug 20 19:07:23 2014
  httpd-2.4.10-4.fc21.x86_64                Wed Aug 20 18:52:19 2014
  httpd-tools-2.4.10-4.fc21.x86_64          Wed Aug 20 18:51:24 2014
  httpd-filesystem-2.4.10-4.fc21.noarch     Wed Aug 20 18:51:11 2014
  shadow-utils-       Wed Aug 20 18:50:20 2014
  fedora-logos-httpd-21.0.3-2.fc21.noarch   Wed Aug 20 18:48:35 2014

(Note how httpd-tools moved.) 

BTW, this was with rpm-4.12.0-0.beta1.3.fc21; packages (other than httpd)
  are those from repomd.xml timestamped 1408445218 (Aug 19 10:46:58 UTC).
And for the record, installs were done on a VMware Workstation 9.0.3
  client, with 2 CPUs and 2 GiB memory.  Host has 8 CPUs and 16 GiB
  memory.  All that memory on the host makes client (virtual) disk I/O
  very fast once it's buffered.  I don't know if that makes any
  difference due to multi-threading; I suppose the package installation
  order is determined by the rpm transaction generator and may actually
  be deterministic (or am I dreaming?).

Comment 10 Fedora Update System 2014-09-03 07:27:38 UTC
httpd-2.4.10-8.fc21 has been submitted as an update for Fedora 21.

Comment 11 Fedora Update System 2014-09-03 15:29:42 UTC
httpd-2.4.10-9.fc21 has been submitted as an update for Fedora 21.

Comment 12 Fedora Update System 2014-09-06 01:01:37 UTC
Package httpd-2.4.10-9.fc21:
* should fix your issue,
* was pushed to the Fedora 21 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing httpd-2.4.10-9.fc21'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).

Comment 13 Fedora Update System 2014-09-23 04:51:07 UTC
httpd-2.4.10-9.fc21 has been pushed to the Fedora 21 stable repository.  If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.