Şu anda sistemin başlatılması / başlatılması sırasında bir komut dosyası çalıştırmak için init.dve cron arasındaki farkı anlamaya çalışıyorum @reboot.

Kullanımı @reboot(bu yöntem sözü edilen bu forumda tarafından hs.chandra ) basitçe girerek, bazı ne basittir crontab -eve bir yaratma @reboot /some_directory/to_your/script/your_script.txtve daha sonra your_script.txtsistem yeniden başlatılması her zaman yürütür. Bir derinlemesine açıklama @rebootolduğunu burada

Alternatif olarak, betiğinizin ikinci satırına/etc/init.d/your_script.txt ekleyerek yani:

#!/bin/bash
# /etc/init.d/your_script.txt

Çalıştırılabilir chmod +x /etc/init.d/your_script.txtve bu your_script.txt, sistemin her açılışında çalıştırılmasıyla sonuçlanmalıdır .

S1: İkisi arasındaki anahtar farklar nelerdir?
S2: Hangisi daha sağlam?
S3: İkisinden daha iyi bir tane var mı?
S4: Önyükleme sırasında çalıştırılacak bir komut dosyasını gömmenin doğru yolu bu mu?

Başlangıç ​​sırasında çalıştırılacak bir bash .sh dosyası ekleyeceğim.

init.dSysV betiği olarak da bilinir, sistemin başlatılması ve kapatılması sırasında hizmetleri başlatmak ve durdurmak içindir. ( /etc/init.d/komut dosyaları da uyumluluk için sistem ve etkin sistemlerde çalıştırılır).

• Komut önyükleme ve kapatma sırasında yürütülür (varsayılan olarak).
• Komut dosyası bir komut dosyası değil, bir init.d komut dosyası olmalıdır. Desteklemeli startve stopdaha fazlası (bakınız Debian politikası )
• Komut dosyası , sistem önyüklemesi sırasında yürütülebilir (ne zaman tanımlayabilirsiniz).

crontab(ve bu nedenle @reboot).

• cron burada herhangi bir özel komut veya komut dosyası çalıştıracaktır.
• Herhangi bir kullanıcı bir @rebootkomut dosyası ekleyebilir (sadece root değil)
• systemd olan bir Debian sisteminde: cron's @reboot işlemi sırasında çalıştırılır multi-user.target.
• cystab (5), SysV'li (sistemd olmayan) bir Debian sisteminden bahseder: Lütfen, @reboot ile ilgili olarak başlatmanın cron (8) arka plan programı başlangıcının zamanı olduğunu unutmayın. Özellikle, bazı sistem artalanlarının veya diğer tesislerin devreye girmesinden önce olabilir. Bu, makinenin önyükleme sırası dizisinden kaynaklanmaktadır.
• Aynı betiği açılışta ve periyodik olarak programlamak kolaydır.

/etc/rc.localçoğu zaman çirkin veya kullanımdan kaldırılmış olarak kabul edilir (en azından redhat tarafından ), yine de bazı güzel özelliklere sahipti:

• rc.local burada herhangi bir özel komut veya komut dosyası çalıştıracaktır.
• SysV ile Debian sisteminde (sistemd değil): rc.localbaşlamak için en son hizmet (neredeyse) idi.
• ancak systemd'li bir Debian sisteminde: varsayılan rc.localolarak çalıştırılır network.target(değil network-online.target!)

Systemd en İlişkin network.targetve network-online.targetokumak Ağ yukarı sonra Running Hizmetleri .

İlk olarak, bir açıklama sırasıdır:

• init.d dizinidir depolar hizmetleri kontrol eden komut dosyaları, kontrol ettikleri başlayan ve bu gibi hizmetlerin durdurulması httpdveyacron
• rc.local , sistem başlatma işleminin bir parçası olarak rastgele komut dosyalarının çalıştırılmasına izin veren bir hizmettir

Komut dosyanızı kullanmanın rc.localveya cronçalıştırmanın daha iyi olup olmadığı konusunda , pratikten çok estetik meselesi olduğundan şüpheleniyorum. cronBir görev zamanlayıcı olarak, güncellemeleri kontrol etmek, önbellekleri temizlemek veya güvenlik denetimleri yapmak gibi bir makineye bakım yapmak veya bakım yapmak için bir yöntem olarak tasarlanmıştır. Bu, belirtilen zamanda istenen herhangi bir komut dosyasını veya komutu çalıştırabileceği için bu işlevleri yerine getirmeyle sınırlı olduğu anlamına gelmez @reboot.

Kullanılması rc.localolarak, görevin bir sistem konfigürasyonu türü içinde daha düşecek, diğer taraftan, olur rc.localmakineler tarafından yürütülmektedir, sistemi başlatmaya tipik makineleri ağ yapılandırmasını ayarlamak sorumludur, hizmetler veya ortamlar (ama yine sadece bunlarla sınırlı değildir bu görev).

Bununla birlikte, bu noktaların her ikisi de, tüm init sistemlerinin bir rc.localmekanizma sunmadığı ve tüm cron daemonlarının bir @rebootpsuedo etiketi sunmadığı gerçeğiyle temellendirilmelidir.

Bonus puanlar

Belirtildiği gibi, init.dsisteminizde başlatılabilen veya durdurulabilen hizmetleri kontrol eden komut dosyalarını içeren dizin (en azından bir SysVinit sistemi kullanan makinelerde ). Init sisteminize ve komut dosyanızın amacına bağlı olarak, komut dosyanızı bir hizmetle aynı şekilde çalıştırılmak üzere bir init komut dosyasına dönüştürmeniz makul olabilir . Bununla birlikte, bu, bu dosyaların nasıl oluşturulduğunu çevreleyen çerçeve büyük ölçüde farklılık gösterebileceğinden, büyük ölçüde init sisteminize bağlıdır.

Son söz

Ayrıca, tipik olarak bash betiğinin , bunun hemen bir metin dosyası yerine bir kabuk betiği olduğu anlamına geldiğinden .shziyade bir sonek ile bittiğine dikkat edilmelidir .txt. Dosyanın üstünde bir shebang ( #!/bin/bash) bulunması veya bash /path/to/script.whateverbetiğin çalıştırılması açısından bir önemi olmaması gerektiği söyleniyor .

Cevabımı aşağıya yazıyorum;

S1: İkisi arasındaki anahtar farklar nelerdir?

Yukarıdaki diğer kullanıcılar tarafından belirtilen farklılıkların yanı sıra, @reboot öğesinin crond daemon'a bağlı olduğunu vurgulamak isterim. Crond'un başladığı sıraya bağlısınız. Her ne kadar çoğu durumda, crond iyi başlıyor, ancak başlaması bazen başarısız olabilir (en azından bazı projelerimde bazı başarısızlıklar gördüm). Bir init betiği yazdığınızda, betiğinizde yanlış bir şey yaparsanız, genellikle hata oluşur (örneğin: hizmetinizden sonra başlayacak olan bir hizmete güvenerek)

S2: Hangisi daha sağlam?

Yukarıdakilere göre, init'in daha sağlam olduğunu düşünüyorum. Ancak ilk cevapta "Franklin Piat" tarafından bahsedildiği gibi başka bir nokta var. Genellikle bir daemon için init betiğine ihtiyacınız vardır ve politikayı izlemelisiniz

S3: İkisinden daha iyi bir tane var mı?

Öyle sanmıyorum (rc.local biraz eski ve kullanımdan kaldırıldı)

S4: Önyükleme sırasında çalıştırılacak bir komut dosyasını gömmenin doğru yolu bu mu?

Evet. Genellikle uygulama / paket yazarları bu şekilde yapar.