Errors will either be in /var/log/syslog, /var/log/messages, or one of the files in /var/log/httpd (do an ls -lt to see the most recently changed).

"systemctl" is a command that you issue as root from a command line prompt.

The command to start httpd is "service httpd start".

CC: (none) => ftg

Created attachment 2563 [details]
httpd start error

Here's what gets written to the logs.

Same problem here. This is pretty critical as Apache is unable to start at all. Guillaume, did you manage to make Apache work when upgrading it to 2.4.2?

Priority: Normal => High
CC: (none) => LpSolit
Severity: normal => critical

The httpd-prefork systemd unit doesn't exist anymore since the switch to apache 2.4. The value hardcoded in drakxservices ought to be fixed, but that's an issue for drakxtools package, not for apache package.

BTW, using systemctl commands seems safer than using service command, as it one is merely a sysinit-era command, and will probably get dropped in a pure systemd system.

Priority: High => Normal
Assignee: guillomovitch => bugsquad
Source RPM: apache-2.4.2-1.mga3.i586.rpm => drakxtools

This is obviously not a drakxtools bug

Source RPM: drakxtools => apache

The problem is not about systemctl vs service. The problem is that httpd.conf contains lots of "LoadModule foo.so" and those are not found by Apache, and so it fails. Also, the path to modules.d changed, which is another reason why it fails to start. If you replace the old httpd.conf from Apache 2.2 by httpd.conf.rpmnew from 2.4, then it starts correctly. So it seems that the old httpd.conf from 2.2 is not compatible as-is with 2.4. That's what this bug is about.

opening a tracker so someone do something before mga3

A more

Summary: Apache ( httpd ) no longer runs at startup in Cauldron (httpd: Syntax error) => Apache configuration file handling during upgrade

This issue deserves a more explicit title.

The new setup is quite different, and the list of available modules also. I fear than any attempt to fix the configuration magically during post-installation will just rather make the situation even worse. They are not just LoadModule directives to change/remove, they are also all the other directives now splitted in additional files. For me, it's safer to let the end user handle it himself when we don't have a simple and failproof solution.

This bug is still valid for me in M3A2 on
10/15/12 using boot.iso 10/02/12 32-bit

I have installed "apache" from MCC -> Install & Remove Software -> "apache"
and that works ok. As root I can create and modify /var/www/html/index.html
and that works just fine. Is there a simple way to activate the ability
to get /home/username/public_html/index.html working again? That would
get me/us going again.

I agree looking at M2 Apache 2.2.x vs M3 Apache 2.4.x is a major change.
Maybe there's a simple set of instructions to get it working in
a minimum format.

Thanks

A little tinkering around here with Apache ( httpd ) 2.4.x on Cauldron I find
that the apache-mod_userdir is not installed.
Using the MCC -> Software Management -> Install and Remove Software -> apache-mod_userdir
that installs the necessary Apache module to allow the public_html directory to
contain a users website. So using the MCC in M3 install

apache
apache-mod_userdir

I get all the functionality I need without needing to install and use drakwizard. At least so far as I have seen. I'm not quite ready to call this discussion
resolved but for me it seems to work.

I just don't want to become an Apache installation expert.

Well, the split in a distinct module was made on purpose, so it can hardly get considered as a bug. If you're running a server, you're expected to know what you need better than the packager. Anyway, it doesn't have much relationship with the original issue...

Guillaume Rousse said in Comment 13:

> If you're running a server, you're expected to know what
> you need better than the packager.

While I agree with that the problem is that
Mandrake/Mandriva/Mageia has a long history
of making this install extremely simple and
and the admin need not be an Apache expert
to get this working. A few keystrokes in
drakwizard and you've a working httpd server.
Are we now backing off that feature function?

William, you are out of topic. Please file a separate bug for your request. No need to spam everybody about apache-mod_userdir.

ping for the beta1

As already said, it's a WONTFIX for me, unless someone has something robust and reasonnably complete to suggest for handling the setup change.

What you say is that you are going to intentionally break old Apache 2.2 configuration servers when upgrading from Mageia 2 to 3. I know at least one application which will be directly affected by these incompatibilities: Bugzilla. If you keep the old Apache config file, Apache won't start. If you choose the new config file, relevant config data for Bugzilla will be gone and Bugzilla won't work anymore.

You will at least have to find a way to notify admins very clearly about the incompatibilities. Release notes are one place. Not sure if that's enough. rpmdrake would have to alert the user too when upgrading this package.

"intentionally break old Apache 2.2" is a bit excessive, it's just an unfortunate side-effect of packaging setup changes. And even without those changes, upstream changes would probably have the same effect anyway...

So far, here are the most proeminent changes I'm aware of, and ought to be documented:
- modules files are now located under /usr/lib(64)/httpd/modules, but the relative path from apache base directory (/etc/httpd/modules) didn't change
- all modules loading directives are now located in files located under /etc/httpd/conf/modules.d, and are likely to duplicate legacy directives from /etc/httpd/conf/httpd.conf
- httpd.conf now contains only core directives, many other are now located in various files under /etc/httpd/conf/conf.d
- additional upstream changes documented here: http://httpd.apache.org/docs/2.4/upgrading.html

Anything else ?

Also, Fedora 18, which introduced apache 2.4, doesn't have anything specific in its release notes. Changes may have been less drastic, tough.

I just added a README.update.urpmi file advertising those changes in incoming 2.4.4-5mga3 release.

Status: NEW => RESOLVED
Resolution: (none) => FIXED

*** Bug 10504 has been marked as a duplicate of this bug. ***

CC: (none) => flink