Apache2 anomaly

[RonR]

Anyone know what's changed recently with regard to apache2?

After a fresh install of Raspbian Jessie Lite (2016-05-27), I install apache2:

root@raspberrypi:~# apt-get install apache2

At this point, 'service apache2 restart' executes with no warning.

root@raspberrypi:~# service apache2 restart
root@raspberrypi:~#

Following a reboot, however, I get a warning:

Last login: Wed Sep 21 14:31:14 2016 from gigabyte
root@raspberrypi:~# service apache2 restart
Warning: Unit file of apache2.service changed on disk, 'systemctl daemon-reload' recommended.
root@raspberrypi:~#

Following the recommendation clears the warning:

root@raspberrypi:~# systemctl daemon-reload
root@raspberrypi:~# service apache2 restart
root@raspberrypi:~#

After a reboot, however, the problem is back. No changes are being made anywhere.

[mstriani]

Same here... I was looking and reinstall apache... but everytime I reboot... the warning persist

[malicious]

This is a guess based on my less-than-comprehensive understanding of how systemd coexists with System V init scripts.

systemd converts /etc/init.d/ scripts into .service files at boot with a "generator"[1], including the script for Apache. Invoking Apache with "# service apache2 ... " probably causes its .service file to be recreated which systemd notices and issues a warning for. Managing Apache, or another program with an /etc/init.d/ script, with systemd's systemctl[2] instead of going through "service"(which now uses systemd, anyway) should stop the warnings.

Some common systemctl commands:

# systemctl start X
# systemctl stop X
# systemctl reload X (have X reload altered configuration)
# systemctl restart X
# systemctl enable X (have X start at system boot)
# systemctl disable X (stop X from starting at boot)
# systemctl mask X (prevent X from running at boot or via manual invocation)
# systemctl unmask X (reverse "mask")

[1] https://www.freedesktop.org/software/sy ... rator.html
[2] https://www.freedesktop.org/software/sy ... emctl.html

[RonR]

Thanks for the suggestion, malicious, but using systemctl commands result in the very same warnings. After running 'systemctl daemon-reload' to clear the warning followed by a reboot:

Last login: Sat Sep 24 02:41:51 2016 from gigabyte
root@FreePBX:~# systemctl restart apache2
Warning: Unit file of apache2.service changed on disk, 'systemctl daemon-reload' recommended.
root@FreePBX:~#

The mystery continues...

[sb0373]

I am not sure what has changed but do this:

Code: Select all

systemctl disable apache2
systemctl enable apache2

That removes and recreates the service file

[RonR]

I am not sure what has changed but do this:

Code: Select all

systemctl disable apache2
systemctl enable apache2

That removes and recreates the service file

Thanks, but that doesn't fix it either. The warning goes away until after the next reboot:

Last login: Wed Sep 28 02:00:31 2016 from gigabyte
root@FreePBX:~# service apache2 restart
Warning: Unit file of apache2.service changed on disk, 'systemctl daemon-reload' recommended.
root@FreePBX:~#

[castletonroad]

This error

Code: Select all

Warning: Unit file of apache2.service changed on disk, 'systemctl daemon-reload' recommended

...is really annoying me too.

Recurs after reboot.

Like the OP, I only started receiving this recently.

[rasporg]

I have the same problem since a few weeks. On every log-rotate I have the same warning.

To solve that I had to enter "sudo systemctl daemon-reload" which I tried yesterday and the message was not show again. In hte time before I always entered "systemctl daemon-reload" and that did not do anything.

After an reboot the message still activated again until I enter "sudo systemctl daemon-reload"

I am still puzzled why this happens I can't find much information that could solve this problem.

[ojrb]

Hi guys,

I solve the problem as workaround adding the next bold line in /etc/logrotate.d/apache2.

/var/log/apache2/*.log {
daily
missingok
rotate 14
compress
delaycompress
notifempty
create 640 root adm
sharedscripts
postrotate
if /etc/init.d/apache2 status > /dev/null ; then \
/bin/systemctl daemon-reload; \
/etc/init.d/apache2 reload > /dev/null; \
fi; \
endscript
prerotate
if [ -d /etc/logrotate.d/httpd-prerotate ]; then \
run-parts /etc/logrotate.d/httpd-prerotate; \
fi; \
endscript
}

Execute "sudo systemctl daemon-reload"

The next rotate log or system reboot it will not appear the error.

Best regards.

[rasporg]

Thanks "orjb" and is a work around as you write and it does not solve a restart of Apache2 after a reboot before the first logrotate.

The problem in the startup files (systemd) so you end up after a restart with the same problem.

You wrote: Execute "sudo systemctl daemon-reload" after you edited the file but that already was enough to avoid logrotate notices....till the next reboot.

[Radstake]

I added sudo systemctl daemon-reload in /etc/rc.local just before exit 0 and rebooted.
Now on every reboot it runs the systemctl daemon-reload, not the solution but works for me now.....

[rasporg]

Thanks Radstake and this works also for me.

[rdibened]

I've had a Raspberry Pi-2 for over a year and have been running Unbuntu 14.4 on it without issues. I recently upgraded my version to:
Linux version 3.18.0-14-rpi2 (buildd@lcy01-03) (gcc version 4.8.2 (Ubuntu/Linaro 4.8.2-19ubuntu1) ) #15-Ubuntu SMP PREEMPT Wed Feb 18 10:43:15 UTC 2015

And also did an Apt update and Apt upgrade.

Since that time, I have had a number of problems with software that has been running flawlessly for a year on the Pi and many years on other Pi's I own.

Now I am getting this error also:
/etc/cron.daily/logrotate:
Warning: apache2.service changed on disk. Run 'systemctl daemon-reload' to reload units.
Warning: apache2.service changed on disk. Run 'systemctl daemon-reload' to reload units.
logrotate_script: 2: kill: No such process

error: error running non-shared postrotate script for /var/log/samba/log.nmbd of '/var/log/samba/log.nmbd '
run-parts: /etc/cron.daily/logrotate exited with return code 1

Again, I am having the problem where the systemctl daemon-reload corrects the problem, unless I do a reboot or I stop and start the service manually.

My Question, It didn't do this before, so How do I fix it? Have they released a newer version of the OS that isn't buggy like this one is?

To be honest, I am seriously thinking of not updating OS since this is the second big problem I have had with OS updates 1) with Ubuntu and 1) with Raspbian.

I know these are Open Source and Free but I sure with the OS was more fully tested before release.

Anyone that has a solid fix, Please let me know.

[in3vrr]

I have RPI3 with Raspbian Jessie with PIXEL 4.4 and I have the same problem (2 or 3 days ago it worked) but I did not update
With sudo systemctl daemon-reload ..... sudo service apache2 restart .... sudo reboot....... nothing changes !
I use apache only for UPS monitoring using apcupsd and do not connect more (http://<rpi-ip>/cgi-bin/apcupsd/multimon.cgi)
Very strange this thing
.....we hope there is a solution.....
Bob

Today I tried again and it works perfectly
.....I did not do anything

[andocromn]

Anyone ever figure out why Systemd thinks the apache2 file has changed on disk when rebooting? has anyone reported this issue on the Systemd forums?

[aleifuu]

Hi all, I just want to add that I too experience this apache2 anomaly on jessie and on pi3

I have at least 2 pi3 running jessie that was installed using jessie-lite ROM downloaded from the official source, and has noticed same anomaly

At first I thought it could be a bad SD Card error and have reflushed the image to Sandisk SD card that I use on other pi, and it works alright for few days ( I can see phpmyadmin and etc ) untill accessing it from chrome one day would just show connection error, not a 404 or 500 kind of error

What I notice whever I want to restart the apache2 service is the following :
Warning: Unit file changed on disk, 'systemctl daemon-reload' recommended

doing daemon-reload and restart apache2 service would still show connection erorr on its :80


Will post more technical details soon

[YvanSautin]

Hi,
@andocromn

I think the problem is that during a Raspberry cold boot date time is Jan 01 1970 0100.
Service Apache2 starts before the date/time update by the ntp service, the unit file created by systemd is then dated Jan 01 70 and is considered modified.
If someone knows how to make wait the service apache2 for the updating of the date by the service ntp, i think that the problem will be solved.

Y

[Phil333]

try:
sudo a2enmod headers
sudo service apache2 restart

[hkuno9000]

Hi, Phil333

> try:
> sudo a2enmod headers
> sudo service apache2 restart

I tried that, but it did not work out.
Every time "sudo reboot", I received an email at 6:25 am.

Date: Thu, 16 Mar 2017 06:25:11 +0900
Subject: Cron <root@rasberry2> test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )
/etc/cron.daily/logrotate:
Warning: Unit file of apache2.service changed on disk, 'systemctl daemon-reload' recommended.

[acekyle23]

was looking for a solution to this problem. I don't have one but I noticed this occur right after I changed the 000-default.conf file to have DocumentRoot point to another location.

Code: Select all

/etc/apache2/sites-available/000-default.conf

Thought this might help someone smarter than I to figure out the problem/solution.
Cheers

[MillsMess]

I added sudo systemctl daemon-reload in /etc/rc.local just before exit 0 and rebooted.
Now on every reboot it runs the systemctl daemon-reload, not the solution but works for me now.....

Hint: you don't need sudo in front of systemctl daemon-reload in /etc/rc.local, as rc.local runs as root anyway.

While this worked for me as well, the RasPi of a friend of mine seemed to need too much time for ntp, so systemctl daemon-reload was triggered before ntp was finished, although the configuration is pretty much the same and we both have very fast internet connection from the same provider.

The workaround in this case was to add a sleep of 60 seconds before the daemon-reload. The line looks like this now:
(/bin/sleep 60 && systemctl daemon-reload)
You can play around with te sleep time and set it to a lower period. However: no matter how high you set the period, there is no 100% guarantee, that ntp is done when daemon-reload is triggered. 60 seconds should work in 99.99% though, if your connection isn't extraordinary slow.

[MillsMess]

Another solution is, if you don't want to start something else in /etc/rc.local that should be started earlier, to modify /lib/systemd/system/rc-local.service

Instead of
After=network.target
use
After=network.target time-sync.target

You have to make sure, that time-sync target is available. I run Ubuntu 16.04.2 LTS on my RasPi and time-sync.target is available by default.

You can also create your own service that runs after time-sync.target, if you want to leave the After= of /lib/systemd/system/rc-local.service untouched or you need it for something else.

[evilkitty]

Hi guys,

I solve the problem as workaround adding the next bold line in /etc/logrotate.d/apache2.
[snip]

My pi started giving me a daily warning, this solved it, thanks

[wallneradam]

Hi,
@andocromn

I think the problem is that during a Raspberry cold boot date time is Jan 01 1970 0100.
Service Apache2 starts before the date/time update by the ntp service, the unit file created by systemd is then dated Jan 01 70 and is considered modified.
If someone knows how to make wait the service apache2 for the updating of the date by the service ntp, i think that the problem will be solved.

Y

It is indeed the problem. When you (or any script or extension) creates a systemd override, it creates the file at the current time. However on start this will be in the future, because time is not synced and Pi has no hardware clock by default.
The permanent solution:

• go to /etc/systemd/system
• you will see a directory with your service name and ended with ".d"
• inside that dir you will see the override(s), like override.conf (or any file with conf extension)
• you need to modify the time of it by running the following:

  Code: Select all

  sudo touch -d "2000-01-01 00:00:00" ./override.conf

• after reboot the problem will disappear

Hope that helps...