Stworzyłem skrypt w /etc/init.d/, który musi uruchamiać kilka innych skryptów od innych (nieuprzywilejowanych) użytkowników z ich katalogów domowych, tak jakby je uruchomili.
Uruchamiam te skrypty za pomocą: sudo -b -u <username> <script_of_a_particular_user>
I to działa. Ale dla każdego skryptu użytkownika, który kontynuuje działanie (na przykład jakiegoś watchdoga), widzę odpowiedni nadrzędny proces sudo, wciąż żywy i działający jako root. To tworzy bałagan na liście aktywnych procesów.
Moje pytanie brzmi: w jaki sposób mogę uruchomić (rozwidlić) inny skrypt z istniejącego skryptu bash jako inny użytkownik i pozostawić go jako osierocony (samodzielny) proces?
Bardziej szczegółowe wyjaśnienie: w
zasadzie staram się zapewnić innym użytkownikom komputera sposób uruchamiania rzeczy po uruchomieniu systemu lub zamknięciu systemu, uruchamiając pliki wykonywalne znajdujące się w odpowiednich podkatalogach znajdujących się w ich katalogu domowym, o nazwach .startUp i .shutDown. Ponieważ nie znalazłem żadnego innego sposobu, aby to zrobić, napisałem skrypt bash, który to robi i skonfigurowałem go jako skrypt usługi (na podstawie szkieletu) w /etc/init.d/, więc kiedy jest uruchomiony z argumentem start uruchamia wszystko z katalogów .startUp, a gdy jest uruchamiany z argumentem stop, uruchamia wszystko z katalogów .shutDown wszystkich użytkowników.
Alternatywnie jestem również zainteresowany, czy mógłbym użyć jakiegoś istniejącego rozwiązania do rozwiązania tego problemu.
AKTUALIZACJA
Rozejrzałem się trochę i znalazłem to pytanie:
/unix/22478/detach-a-daemon-using-sudo
Zaakceptowano odpowiedź, aby użyć: sudo -u user sh -c "daemon & disown %1"
działa dla mnie. Ale próbowałem też bez odrzucenia% 1 i jest tak samo. Więc to działa dla mnie tak, jak się spodziewałem:
sudo -u <username> bash -c "<script_of_a_particular_user> &"
Moje dodatkowe pytanie brzmi: dlaczego to działa bez sprzeciwu? czy mimo wszystko powinienem zrezygnować z odrzuconego połączenia z powodu jakiegoś potencjalnego szczególnego przypadku?
AKTUALIZACJA 2
Najwyraźniej to też działa:
su <username> -c "<script_of_a_particular_user> &"
Czy jest jakaś różnica między tym połączeniem a połączeniem sudo? Wiem, że to potencjalnie zupełnie inne pytanie. Ale ponieważ sam znajduję tutaj odpowiedzi, może ze względu na ten temat ktoś mógłby to tutaj wyjaśnić.
AKTUALIZACJA 3
Obie te metody za pomocą su lub sudo wytwarzają teraz nowy proces startpar (pojedynczy proces działający jako root) po uruchomieniu komputera. Widoczny na liście procesów jako:
startpar -f -- <name_of_my_init.d_script>
Dlaczego ten proces się pojawia? Oczywiście robię coś złego, ponieważ żaden inny skrypt init.d nie uruchamia tego procesu.
AKTUALIZACJA 4
Problem ze startpar został rozwiązany. Zacząłem od tego inne pytanie:
proces startpar pozostawał zawieszony podczas uruchamiania procesów z rc.local lub init.d
I kolejne pytanie do dalszego omówienia mechanizmów uruchamiania dla nieuprzywilejowanych użytkowników:
Zapewnienie normalnym użytkownikom (innym niż root) możliwości inicjalizacji i automatycznego uruchamiania