Skip to content

Defunct fcgid/fastcgi processes in Debian Jessie apache2

Wenn ihr unter dem aktuellen stabilen Release von Debian GNU/Linux - Codename Jessie - den Webserver Apache2 zusammen mit fcgid oder fastcgi einsetzt und von (z.B.) PHP-Prozessen geplagt werdet, die nicht richtig beendet werden und stattdessen als Zombie mit dem Zusatz <defunct> weiter in der Prozessliste rumgammeln bis FcgidMaxProcesses oder FcgidMaxProcessesPerClass erreicht ist und Eure Seite dann nicht mehr erreichbar ist, habe ich hier die Lösung für Euch.

So sieht das Problem aus:

% ps f -o user,pid,nice,%cpu,%mem,cputime,etime,tty8,command ax
USER       PID  NI %CPU %MEM     TIME     ELAPSED TTY      COMMAND
root     11886   0  0.0  0.0 00:00:12    08:45:37 ?        /usr/sbin/apache2 -k start
www-data 26825   0  0.0  0.0 00:00:04    06:27:00 ?         \_ /usr/sbin/apache2 -k start
user4    26854   0  3.3  0.0 00:13:07    06:27:00 ?         |   \_ [php5] <defunct>
user4    26856   0  5.6  0.0 00:21:45    06:27:00 ?         |   \_ [php5] <defunct>
user3    26976   0  0.3  0.0 00:01:31    06:26:51 ?         |   \_ [php5] <defunct>
user4    27389   0  5.1  0.0 00:19:37    06:23:13 ?         |   \_ [php5] <defunct>
user2     7283   0  1.5  0.0 00:04:08    04:32:24 ?         |   \_ [php5] <defunct>
user1    12657   0  1.2  0.0 00:02:56    03:46:37 ?         |   \_ [php5] <defunct>
user1    12680   0  1.9  0.2 00:04:23    03:46:35 ?         |   \_ /usr/lib/cgi-bin/php5
user2    19589   0  0.9  0.0 00:01:36    02:47:44 ?         |   \_ [php5] <defunct>
user3    21574   0  0.6  0.0 00:00:56    02:31:46 ?         |   \_ [php5] <defunct>
user4    24239   0  1.4  0.0 00:01:56    02:11:06 ?         |   \_ [php5] <defunct>
user4    24241   0  2.3  0.0 00:03:07    02:11:06 ?         |   \_ [php5] <defunct>
user4    24252   0  2.1  0.0 00:02:47    02:11:06 ?         |   \_ [php5] <defunct>
user4    24253   0  1.7  0.0 00:02:15    02:11:06 ?         |   \_ [php5] <defunct>
user4    24254   0  5.6  0.2 00:07:24    02:11:06 ?         |   \_ /usr/lib/cgi-bin/php5
user2    28074   0  1.0  0.0 00:00:57    01:30:14 ?         |   \_ [php5] <defunct>
user2    28088   0  1.8  0.2 00:01:42    01:30:14 ?         |   \_ /usr/lib/cgi-bin/php5
user2    30171   0  1.9  0.2 00:01:31    01:16:54 ?         |   \_ /usr/lib/cgi-bin/php5
user4    30676   0  5.4  0.2 00:04:05    01:15:05 ?         |   \_ /usr/lib/cgi-bin/php5
user4    30678   0  4.7  0.2 00:03:34    01:15:05 ?         |   \_ /usr/lib/cgi-bin/php5
user4    31164   0  5.7  0.2 00:04:11    01:13:10 ?         |   \_ /usr/lib/cgi-bin/php5
user3    32378   0  1.8  0.2 00:01:07    01:02:07 ?         |   \_ /usr/lib/cgi-bin/php5
user3    32385   0  1.4  0.2 00:00:53    01:02:06 ?         |   \_ /usr/lib/cgi-bin/php5
user3    32395   0  1.3  0.2 00:00:48    01:02:06 ?         |   \_ /usr/lib/cgi-bin/php5
user3    32402   0  1.6  0.2 00:01:01    01:02:06 ?         |   \_ /usr/lib/cgi-bin/php5
user3    32410   0  1.1  0.2 00:00:44    01:02:05 ?         |   \_ /usr/lib/cgi-bin/php5
user1      418   0  1.4  0.2 00:00:52       59:03 ?         |   \_ /usr/lib/cgi-bin/php5
user1      433   0  2.1  0.2 00:01:15       59:02 ?         |   \_ /usr/lib/cgi-bin/php5
user1      436   0  2.5  0.2 00:01:30       59:02 ?         |   \_ /usr/lib/cgi-bin/php5
user4     1266   0  4.9  0.2 00:02:31       51:23 ?         |   \_ /usr/lib/cgi-bin/php5
user2     3231   0  3.3  0.2 00:01:14       36:57 ?         |   \_ /usr/lib/cgi-bin/php5
www-data  6830   0  1.1  0.1 00:00:07       10:42 ?         \_ /usr/sbin/apache2 -k start
www-data  7145   0  1.2  0.1 00:00:06       08:23 ?         \_ /usr/sbin/apache2 -k start
www-data  7183   0  1.0  0.1 00:00:04       08:11 ?         \_ /usr/sbin/apache2 -k start

Der Webserver läuft seit fast 9 Stunden und es gibt viele fcgid-Prozesse (in diesem Fall PHP), die nicht korrekt beendet wurden und stattdessen als Zombie weiterleben. Zombie-Prozesse sind in der Regel kein Problem, da sie keine Ressourcen verbrauchen. In diesem Fall führt es aber dazu, dass die Zombie-Prozesse weiterhin mitgezählt werden und irgendwann keine neuen php5-Prozesse mehr gestartet werden, weil ja bereits genügend laufen. Je nach Traffic des Webservers ist so bereits nach ein paar Stunden das Limit erreicht und die Webseite(n) werden unerreichbar. Wird viel Traffic über verschlüsseltes SSL/TLS abgewickelt, erhöht das die Chancen, von diesem Problem betroffen zu sein.

Gleichzeitig findet mal im error.log des Webservers folgende Einträge:

[mpm_worker:emerg] [pid 18908:tid 139812686178048] (35)Resource deadlock avoided: AH00273: apr_proc_mutex_lock failed. Attempting to shutdown process gracefully.
[ssl:warn] [pid 31524:tid 140433418090240] (35)Resource deadlock avoided: AH02026: Failed to acquire SSL session cache lock

Die Lösung: in /etc/apache2/apache2.conf die folgende Zeile auskommentieren:

Mutex file:${APACHE_LOCK_DIR} default

Quellen:

Siehe auch Changelog zu apache2-2.4.20-1:

apache2 (2.4.20-1) unstable; urgency=medium

  • New upstream release - mostly bugfixes and HTTP/2 improvements
  • Build against lua 5.2 instead of 5.1. Closes: #820243
  • Correct systemd-sysv-generator behavior by customizing some parameters. This fixes 'systemctl status' returning incorrect results. Thanks to Pierre-André MOREY for the patch. LP: #1488962
  • On Linux, use pthread mutexes. On kfreebsd/hurd, continue using fctnl because they lack robust pthred mutexes. LP: #1565744, #1527044

-- Stefan Fritsch <sf@debian.org>  Sun, 10 Apr 2016 14:03:41 +0200

Tagged , , , , , , ,

hpsa Abort request on C0:B0:T0:L0 FAILED. Aborted command has not completed after 30 seconds.

When you're running Linux on a HP Proliant Server with a SmartArray Controller attached and have errors in Syslog like

hpsa 0000:0e:00.0: Abort request on C0:B0:T0:L0
hpsa 0000:0e:00.0: ABORT REQUEST on C0:B0:T0:L0 Tag:0x00000000:00000010 Command:0x28 SN:0x88896  REQUEST SUCCEEDED.
hpsa 0000:0e:00.0: ABORT REQUEST on C0:B0:T0:L0 Tag:0x00000000:00000010 Command:0x28 SN:0x88896  FAILED. Aborted command has not completed after 30 seconds.
hpsa 0000:0e:00.0: resetting device 0:0:0:0
hpsa 0000:0e:00.0: device is ready.

and disk IO hangs but the SmartArray Controller reports no problems at all

Smart Array P410i in Slot 0 (Embedded)

   array A (SAS, Unused Space: 0  MB)

      logicaldrive 1 (558.7 GB, RAID 1+0, OK)

      physicaldrive 2I:1:1 (port 2I:box 1:bay 1, SAS, 300 GB, OK)
      physicaldrive 2I:1:2 (port 2I:box 1:bay 2, SAS, 300 GB, OK)
      physicaldrive 2I:1:3 (port 2I:box 1:bay 3, SAS, 300 GB, OK)
      physicaldrive 2I:1:4 (port 2I:box 1:bay 4, SAS, 300 GB, OK)

then chances are high that you have one drive that is going to die very soon.

After some hours and some more IO stalls and kernel logs like above the disk status will hopefully change to this:

Smart Array P410i in Slot 0 (Embedded)

   array A (SAS, Unused Space: 0  MB)

      logicaldrive 1 (558.7 GB, RAID 1+0, OK)

      physicaldrive 2I:1:1 (port 2I:box 1:bay 1, SAS, 300 GB, OK)
      physicaldrive 2I:1:2 (port 2I:box 1:bay 2, SAS, 300 GB, Predictive Failure)
      physicaldrive 2I:1:3 (port 2I:box 1:bay 3, SAS, 300 GB, OK)
      physicaldrive 2I:1:4 (port 2I:box 1:bay 4, SAS, 300 GB, OK)

Now you know which disk is causing the problem and can replace it.

Tagged , ,

Wenn im Planetarium Münster das Betriebssystem abstürzt

Im LWL-Museum für Naturkunde fiel am Samstag im Planetarium während der Vorstellung "Ferne Welten – fremdes Leben?" völlig unverhofft die Projektion aus, die Beleuchtung ging an und alle fragten sich, was wohl passiert sei:

Der Mitarbeiter, der den Projektor bediente und die Einführung in die Veranstaltung gab, bat um Entschuldigung und meinte, dass die Zwangsunterbrechung der Vorstellung mal wieder an Windows läge. Nach einem Reboot des Fulldome-Projektionssystem DigitalSky 2 projizierte das System dann 24x einen Windows-Desktop an die Kuppel (3000px):

Nach einem Neustart der entsprechenden Anwendung lief die Projektion dann unterbrechungsfrei bis zum Ende der Vorstellung durch:

Tagged , , , ,

Samsung Spinpoint F1

Gerade eben ist wieder eine Samsung Spinpoint F1 in meinem Desktop-Rechner gestorben ... das ist jetzt die vierte (!) Platte innerhalb von nur 8,5 Monaten.

  1. 12.02.2010 Samsung Spinpoint F1 HD103UJ SMART Self-test: Read failure
  2. 07.07.2010 Samsung Spinpoint F1 HD103UJ FAILED SMART self-check. BACK UP DATA NOW!
  3. 03.09.2010 Samsung Spinpoint F1 HD103UJ SError: { UnrecovData Handshk }, ES-Tool: RAM-Error
  4. 05.03.2011 Samsung Spinpoint F1 HD103UJ SError: { UnrecovData Handshk }, ES-Tool: RAM-Error
  5. 24.03.2011 Samsung Spinpoint F1 HD103SJ ES-Tool: AJ36 Bad Sector, SMART Extended offline Completed: read failure

Bisher wurde von Samsung zwar jede von mir eingeschickte Platte anstandslos getauscht ... aber ich hätte doch gerne eine die länger als ein paar Monate durchhält.

Weiß jemand, ob diese Serie besonders oft von Ausfällen betroffen ist?

Tagged ,

Militärischer Sicherheitsbereich

Das Betreten/Befahren von militärischen Sicherheitsbereichen muss nicht zwangsläufig ordnungswidrig sein:

So wurde mir vorgeworfen, gegen § 114 OWiG verstoßen zu haben (PDF), als ich mit meinem Fahrzeug befestigte Straßen in einem Wald militärischen Sicherheitsbereich befuhr.

Von kämpferischer Laune beflügelt und in der Hoffnung, das Verwarnungsgeld in Höhe von 35 Euro sinnvoller investieren zu können, formulierte ich mit Unterstützung einer guten Freundin meinen Widerspruch (PDF) und harrte der Dinge, die da kommen würden.

Knappe 2 Wochen später lag dann auch schon die Antwort der Wehrverwaltung (PDF) im Briefkasten.

Fazit: Glück (Recht?) gehabt.

Tagged , ,

No DRI/XVideo with radeon after Upgrading to openSUSE 11.3

After upgrading openSUSE 11.2 to 11.3 my

VGA compatible controller: ATI Technologies Inc RV370 5B60 [Radeon X300 (PCIE)]

couldn't use DRI anymore and thus XVideo (e.g. with mplayer) wasn't available anymore.

Error in dmesg:

[drm] radeon: cp idle (0x10000C03)
[drm] Loading R300 Microcode
[drm] radeon: ring at 0x00000000B8000000
[drm:r100_ring_test] *ERROR* radeon: ring test failed (sracth(0x15E4)=0xCAFEDEAD)
[drm:r100_cp_init] *ERROR* radeon: cp isn't working (-22).
[drm:r100_cp_fini] *ERROR* Wait for CP idle timeout, shutting down CP.
[drm] radeon: cp finalized

Error in Xorg.0.log:

(II) AIGLX: Screen 0 is not DRI2 capable
(II) AIGLX: Screen 0 is not DRI capable

glxinfo:

% glxinfo | grep direct
direct rendering: No

xvinfo:

% xvinfo
X-Video Extension version 2.2
screen #0
no adaptors present

Solution:

  1. Remove any vga= options from /boot/grub/menu.lst (e.g. vga=0x31b)
  2. Disable bootsplash in /etc/sysconfig/bootsplash
  3. mkinitrd
  4. reboot

Thanks to hifi and Ke in #radeon on irc.freenode.net for their help and input on this matter.

Edit:

If this doesn't help, try adding

nomodeset

to the kernel command line in /boot/grub/menu.lst (or just try the failsafe boot option which has this option added by default).

Thanks to cb400f in #suse on irc.freenode.net for pointing this out.

Tagged , , , ,

Morgens um 7:12 im Büro

31,1°C um 7:12 Uhr im Büro

Bietet jemand mehr?

Tagged

Sylvain Whites "The Losers" crypto disk decoded

In Sylvain Whites The Losers some guys and a hot chick steal a crypto disk from the bad guy named Max.

After obtaining the decryption code the tech guy is able to decode the hard drive:

See still images of the decryption sequence here, here and here.

The obtained code actually is the HTML code of MathCode download page at mathcore.com, worth $400 million.

I laughed out loud. :)

Tagged

Helo command rejected: Host not found

Aus dem Logfile unseres Firmen-MTAs:

reject: RCPT from gw01.zanox.com[217.110.111.101]: 554 <z-de-dom02.zanox.com>: Helo command rejected: Host not found; from=<XXXXXX@zanox.com> to=<YYYYYYY>

Schon erstaunlich wie sich solch große Firmen wie Zanox solche Anfängerfehler Schnitzer leisten.

Wie liefern die überhaupt irgendwo Emails ein?

Tagged , , , ,

Facebooks mailserver listed in SPAMCOP, ix.dnsbl.manitu.net, mails looking fishy

This is going to be a little bit technical.

User enters ********@ks-webstyle.de on facebook register form. Facebook checks if entered address can receive mail.
Postfix does sender verification (reject_unverified_sender), policyd-weight checks DNS, RBLs and some other stuff.
69.63.178.167 is listed in ix.dnsbl.manitu.net, oops! Overall rated as spam since some checks made this email look fishy:
Continue reading ›

Tagged , , ,