Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.debian.user > #185688 > unrolled thread

Apache oddness on jessie => stretch upgrade

Started byDave Sherohman <dave@sherohman.org>
First post2017-08-22 11:30 +0200
Last post2017-08-22 12:10 +0200
Articles 4 — 3 participants

Back to article view | Back to linux.debian.user


Contents

  Apache oddness on jessie => stretch upgrade Dave Sherohman <dave@sherohman.org> - 2017-08-22 11:30 +0200
    Re: Apache oddness on jessie => stretch upgrade Sven Hartge <sven@svenhartge.de> - 2017-08-22 12:00 +0200
      Re: Apache oddness on jessie => stretch upgrade Dave Sherohman <dave@sherohman.org> - 2017-08-22 12:10 +0200
    Re: Apache oddness on jessie => stretch upgrade Bastien Durel <bastien@durel.org> - 2017-08-22 12:10 +0200

#185688 — Apache oddness on jessie => stretch upgrade

FromDave Sherohman <dave@sherohman.org>
Date2017-08-22 11:30 +0200
SubjectApache oddness on jessie => stretch upgrade
Message-ID<uhdFw-ng-7@gated-at.bofh.it>
Yesterday, I started on upgrading my servers from jessie to stretch.  It
went mostly without incident at the time, but then apache failed to
restart after logrotate did its thing overnight.

Investigating the apache error log, it ended with:

[Tue Aug 22 06:30:01.223322 2017] [mpm_prefork:notice] [pid 32366] AH00171: Graceful restart requested, doing restart
apache2: Syntax error on line 146 of /etc/apache2/apache2.conf: Syntax error on line 2 of /etc/apache2/mods-enabled/access_compat.load: Cannot load /usr/lib/apache2/modules/mod_access_compat.so into server: /usr/lib/apache2/modules/mod_access_compat.so: undefined symbol: ap_get_useragent_host

The particularly odd part is that this seems to happen only on the first
restart after the upgrade.  If I manually `systemctl start apache2` or
`apachectl graceful`, it successfully starts up with no complaints.
I'll have to wait until tomorrow to see whether this recurs on the next
logrotate run.

Any ideas regarding what's happening here or how to prevent it (other
than doing a manual apache restart immediately after upgrading, to get
the failure out of the way)?


Also, side question: I'm also manually running `systemctl enable
apache2` after upgrading.  How can you tell whether something is enabled
or not in systemd?  `systemctl status` will tell you whether it's
currently running or not, but I can't find any indication of enabled/
disabled in its output.

-- 
Dave Sherohman

[toc] | [next] | [standalone]


#185690

FromSven Hartge <sven@svenhartge.de>
Date2017-08-22 12:00 +0200
Message-ID<uhe8z-z1-41@gated-at.bofh.it>
In reply to#185688
Dave Sherohman <dave@sherohman.org> wrote:

> Also, side question: I'm also manually running `systemctl enable
> apache2` after upgrading.

You shouldn't need to do this, the maintainer scripts in the packages
will do this for you during the upgrade.

*If* you need to do this to get a service started automatically during
boot, then something is wrong with your system.

> How can you tell whether something is enabled or not in systemd?
> `systemctl status` will tell you whether it's currently running or
> not, but I can't find any indication of enabled/ disabled in its
> output.

,----
| # systemctl status ssh.service 
| ● ssh.service - OpenBSD Secure Shell server
|    Loaded: loaded (/lib/systemd/system/ssh.service; enabled)
|    Active: active (running) since Tue 2017-08-22 11:36:46 CEST; 11min ago
|  Main PID: 812 (sshd)
|    CGroup: /system.slice/ssh.service
|            └─812 /usr/sbin/sshd -D
`----

See the "enabled" at the end of the line starting with "Loaded:"? 

Grüße,
Sven.
-- 
Sigmentation fault. Core dumped.

[toc] | [prev] | [next] | [standalone]


#185691

FromDave Sherohman <dave@sherohman.org>
Date2017-08-22 12:10 +0200
Message-ID<uheid-T0-7@gated-at.bofh.it>
In reply to#185690
On Tue, Aug 22, 2017 at 11:49:50AM +0200, Sven Hartge wrote:
> Dave Sherohman <dave@sherohman.org> wrote:
> > Also, side question: I'm also manually running `systemctl enable
> > apache2` after upgrading.
> 
> You shouldn't need to do this, the maintainer scripts in the packages
> will do this for you during the upgrade.
> 
> *If* you need to do this to get a service started automatically during
> boot, then something is wrong with your system.

I've been doing it more just to be certain it was enabled, since I
wasn't sure how to tell if it was already enabled or not.  It probably
wasn't actually needed.

> > How can you tell whether something is enabled or not in systemd?
> > `systemctl status` will tell you whether it's currently running or
> > not, but I can't find any indication of enabled/ disabled in its
> > output.
> 
> ,----
> | # systemctl status ssh.service 
> | ● ssh.service - OpenBSD Secure Shell server
> |    Loaded: loaded (/lib/systemd/system/ssh.service; enabled)
> |    Active: active (running) since Tue 2017-08-22 11:36:46 CEST; 11min ago
> |  Main PID: 812 (sshd)
> |    CGroup: /system.slice/ssh.service
> |            └─812 /usr/sbin/sshd -D
> `----
> 
> See the "enabled" at the end of the line starting with "Loaded:"? 

...

Well, that's embarrassing.  How did I manage to never notice that in all
the times I looked for it?

Thanks!

-- 
Dave Sherohman

[toc] | [prev] | [next] | [standalone]


#185693

FromBastien Durel <bastien@durel.org>
Date2017-08-22 12:10 +0200
Message-ID<uheie-T0-21@gated-at.bofh.it>
In reply to#185688
Le mardi 22 août 2017 à 03:58 -0500, Dave Sherohman a écrit :
> 
[...]
> Also, side question: I'm also manually running `systemctl enable
> apache2` after upgrading.  How can you tell whether something is
> enabled
> or not in systemd?  `systemctl status` will tell you whether it's
> currently running or not, but I can't find any indication of enabled/
> disabled in its output.
> 
Hello.

Second line of systemctl status output:

Loaded: loaded (/lib/systemd/system/apache2.service; enabled; vendor
preset: enabled)

or for disabled service:

Loaded: loaded (/lib/systemd/system/bgpd.service; disabled; vendor
preset: enabled)

-- 
Bastien

[toc] | [prev] | [standalone]


Back to top | Article view | linux.debian.user


csiph-web