Jeśli http_proxy wraca w kolejnym terminalu, ustal, kto go ustawił. Kolejny unset na końcu .bashrc może ukryć wartość dla jednego uruchomienia, podczas gdy źródło pozostaje aktywne gdzie indziej.

  1. Zidentyfikuj nieudane uruchomienie. Czy to interaktywna powłoka logowania, terminal bez logowania, czy zadanie nieinteraktywne? Bash wywołany jako sh również podlega innym regułom.
  2. Prześledź tę ścieżkę startową. Interaktywna powłoka logowania czyta /etc/profile, a następnie pierwszy dostępny plik użytkownika spośród ~/.bash_profile, ~/.bash_login i ~/.profile. Interaktywna powłoka bez logowania czyta zwykle ~/.bashrc. Plik logowania może go jawnie source'ować. W przypadku nieinteraktywnego Basha uwzględnij BASH_ENV, gdzie ma to zastosowanie.
  3. Znajdź przypisanie. Przeszukaj te pliki i pliki, które one source'ują, pod kątem nazwy zmiennej i starej nazwy hosta proxy. Uwzględnij odpowiednie fragmenty /etc/profile.d oraz nazwy wielkimi i małymi literami.
  4. Jeśli start go nie przypisał, prześledź proces nadrzędny. Powłoka dziedziczy środowisko z terminala, sesji logowania, menedżera usług lub narzędzia deweloperskiego. Długo działający proces nadrzędny może zachować starą wartość po edycji pliku powłoki.

W przypadku logowań opartych na PAM sprawdź także /etc/environment. Popraw źródło, które go posiada, i uruchom ponownie dotkniętą ścieżkę startową, odświeżając w razie potrzeby konfigurację procesu nadrzędnego. Utrzymuj wyszukiwania lokalnie: pliki startowe i zrzuty środowiska mogą zawierać dane uwierzytelniające. Wynikiem do weryfikacji jest wartość dziedziczona przez docelowe polecenie, a nie ostatni plik, któremu udało się ją unsetować.

Powiązane artykuły