sudo gsettings може змінити проксі GNOME не того користувача
Застосовуйте налаштування проксі GNOME у сеансі робочого столу потрібного користувача замість оновлення бази налаштувань root.
Для власного робочого столу GNOME запускайте зміну налаштування від імені його користувача з цього сеансу робочого столу:
gsettings get org.gnome.system.proxy mode
gsettings set org.gnome.system.proxy mode 'manual'Це ілюструє контекст, а не повне налаштування проксі; значення кінцевої точки й обходу теж мають бути правильними. Для ручного маршруту SOCKS задайте вузол і порт разом із режимом. Прочитайте значення назад у тому самому потрібному сеансі.
Запуск команди через sudo не вибирає налаштування цього користувача. GSettings працює через контекст бекенду. З dconf важливі користувацька база даних і шина сеансу; посібник командного рядка вимагає з'єднання з шиною сеансу D-Bus для записів у цей бекенд.
Для адміністративної зміни використовуйте підтримуваний механізм керування робочим столом або сеансом користувача. Перемикання UID в іншій оболонці все ще може не мати потрібного середовища налаштувань, а копіювання змінних із довільного відповідного процесу може націлитися на інший вхід на машині з кількома сеансами.
Якщо зворотне читання правильне, але маршрутизація не змінилася, визначте споживчий інтерфейс застосунку. Живий слухач GSettings може отримувати сповіщення. Застосунок, який скопіював http_proxy під час запуску, не отримує нового середовища, коли dconf змінюється, і його приватна політика проксі може вибрати інший маршрут. Повторення запису від root не усуває цю невідповідність споживача.