perfSONAR User Q&A and Other Discussion

["Uhl, George D. (GSFC-423.0)[Arctic Slope Technical Services, Inc.]" <>]

Hi Mark,

 

The RPM named python3-parse-crontab was installed.  I’m running CentOS 7.8.  I’m not sure what got stuck during the upgrade but resorting to a good old reboot fixed it.

 

# systemctl status httpd

● httpd.service - The Apache HTTP Server

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

  Drop-In: /etc/systemd/system/httpd.service.d

           └─perfsonar_ulimit_apache.conf

   Active: active (running) since Tue 2020-11-03 19:09:01 UTC; 15min ago

     Docs: man:httpd(8)

           man:apachectl(8)

 Main PID: 2896 (httpd)

   Status: "Total requests: 5003; Current requests/sec: 5.3; Current traffic:  37KB/sec"

   CGroup: /system.slice/httpd.service

           ├─ 2896 /usr/sbin/httpd -DFOREGROUND

           ├─ 3266 pscheduler-api  -DFOREGROUND

           ├─ 3267 pscheduler-api  -DFOREGROUND

           ├─ 3268 pscheduler-api  -DFOREGROUND

           ├─ 3270 pscheduler-api  -DFOREGROUND

           ├─ 3273 pscheduler-api  -DFOREGROUND

           ├─ 3277 pscheduler-api  -DFOREGROUND

           ├─ 3280 pscheduler-api  -DFOREGROUND

           ├─ 3282 pscheduler-api  -DFOREGROUND

           ├─ 3283 pscheduler-api  -DFOREGROUND

           ├─ 3284 pscheduler-api  -DFOREGROUND

           ├─ 3291 /usr/sbin/httpd -DFOREGROUND

           ├─20466 /usr/sbin/httpd -DFOREGROUND

           ├─21091 /usr/sbin/httpd -DFOREGROUND

           ├─24357 /usr/sbin/httpd -DFOREGROUND

           ├─28581 /usr/sbin/httpd -DFOREGROUND

           ├─30097 /usr/sbin/httpd -DFOREGROUND

           ├─30792 /usr/sbin/httpd -DFOREGROUND

           ├─33664 /usr/sbin/httpd -DFOREGROUND

           ├─34117 /usr/sbin/httpd -DFOREGROUND

           └─34249 /usr/sbin/httpd -DFOREGROUND

 

Nov 03 19:09:25 enpl-pt2-10g.eos.nasa.gov httpd[3280]: pscheduler-api INFO     Started

Nov 03 19:09:26 enpl-pt2-10g.eos.nasa.gov httpd[3280]: pscheduler-api INFO     Limits loaded from /etc/pscheduler/limits.conf

Nov 03 19:09:43 enpl-pt2-10g.eos.nasa.gov httpd[3283]: pscheduler-api INFO     Started

Nov 03 19:09:44 enpl-pt2-10g.eos.nasa.gov httpd[3283]: pscheduler-api INFO     Limits loaded from /etc/pscheduler/limits.conf

Nov 03 19:09:47 enpl-pt2-10g.eos.nasa.gov httpd[3277]: pscheduler-api INFO     Started

Nov 03 19:09:48 enpl-pt2-10g.eos.nasa.gov httpd[3277]: pscheduler-api INFO     Limits loaded from /etc/pscheduler/limits.conf

Nov 03 19:10:01 enpl-pt2-10g.eos.nasa.gov httpd[3266]: pscheduler-api INFO     Started

Nov 03 19:10:02 enpl-pt2-10g.eos.nasa.gov httpd[3266]: pscheduler-api INFO     Limits loaded from /etc/pscheduler/limits.conf

 

 

From: <> on behalf of Mark Feit <>
Reply-To: Mark Feit <>
Date: Tuesday, November 3, 2020 at 1:44 PM
To: "George.D.Uhl" <>, "" <>
Cc: "DeBold, Daniel F. (GSFC-423.0)[Arctic Slope Technical Services, Inc.]" <>
Subject: [EXTERNAL] Re: [perfsonar-user] Getting local host httpd errors after v4.3 auto upgrade

 

George Uhl writes:

 

I’m getting major apache errors since last night’s auto upgrade to pS 4.3:

 

SERVERS A and B: 

Nov 03 14:37:44 nasatest2.asf.alaska.edu httpd[28528]: pscheduler-api ERROR    Internal error xxx.xxx.xxx.xxx POST https://<FQDN>/pscheduler/t...liseconds

…

[Tue Nov 03 17:30:22.100392 2020] [wsgi:error] [pid 16748] [remote 137.229.86.189:42812] ImportError: No module named crontab

 

That looks like an upgrade failure.  If you’re on CentOS, you should have a RPM named python3-parse-crontab installed.  That’s a new package that wasn’t present in 4.2, and I’m not seeing it missing in our testbed or a handful of production hosts.  If you’re on Debian, I’ll have to pass you over to Antoine, who runs that corner of the show.

 

 SERVER C (after systemctl restart httpd):

Nov 03 15:17:44 enpl httpd[9185]: AH00558: httpd: Could not reliably determine the server's fully qualified domain name, using fe80::20a:f7ff:fe21:a62c. Set the 'ServerName' dir... this message

Nov 03 15:17:44 enpl httpd[9185]: httpd (pid 40510) already running

Nov 03 15:17:44 enpl systemd[1]: Failed to start The Apache HTTP Server.

Nov 03 15:17:44 enpl systemd[1]: Unit httpd.service entered failed state.

Nov 03 15:17:44 enpl systemd[1]: httpd.service failed.

 

 

We don’t do anything unusual with Apache other than starting and stopping it (and, of course, adding config).  Did the system get itself into a state where the Apache PID file didn’t get erased and the PID got re-used for something else?

 

The AH00558 error is harmless and is standard fare.  We don’t configure ServerName, and there isn’t a need to.

 

--Mark