Arch Linux

toco

Member

Registered: 2015-08-16

Posts: 21

Website

Apachectl restart *produce Fatal Python Error

journalctl -xeu httpd shows only

systemd[1]: httpd.service: Main process exited, code=dumped, status=6/ABRT
systemd[1]: httpd.service: Failed with result 'core-dump'.

tail -f /var/log/httpd/error_log
[Thu Apr 26 19:18:13.434470 2018] [proxy_hcheck:debug] [pid 14596] mod_proxy_hcheck.c(969): AH03261: stopping _proxy_hcheck_ watchdog.
[Thu Apr 26 19:18:13.438493 2018] [watchdog:debug] [pid 14618] mod_watchdog.c(254): AH02973: Singleton Watchdog (_proxy_hcheck_) stopping
[Thu Apr 26 19:18:13.440777 2018] [watchdog:debug] [pid 14596] mod_watchdog.c(254): AH02973: Singleton Watchdog (_proxy_hcheck_) stopping
[Thu Apr 26 19:18:13.504521 2018] [mpm_prefork:notice] [pid 14595] AH00173: SIGHUP received.  Attempting to restart
[Thu Apr 26 19:18:13.571902 2018] [ssl:warn] [pid 14595] AH01873: Init: Session Cache is not configured [hint: SSLSessionCache]
[Thu Apr 26 19:18:13.571953 2018] [ssl:info] [pid 14595] AH01887: Init: Initializing (virtual) servers for SSL
[Thu Apr 26 19:18:13.571973 2018] [ssl:info] [pid 14595] AH01876: mod_ssl/2.4.33 compiled against Server: Apache/2.4.33, Library: OpenSSL/1.1.0h
[Thu Apr 26 19:18:13.572216 2018] [:notice] [pid 14595] mod_python: Creating 8 session mutexes based on 250 max processes and 0 max threads.
[Thu Apr 26 19:18:13.572239 2018] [:notice] [pid 14595] mod_python: using mutex_directory /tmp
Fatal Python error: PyEval_SaveThread: NULL tstate

Any ideas how to fix the apachectl command ?

apachectl status shows

# apachectl status
               Apache Server Status for localhost (via 127.0.0.1)

   Server Version: Apache/2.4.33 (Unix) OpenSSL/1.1.0h mod_python/3.5.0-
          Python/2.7.14 PHP/7.2.5

   Server MPM: prefork
   Server Built: Apr 2 2018 12:13:59
     __________________________________________________________________

   Current Time: Thursday, 26-Apr-2018 20:23:43 CEST
   Restart Time: Thursday, 26-Apr-2018 20:23:42 CEST
   Parent Server Config. Generation: 1
   Parent Server MPM Generation: 0
   Server uptime:
   Server load: 0.12 0.16 0.16
   Total accesses: 0 - Total Traffic: 0 kB
   CPU Usage: u0 s0 cu0 cs0
   1 requests currently being processed, 4 idle workers

W____...........................................................
................................................................
................................................................
..........................................................

   Scoreboard Key:
   "_" Waiting for Connection, "S" Starting up, "R" Reading Request,
   "W" Sending Reply, "K" Keepalive (read), "D" DNS Lookup,
   "C" Closing connection, "L" Logging, "G" Gracefully finishing,
   "I" Idle cleanup of worker, "." Open slot with no current process

systemd is using it obviously, than apache goes down ....

Last edited by toco (2018-05-15 10:15:31)

x33a

Forum Fellow

Registered: 2009-08-15

Posts: 4,587

Re: Apachectl restart *produce Fatal Python Error

What happens if you use systemctl instead? And what happens in case of stop/start instead?

toco

Member

Registered: 2015-08-16

Posts: 21

Website

Re: Apachectl restart *produce Fatal Python Error

Hey systemctl is working but apachectl "start stop restart", only "stop" is working... the restart after needs to be a systemctl restart ...

while I'm stoping with "apachectl stop"

I get from journalctl -xefu httpd

Mai 03 13:41:35 Archlinux httpd[32025]: httpd (no pid file) not running

and from httpd/error_log a tail -f

[Thu May 03 13:41:35.244426 2018] [core:info] [pid 31807] AH00096: removed PID file /run/httpd/httpd.pid (pid=31807)
[Thu May 03 13:41:35.244507 2018] [mpm_prefork:notice] [pid 31807] AH00169: caught SIGTERM, shutting down

Last edited by toco (2018-05-07 06:53:52)

toco

Member

Registered: 2015-08-16

Posts: 21

Website

Re: Apachectl restart *produce Fatal Python Error

No ideas how I can fix this? Once a week the systemd seems to use apachectl to reload the server and it's crashing. Every the time I need a manual "systemctl restart httpd" to handle it...
I checked the crontab, it's clean...