2015-12-08 38 views
13

Mam usługę, którą chcę rozpocząć od uruchomienia systemu. Zbudowałem definicję ap @ .service jako szablon, ponieważ może istnieć wiele instancji.Czy mogę kontrolować systemd użytkownika przy użyciu "systemctl --user" po sudo su - myuser?

Zdefiniowane w systemie głównym d, działa to dobrze, a także uruchamia i zatrzymuje usługę w systemie. Instancja usługi jest instalowana z systemctl enable [email protected] zgodnie z oczekiwaniami. Root może również bez problemów uruchomić i zatrzymać usługę. Usługa działa na swoim koncie (myuser), a nie root, kontrolowana przez User = myuser w szablonie ap @ .service.

Ale chcę, aby użytkownik "myuser" mógł uruchamiać i zatrzymywać własną usługę, bez naruszania bezpieczeństwa systemu.

Przełączyłem się na używanie systemd użytkownika i włączone podtrzymywanie z loginctl enable-linger myuser. Następnie włączam usługę zdefiniowaną w katalogu ~ myuser/.config/systemd/user. Usługa jest teraz uruchamiana i zatrzymuje się zgodnie z projektem zgodnie z projektem. Jeśli loguję się do terminala jako "myuser", systemctl --user start [email protected] i systemctl --user stop [email protected] oba działają doskonale.

Jeśli jednak loguję się jako inny użytkownik (użytkownik2) i wykonuję sudo su - myuser w terminalu, to komendy systemctl --user kończą się niepowodzeniem z komunikatem o błędzie "Nie można uzyskać połączenia D-Bus: brak takiego pliku lub katalogu".

Jak włączyć systemctl --user do pracy po komendzie sudo su - myuser, aby zmienić użytkownika?

+0

Czy Twój CWD jest nadal katalogiem osobistym innego użytkownika? Niektóre narzędzia mają problemy, jeśli użytkownik wywołujący nie ma uprawnień do wyświetlania bieżącego katalogu. – Dave

+0

Cześć Dave ... katalog domowy został przełączony, wymuszony przez - w poleceniu sudo. CWD zostało zmienione na katalog domowy nowego użytkownika. – NeilCasey

+0

Ah OK. Zignoruj ​​mnie wtedy. – Dave

Odpowiedz

13

Znalazłem odpowiedź na innej stronie z dalszymi wyszukiwaniami, używając różnych terminów.

Potrzebne rozwiązania polegały na dostarczeniu powłoce informacji potrzebnych do uzyskania prawidłowego DBUSa dla użytkownika.

Dodanie następujących zmiennych środowiskowych do powłoki przed uruchomieniem systemctl --user, problem DBUS jest wyeliminowany, a systemctl działa poprawnie.

export XDG_RUNTIME_DIR="/run/user/$UID" 
export DBUS_SESSION_BUS_ADDRESS="unix:path=${XDG_RUNTIME_DIR}/bus" 

Aby zapewnić DBUS_SESSION_BUS_ADDRESS jest dostępny w powłoce sudo dodawaniu zmienne środowiska do ~/bash_profile z identyfikatorem użytkownika docelowego. Wymaga to utworzenia powłoki logowania (sudo su - myuser lub sudo -l myuser) w celu utworzenia poprawnego środowiska.

Alternatywnie dodaj tworzenie zmiennych środowiskowych do ~/.bashrc (lub odpowiednika dla innych powłok). Środowisko zostanie utworzone na nowo dla wszystkich kreacji powłoki.