[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Korrupte Files vom Apachen bei Kernel 4.9.0-0.bpo.3-amd64



Heiko Schlittermann <hs@schlittermann.de> wrote:
> Sven Hartge <sven@svenhartge.de> (So 02 Jul 2017 17:49:51 CEST):
>> Heiko Schlittermann <hs@schlittermann.de> wrote:
 
>>>     Apache ------> wget
>>>       |
>>>       +----------,--------,
>>>       |          |        |
>>>      smbfs¹      |      TMPFS
>>>       |          |
>>>      ext4      ext4
>>>       |          |
>>>      LVM        LVM     
>>>       |          | 
>>>      mdadm      mdadm
>>>       |          |
>>>       :          :
>>>      SAS-Box    SAS-Box
>>
>>>       A          B         C
>>
>>> ¹) Das Verzeichnis, in dem das ext4 liegt ist per Samba exportiert
>>>    und wird über smbfs wieder eingehängt. [Frag' nicht, ist so.]
>> 
>> Sorry, aber wenn jemand sagt "frag' nicht", dann ist doch klar, dass
>> hier die Frage kommen muss: Warum?

> For legacy reasons :) Ich glaube, es ging ursprünglich darum, daß
> alles, was unterhalb eines bestimmten Verzeichnisbaums liegt, wie genau
> einer UID gehörend aussieht, auch wenn es in Wirklichkeit
> unterschiedliche sind.

Ahh, "legacy". Ich glaube, du bist hier mit dem System schon einen
Schritt weiter zu "cargo cult".

>>> A zeigt Fehler, B und C scheinen zu funktionieren. Ob immer, weiss
>>> ich nicht. Der Fehler tritt ja auch bei A nicht immer auf und läßt
>>> sich mit einem strace auf dem Apache-Prozess scheinbar ja auch
>>> verhindern.

>> Klassischer Heisenbug: Wenn man ihn ansieht, ist er weg.

> Ja.

Mich würde nicht wundern, wenn ein nicht gerade kleiner Teil von
Close-Source Software da draussen mit aktivierten Debug-Code oder mit
dem Equivalent von "-O0" kompiliert ausgeliefert wird, weil der
Hersteller einen subtilen Race-Condition Bug nicht behoben bekommt.
(Ich habe gerade selbst "Spass" mit so einem Problem in einer sehr
teuren und auch verbreitet eingesetzten Enterprise-Software.)

>> Spass beiseite: Die smbfs-Komponente ist die Kernel-Variante und kein
>> FUSE-basierter mount, oder?

> # ps ax | grep cifs
>   315 ?        S<     0:00 [cifsiod]
>  2917 ?        S      0:04 [cifsd]
> 18234 pts/0    S+     0:00 grep cifs

> Also gehe ich mal nicht von FUSE aus.

Nein, das ist definitiv die Kernel-Variante.

> Ich halte mmap(2) und writev(2) eigentlich für abgehangene Technologie.
> Dem Kernel wirden Adressen von Puffern genannt, die er lesen darf und
> dann schreiben soll auf den Filedescriptor. Wenn es über CIFS läuft sind
> zusätzlich zwei weitere Komponenten involviert: smbd und der
> cifs-Treiber. Daß ich es mit einem einfachen Programm nicht
> reproduzieren kann, mag daran liegen, daß man noch weitere
> Randbedingungen erfüllen muß, die ich bisher nicht kenne, und die der
> Apache erfüllt.

Möglich bis wahrscheinlich. Ich zumindest kann deine Probleme ohne CIFS
nicht nachstellen, egal, was ich anstelle, egal ob reale Hardware oder
VM.

Mein Vorgehen wäre jetzt, wenn man den Bug nicht direkt finden kann
(Zeit den Kernel-Entwickler der CIFS-Komponente zu involvieren?) den
*Grund* für den CIFS-Mount zu enternen, um den Teil loszuwerden, sofern
möglich.

S°

-- 
Sigmentation fault. Core dumped.


Reply to: