Sto avendo strani effetti collaterali sul cambio LD_LIBRARY_PATH
.LD_LIBRARY_PATH effetti collaterali
Quando accludo un percorso contenente una libreria, ad es. :
LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/my_path/lib
Quindi, tutto diventa incredibilmente lento. Ad esempio, un semplice ls
può essere lungo 10 secondi.
ldd
uscita è esattamente lo stesso prima e dopo la modifica LD_LIBRARY_PATH
e ho cercato di eseguire il debug l'esecuzione del lento ls
con strace
: ottengo la stessa identica esecuzione in entrambi i casi. L'esecuzione non si blocca nemmeno durante l'esecuzione di ls
(poiché strace
non emette alcunché durante il ritardo di 10 secondi e quindi esegue improvvisamente perfettamente ls
). Così ho pensato che potesse provenire dalla mia shell, ma questo è lo stesso, eseguendo strace
sulla mia bash e eseguendo ls
in entrambi i casi mi dà lo stesso output strace
: la shell esegue ls
e aspetta la fine della sua esecuzione (l'ultimo strace
uscita prima del ritardo strace
è waitpid(...)
). Quindi immagino che qualcosa di sbagliato accada tra il lancio di ls
e la sua esecuzione, come se si trattasse di un problema a livello di kernel. Funziona davvero come se uno sleep
sia stato creato su ls
(0 utilizzo della CPU).
Durante il ritardo, la mia CPU e attività di rete sono perfettamente normale ...
Si noti che la biblioteca nel nuovo percorso LD non sia in conflitto con qualsiasi "libreria standard", in modo da non disturbare ls
nella mia esempio.
Quindi sono interessante nelle spiegazioni più dettagliate sugli effetti collaterali LD_LIBRARY_PATH
o su come eseguire il debug approfondito del mio esempio.
Buona domanda. Ho usato 'LD_LIBRARY_PATH' e non ho mai visto un simile comportamento, tuttavia la tua osservazione sembra sia isolata che chiara. Interessante. – thb
'export LD_DEBUG = all' e' man 8 ld.so' –
è ovvio ma "ldd $ (which ls)" può dare un indizio se ls usa qualcosa da LD_LIBRARY_PATH. – Matthias