Mam dziwne efekty uboczne na zmianę LD_LIBRARY_PATH
.Efekty uboczne LD_LIBRARY_PATH
Kiedy dołączam ścieżkę zawierającą bibliotekę, np. :
LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/my_path/lib
Wtedy wszystko staje się niewiarygodnie powolne. Na przykład prosty ls
może mieć 10 sekund.
ldd
wyjście jest dokładnie taka sama przed i po zmianie LD_LIBRARY_PATH
i starałem się debugowania wykonanie powolnego ls
z strace
: Mam dokładnie to samo wykonanie w obu przypadkach. Wykonanie nawet nie utknie podczas wykonywania ls
(ponieważ strace
nic nie wyprowadza podczas 10-sekundowego opóźnienia, a następnie nagle wykonuje się doskonale ls
). Tak myślałem, że to przyjdzie z mojego powłoki, ale jest to ten sam, bieganie strace
na moim bash i wykonywania ls
w obu przypadkach daje mi ten sam strace
wyjście: powłoka wykonuje ls
i czekać na koniec jego realizacji (ostatni strace
wyjście przed opóźnieniem strace
jest waitpid(...)
). Sądzę, że dzieje się coś złego pomiędzy uruchomieniem ls
a jego wykonaniem, tak jakby był to problem na poziomie jądra. To naprawdę działa tak, jakby sleep
został wykonany na ls
(użycie 0 cpu).
czasie opóźnienia, mój CPU i aktywność sieci są całkowicie normalne ...
Zauważ, że biblioteka w nowej ścieżce LD nie jest sprzeczne z jakimkolwiek „standardowej biblioteki”, więc nie przeszkadza w moim ls
przykład.
Więc jestem interesujący w głębszych wyjaśnieniach dotyczących efektów ubocznych LD_LIBRARY_PATH
lub jak głęboko debugować mój przykład.
Dobre pytanie. Użyłem 'LD_LIBRARY_PATH' i nigdy nie widziałem takiego zachowania, ale twoja obserwacja wydaje się być zarówno odizolowana, jak i jasna. Ciekawy. – thb
'export LD_DEBUG = all' i' man 8 ld.so' –
prawdopodobnie oczywiste, ale "ldd $ (który ls)" może dać wskazówkę, jeśli ls używa czegoś z LD_LIBRARY_PATH. – Matthias