# Zeitverzögerung vorm Emergen

## shiosai

Hallo,

ich habe seit ein paar Wochen ein komisches problem auf einem System. Möchte ich irgendwas emergen, dann kommt es jedes mal bei:

```
>>> Emerging (x of y) irgendwo/irgendwas to /
```

zu einer längeren Verzögerung von ca 30s. Unhabhängig von der Compilier- oder "fetch"Zeit. Das ist vor allem sehr nervig, wenn man viele kleine Packete mal schnell emergen will, weil es halt jedes mal so lange dauert. Hat jemand eine Ahung, wieso das so lange dauert bzw. was emerge zu diesem Zeitpunkt macht/machen will?

Danke

----------

## shiosai

Da der Fehler sich noch nicht verflüchtigt hat, würde ich gerne wissen, welche Möglichkeiten man hat um Portage oder Teile davon neu aufzusetzten/ zu reparieren (abgesehen von neuem Re-Emergen und emerge --sync), danke

----------

## Mr. Anderson

Ist Portage nicht in Python geschrieben? War da nicht was, wenn man dein Python-Update macht, dass man danach (mit root-Rechten) python-updater ausführen soll? Mal probiert?

----------

## shiosai

ich habe jetzt eine lösung wie die verzörgerung bei allen portage operationen verschwinden:

```

/etc/init.d/nfsd start

/etc/init.d/nfsd stop

```

total bescheuert... hilft aber   :Rolling Eyes: 

----------

## furanku

 *shiosai wrote:*   

> ich habe jetzt eine lösung wie die verzörgerung bei allen portage operationen verschwinden:
> 
> ```
> 
> /etc/init.d/nfsd start
> ...

 

Das kann aber allenfalls bei den Symptomen helfen, aber das Problem nicht beseitigen.

Wie bist Du den darauf gekommen NFS zu starten und wieder zu stoppen? Das ist ja nicht unbedingt naheliegend und irgendeine Vermutung wirst Du ja schon gehabt haben, das mal auszuprobieren.

Ich vermute, daß Du ein Verzeichnis per NFS im- oder exportierst. NFS kann gerne mal Time Outs verursachen wenn entweder der Server oder der Client nicht richtig konfiguriert ist, oder dazwischen irgendwas schief läuft. Aber da NFS ja nicht läuft und Du es nur einmal startest und wieder beendest damit es funktioniert muß NFS irgendeinen Seiteneffekt auslösen, der das Problem beseitigt. NFS setzt eine funktionierende Netzwerkumgebung voraus, und ich vermute daß da der eigentliche Fehler bei Deiner Konfiguration liegt.

Ist evtl. IPv6 im Kernel aktiviert obwohl Du es nicht brauchst? Ist 127.0.0.1 als localhost und mit Sitename in der /etc/hosts eingetragen? Was sagt denn dein syslog in den Pausen? Ist eventuell doch irgend ein per NFS gemountetes oder sonstwie nicht lokales Verzeichnis im portage Baum? Vergleiche doch mal die Ausgaben der Neztwerk Konfigurations Tools wie route, ifconfig, ... vor und nach dem Aufruf von NFS, ob der NFS start dort Parameter korrigiert.

----------

## SvenFischer

rc-update add net.lo boot

----------

## shiosai

 *furanku wrote:*   

> 
> 
> Wie bist Du den darauf gekommen NFS zu starten und wieder zu stoppen? Das ist ja nicht unbedingt naheliegend und irgendeine Vermutung wirst Du ja schon gehabt haben, das mal auszuprobieren.
> 
> [...]
> ...

 

Im Log stand beim Emerge immer so etwas:

```

statd: server localhost not responding, timed out

lockd: cannot monitor 192.168.2.1

lockd: failed to monitor 192.168.2.1

```

wobei 2.1 ein Server im Netzwerk ist. Dementsprechend habe ich in die localhost datei geschaut, in der unter anderem "::1    localhost" was ich entfern habe, der korrekte 127.0.0.1 war aber auch vorhanden. Nachdem das nichts geändert hat, habe ich mal mit nfsd rumgespielt (weil das irgendwie mit lockd/statd zusammenhängen soll) und es hat geholfen. Verzeichnisse werden aber nicht freigegeben (export ist leer), nur vom server gemountet, was immer funktioniert hat. Das freigeben von Verzeichnissen habe ich aber mal vor ein paar Monaten erfolglos versucht, vieleicht habe ich da irgendwas kaputt gemacht oder es war auch schon damals kaputt...

IPV6 ist deaktiviert und net.lo schon in boot.

----------

