Jaka jest różnica między /etc/rc.local i /etc/init.d/rc.local?


30

Chcę dodać stałą iptablesregułę do mojej nowej VPS, a po krótkim wyszukiwaniu w Google zdziwiłem się, że istnieją dwa miejsca, w których można dodać tę regułę, które wydają się identyczne: /etc/rc.locali /etc/init.d/rc.local. Może ktoś wie, dlaczego są dwa miejsca na prosty kod startowy? Czy jest specyficzny dla Linuksa (ale Ubuntu ma oba!)? Czy jeden z nich jest przestarzały?


1
Jedno powinno być dowiązaniem symbolicznym do drugiego.
Ignacio Vazquez-Abrams,

2
@ IgnacioVazquez-Abrams Na Ubuntu Server 12.04 x86 LTS są zupełnie inne :(.
grigoryvp

1
@ IgnacioVazquez-Abrams: W Debianie również wydają się być inni.
Emanuel Berg

3
Warto sprawdzić: zadałem pytanie o /etc/rc.localjakiś czas temu.
Emanuel Berg

Odpowiedzi:


31

/etc/init.djest utrzymywany na Ubuntu dla wstecznej kompatybilności z sysvinit. Jeśli naprawdę na /etc/init.d/rc.localto spojrzysz , zobaczysz (także z serwera LTS 12.04):

#! /bin/sh
### BEGIN INIT INFORMATION
# Provides:          rc.local
# Required-Start:    $remote_fs $syslog $all
# Required-Stop:
# Default-Start:     2 3 4 5
# Default-Stop:
# Short-Description: Run /etc/rc.local if it exist
### END INIT INFO

A „Run /etc/rc.local” jest dokładnie tym, co robi. Całość /etc/rc.localto:

#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.

exit 0

Sądzę, że celem tego jest zapewnienie prostego miejsca do umieszczania poleceń powłoki, które chcesz uruchamiać podczas rozruchu, bez konieczności zajmowania się usługami stop | start, które są dostępne /etc/init.d/rc.local.

Jest to więc usługa i może być uruchomiona jako taka. Dodałem echowiersz /etc/rc.locali:

»service rc.local start
hello world

Jednak nie sądzę, aby coś o tym wspominało w /etc/initkatalogu upstart (nie init.d!):

»initctl start rc.local
initctl: Unknown job: rc.local

W fazie upstart jest kilka usług „rc”:

»initctl list | grep rc
rc stop/waiting
rcS stop/waiting
rc-sysinit stop/waiting

Ale żaden z nich nie wydaje się mieć nic wspólnego z rc.local.


5

Jest to bardziej charakterystyczne dla dystrybucji. (na przykład nie znajdziesz innego rc.local w CentOS).

Teraz, gdy nadchodzi twoje aktualne pytanie, myślę, że dodanie czegokolwiek w /etc/init.d/rc.local sprawia, że ​​zaczyna się ono jako „usługa”, podczas gdy wszystko w /etc/rc.local po prostu uruchamiałoby ten skrypt podczas uruchamiania.

Nie jestem do końca pewien, dlaczego Ubuntu nadal je utrzymuje? (Być może ktoś inny może rzucić nieco światła na tę część !!)


Jaka jest różnica między poleceniem wykonywanym „jako usługa” a kodem, który „uruchamia się po prostu podczas uruchamiania”? Czy to jakieś bezpieczeństwo czy co?
grigoryvp

Podstawowa różnica między nimi polega zasadniczo na usłudze i procesie. ;) Myślę, że podstawową intencją byłoby tylko bezpieczeństwo. Ten link może Cię zainteresować: unixmen.com/managing-your-services-and-processes-in-linux
pragmatyczny

To jest niepoprawne! Nie są to te same skrypty, ale jedną usługą - /etc/init.d/rc.localczy przestaje uruchamiać rzeczy /etc/rc.local(więcej szczegółów w mojej odpowiedzi).
goldilocks,

@Goldilocks: Dziękuję za bardzo opisową i dokładną odpowiedź, ale nie jestem pewien, która część mojej odpowiedzi, o której wspominałeś, jest nieprawidłowa? Powiedzenie jednego jako usługi oznacza, że ​​może wykonywać czynności „start” i „stop”, a drugie jako zwykły proces. Proszę mnie poprawić, jeśli nie mam tutaj sensu.
pragmatyczny

2
@pragmatic Ponieważ /etc/rc.localskrypt jest procesem wykonywalnym zarządzanym przez /etc/initd/rc.localskrypt, podobnie jak (np.) /bin/syslogbyłby to proces wykonywalny zarządzany przez /etc/initd/syslog. Mówisz wprost, że /etc/rc.localjest to tylko skrypt rozruchowy, a /etc/initd/rc.localnie jest całkowicie oddzielną usługą na poziomie uruchamiania.
goldilocks,
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.