# UDEV-Problem, aber keines der bekannten...

## Chacabaou

Hallo,

wie ich im Betreff schon angedeutet hab, habe ich ein Problem mit UDEV, was scheinbar keines der known-issues ist. Ich hoffe, dass ich mich deutlich genug von den unzähligen Threads über die bekannten Probleme absetzen kann.  :Wink: 

Und zwar ist es so, dass sich mein udev in unregelmäßigen Abständen ohne erkennenbaren Grund irgendwie verabschiedet, was ich daran erkenne, dass ich als User z.B. nicht mehr auf /dev/null schreiben darf. Mit udevstart lässt sich das wieder beseitigen, aber früher oder später (meist Stunden) passiert es wieder.

Zuerst dachte ich, dass das Ding halt nur aussetzt, und ich vielleicht mal mit MAKEDEV brauchbare Devicenodes im Mountpoint ablegen sollte. Zumindest /dev/null und /dev/console, wie es auch in der Anleitung steht.

Ich hab also nachgeguckt, und festgestellt, dass diese Dateien vorhanden sind, also selbst bei völligem Ausfall von udev (oder gar keinem Starten beim Boot) alles einigermaßen funktionieren sollte.

Praktischerweise ist es gerade eben wieder passiert, also kann ich hier mal zeigen, wie das aussieht, wenn ich dann ein Terminal öffne (währenddessen durch allerlei bashrc-Sachen ja vieles nach /dev/null geschickt wird):

```
bash: /dev/null: Permission denied

# davon etwa 50 Zeilen

bash: /dev/null: Permission denied

daniel@mickey ~ $ ls -al /dev/null

-rw-r--r--  1 root root 0 Jul  6 17:13 /dev/null

daniel@mickey ~ $ 
```

Ist wohl relativ deutlich, dass da was nicht stimmen kann.

Weiß jemand Rat?

Vielen Dank im Voraus,

Daniel

----------

## Xylometer

Schaut schwer nach einem Rechteproblem aus. Die Frage ist wer hier Schuld hat.

Ich würde PAM als erstes verdächtigen.

Lösung hab ich aber keine im Ärmel, noch nicht  :Evil or Very Mad: 

Hast du denn schon mal die Logfiles befragt?

----------

## Chacabaou

Die Logfiles schweigen sich völlig darüber aus, das passiert immer im Stillen. Ich merke es auch meistens erst an den Fehlermeldungen beim Öffnen eines neuen Terminals.

Ein Permissionsproblem kann es eigentlich nicht sein, weil es im "Normalfall" ja funktioniert.

Dasselbe Output wie oben nochmal, während UDEV keine Probleme macht:

```
daniel@mickey ~ $ ls -al /dev/null

crw-rw-rw-  1 root root 1, 3 Jul  6 18:23 /dev/null

daniel@mickey ~ $ 
```

Hier ist /dev/null korrekterweise eine Devicenode...oben ist es nur eine Datei.

Da liegt IMHO definitiv der Fehler, aber wie es dazu kommt ist mir unklar.

Ich hab übrigens auch mal udev_log=yes probiert, aber es scheint nirgends dokumentiert zu sein, WO diese Logs dann sein sollen. Im syslog jedenfalls nicht.

----------

## Silicoid

Sieht so aus, als würde ein Script /dev/null löschen. Das nächtse, was dann unter root läuft und seine Ausgabe nach /dev/null umleiten will, legt dann ein File an.

An deinem Output sieht man deutlich, daß das eine ein File und das andere ein Charekter-Device ist:

```

-rw-r--r--  1 root root 0 Jul  6 17:13 /dev/null

crw-rw-rw-  1 root root 1, 3 Jul  6 18:23 /dev/null

```

Hast du irgendwelche Scripten im root-cron oder in der cron.daily/hourly?

----------

## Chacabaou

 *Silicoid wrote:*   

> Hast du irgendwelche Scripten im root-cron oder in der cron.daily/hourly?

 

Klar, einige sogar. Die haben sich aber schon vor dem Umstieg auf UDEV seit längerem nicht geändert, also hätte das Problem ja auch schon vorher auftreten müssen.

Oder wäre es unter devfs nicht möglich gewesen, /dev/null zu löschen?

Ich bin mir nichtsdestrotrotz sehr sicher, dass keines meiner als root ausgeführten Shellscripts versucht, /dev/null zu löschen. Wobei es aber eine logische Erklärung wäre, dass dadurch dann eine normale Datei angelegt wird.

Beim nächsten Ausfall (mittlerweile waren es übrigens schon wieder ca. fünf Stück) werde ich mal gucken, ob neben /dev/null noch andere Devicenodes davon betroffen sind.

----------

## Silicoid

Mach vielleicht auch mal nen 

```

grep cron /var/log/messages

```

vielleicht läuft ja zu der Zeit jeweils ein bestimmter cronjob. Schreib dir vielleicht auch ein Script, daß dir permanent /dev/null prüft und wenn es sich geändert hat das dann in ein Logfile schreibt. So bekommst du vielleicht den genauen Zeitpunkt raus. Vielleicht auch gleich noch nen ps wegschreiben.

----------

## Fauli

 *Chacabaou wrote:*   

> Und zwar ist es so, dass sich mein udev in unregelmäßigen Abständen ohne erkennenbaren Grund irgendwie verabschiedet, was ich daran erkenne, dass ich als User z.B. nicht mehr auf /dev/null schreiben darf.

 

Läuft dann udevd noch?

```
# ps -C udevd

PID TTY          TIME CMD

366 ?        00:00:00 udevd
```

----------

## Chacabaou

Also während alles funktioniert, läuft udevd.

Ob er bei einem solchen Ausfall nicht läuft (und erst durch udevstart wieder), kann ich jetzt nicht 100%ig sagen, glaube ich aber schon.

Wie ich schon sagte, dem Verhalten nach sieht es ganz nach Silicoids Vermutung aus.

Ich hab jetzt mal eine Schleife am laufen, um den genauen Zeitpunkt festzuhalten, wann es passiert. Vielleicht ist tatsächlich ein cronjob der Auslöser.

Das Ganze ist übrigens schon seit dem 27. Juni so, also auch die zwei udev-updates, die es seitdem gab, haben nichts geändert.

----------

## Chacabaou

Ich bumpe das hier jetzt mal hoch, weil das Problem leider immernoch besteht, und ich keine Ursache bei cron finden konnte.

Hat mittlerweile vielleicht jemand eine Idee, oder ein ähnliches Problem im Forum bemerkt? Ich bin hier leider nicht so oft lesend aktiv.

----------

## genstef

Hast du das in deinen udev rules stehen?

```
KERNEL=="null",         NAME="%k", MODE="0666"

```

----------

## Silicoid

Das einzige was mir erstmal einfällt wären ACLs. Hab allerdings selber noch nichts damit gemacht. Aber über ACLs sollte es die möglichkeit geben, daß du das löschen von /dev/null verbietest.

Dann einfach nach der Fehlermeldung ausschau halten, daß /dev/null nicht gelöscht werden kann.

Die Brutale Variante wäre z.B. ein Hardend Kernel das löschen von Files protokolliert. Das ging IMHO unter 2.4.

Is aber schon ne Weile her.

----------

## Chacabaou

 *genstef wrote:*   

> Hast du das in deinen udev rules stehen?
> 
> ```
> KERNEL=="null",         NAME="%k", MODE="0666"
> 
> ...

 

Ja. Ist das nun gut oder schlecht?  :Smile: 

 *Silicoid wrote:*   

> Die Brutale Variante wäre z.B. ein Hardend Kernel das löschen von Files protokolliert. Das ging IMHO unter 2.4.
> 
> Is aber schon ne Weile her.

 

Die Idee klingt prinzipiell gar nicht doof. Zumindest könnte ich so sehr genau feststellen, wer/was für die Löschung verantwortlich ist. Eine Fehlermeldung a la "failed to delete /dev/null" muss ja von entsprechenden Prozess nicht unbedingt ausgegeben werden.

Hat jemand nähere Infos zu einem solchen hardened-kernel? Wie aufwändig wäre es, meine jetzigen nitro-sources möglichst unverändert zu lassen, und trotzdem Feature von protokollierten Löschungen zu bekommen? Lohnt sich das, oder sollte ich mir den Stress lieber sparen?

----------

## Keepoer

Hi!

Ich hatte ein ganz ähnliches Problem: https://forums.gentoo.org/viewtopic-t-373903.html

Bei mir trat der Fehler immer nach dem Neustart auf.

Ursache: Nach einem Update war in der udev.conf nur noch der Pfad zu Verzeichnissen von rules und permissions. Die Namen der Dateien musste ich von Hand nachtragen.

Hinweis: Die Datei für die Rules fing mit irgendwas von wegen ._xxx an. Musst mal gucken... Vielleicht hilft dir das weiter.

MfG

Keep

----------

## Chacabaou

Bist du sicher, dass das daran liegen kann?

Dass es bei dir nur nach Neustarts zu Problemen kam, ist ja eine eher klassische Situation für UDEV...bei mir passiert das aber aus völlig unerfindlichen Gründen in unregelmäßigen Abständen mittendrin.

----------

## Silicoid

IMHO würde udev eher ein Charakter Device oder einen Link anlegen, kein normales File.

----------

## Chacabaou

 *Silicoid wrote:*   

> IMHO würde udev eher ein Charakter Device oder einen Link anlegen, kein normales File.

 

Dass /dev/null eine normale Datei wird geschieht ja nicht durch UDEV, sondern (höchstwahrscheinlich) dadurch, dass die Datei zunächst gar nicht vorhanden ist, und dann durch das nächstbeste >/dev/null eben als normale Datei angelegt wird.

(falls du nicht grad was ganz anderes meintest...)

----------

## Chacabaou

Für jeden, den das noch interessiert... mich hat das Problem bis zum heutigen Tag begleitet, und ich hab mich nochmal durchgerungen, das genau zu untersuchen.

Durch Zufall hab ich letztlich entdeckt, dass alles nur einem IMHO reichlich dämlichen Verhalten von app-portage/getdelta lag. Folgende Konfiguration...

```
LOGFILE="/dev/null"

DELETE_LOG="true"
```

...führte zu einer Löschung von /dev/null.

Einerseits hab ich mir das natürlich selbst zuzuschreiben, aber eine Überprüfung seitens getdelta, ob es sich bei $LOGFILE um eine reguläre Datei handelt, halte ich sehr wohl für angemessen.

----------

