Systemd Servis Oluşturma

En basit haliyle bir komut dosyasının olduğunu varsayın. Bu komut dosyalarının systemd tarafından kontrol edilmesini bize çok büyük avantajlar sağlar. Bazı durumlarda, herhangi bir nedenle kill olduğunda komut dosyalarının kendi kendine yeniden başlatılmasını istersiniz. Bu gibi durumlarda Linux'ta systemd, yönetilebilecek hizmetleri yapılandırmaya yardımcı olur. 

İlk olarak, cd /etc/systemd/system dizini altında .service uzantılı bir dosya oluşturup açınız. Konfigürasyon dosyamı editör ile simple.service isminde oluşturup açıyorum.

nano /etc/systemd/system/simple.service

[Unit]
Description=Api health checker
After=network.target

[Service]
User=demiremrece
Environment=localhost
WorkingDirectory=/home/is-api-up
ExecStart=/usr/bin/node index.js
Restart=on-failure
[Install]
WantedBy=multi-user.target

Şimdi ise konfig dosyasındaki parametrelerin ne anlama geldiğine ve diğer ekleyebileceğimiz parametrelere göz atalım.

After= Bu parametre servisin hangi diğer servisten sonra başlatılmak istendiğini belirtmek için kullanılır.

User= Sistemdeki kullanıcı adınız.

Environment= Çalışma ortamı.

WorkingDirectory= Projemizin bulunduğu directory

ExecStart= Projeyi çalıştırmak için komut. Node.js ile yazıldığından ana scripti(index.js) node ile çalıştırıyoruz.

Restart= Systemd varsayılan olarak servisimizi bir hata durumunda yeniden başlatmaz. Biz servisin her zaman erişilebilir olmasını istediğimizden dolayı burayı always yapabiliriz. on-failure sadece hata durumunda yeniden başlatır. Ama sistem "exit status code:0" ile de sonlanabilir. Bu success kodudur. Detaylı bilgi için: systemd status kodları

Yeni hizmeti dahil etmek için hizmet dosyalarını yeniden yükleyin.

sudo systemctl daemon-reload

hizmetini başlat

sudo systemctl start your-service.service

Hizmetinizin durumunu kontrol etmek için

sudo systemctl status example.service

Hizmetinizi her yeniden başlatmada etkinleştirmek için

sudo systemctl enable example.service

Her yeniden başlatmada hizmetinizi devre dışı bırakmak için

sudo systemctl disable example.service

systemd ile birim dosyaları doğru tasarlanarak bağımlılıklar çözülebilir. En tipik durum, A ünitesinin , A başlatılmadan önce B ünitesinin çalışmasını gerektirmesidir . Bu durumda A bölümüne ve ekleyin . Bağımlılık isteğe bağlıysa, yerine ve ekleyin . Şunu unutmayın ve ima etmeyin , yani belirtilmezse iki ünite paralel olarak başlatılacaktır. Bağımlılıklar genellikle #Targets yerine hizmetlere yerleştirilir . Örneğin, ağ arayüzlerinizi yapılandıran herhangi bir hizmet tarafından çekilir, bu nedenle , zaten başlatıldığından network.target bu yana yeterli olduktan sonra özel biriminizi sipariş edin. 

Özel bir hizmet dosyası yazarken göz önünde bulundurulması gereken birkaç farklı başlangıç ​​türü vardır. Bu, bölümdeki Type= parametre ile ayarlanır 

[Service]

Type=simple(varsayılan): systemd , hizmetin hemen başlatılacağını düşünür. İşlem çatallanmamalıdır. Soket etkinleştirilmedikçe, bu hizmette başka hizmetler sipariş edilmesi gerekiyorsa bu türü kullanmayın.

Type=forking: systemd , işlem çatallandığında ve üst öğe çıktıktan sonra hizmetin başladığını kabul eder. Klasik cinler için, gerekli olmadığını bilmiyorsanız bu türü kullanın. Systemd'nin ana süreci takip edebilmesi için PIDFile=de belirtmelisiniz.

Type=oneshot: Bu, tek bir iş yapan ve ardından çıkan komut dosyaları için kullanışlıdır. RemainAfterExit=yesAyrıca, sistemd'nin işlem sona erdikten sonra hizmeti hala etkin olarak kabul etmesi için ayarlamak isteyebilirsiniz .

Type=notify: Type=simple ile aynıdır , ancak arka plan programının hazır olduğunda systemd'yebir sinyal göndermesi şartıyla . Bu bildirim için başvuru uygulaması libsystemd-daemon.so tarafından sağlanır .

Type=dbusBusName: Belirtilen DBus'un sistem veri yolunda göründüğünde hizmet hazır kabul edilir .

Type=idle: systemd , tüm işler gönderilene kadar hizmet ikili dosyasının yürütülmesini geciktirir. Bunun dışında Type=simple. davranışa çok benzer.