2016 Güncellemesi
Buradaki çoğu cevap beş yaşında, bu yüzden bazı güncellemelerin zamanı geldi.
Ubuntu başlangıçta varsayılan olarak kullanıyordu, ancak geçen yıl systemd lehine terk ettiler - bkz:
Bu nedenle Ubuntu wiki'de Upstart Users için güzel bir Systemd makalesi var - upstart ve systemd ile upstart'tan systemd'e geçiş rehberi arasında çok detaylı bir karşılaştırma yapıldı.
( Ubuntu wiki'sine göre, Ubuntu'nun geçerli sürümlerinde varsayılan olarak hala yükleyerek upstart-sysvve çalıştırarak çalıştırabilirsiniz, sudo update-initramfs -uancak systemd projesinin kapsamını göz önünde bulundurarak pratikte nasıl çalıştığını veya systemd olup olmadığını bilmiyorum. kaldırmak mümkün.)
Aşağıdaki Komutlar ve Komut Dosyaları bölümlerindeki bilgilerin çoğu, bu makalede kullanılan bazı örneklerden uyarlanmıştır (bu, yalnızca Creative Commons Attribution-ShareAlike 3.0 Lisansı altındaki Stack Exchange kullanıcı katkıları gibi uygun şekilde lisanslanmıştır ).
Yaygın komutların ve basit komut dosyalarının hızlıca karşılaştırılması, ayrıntılı açıklama için aşağıdaki bölümlere bakın. Bu cevap, Upstart tabanlı sistemlerin eski davranışlarını, soruda belirtildiği gibi, systemd tabanlı sistemlerin yeni davranışlarıyla karşılaştırıyor, ancak "Upstart" olarak etiketlenen komutların mutlaka Upstart'a özgü olmadığını unutmayın - genellikle komutlardır. her sistem dışı Linux ve Unix sistemi için ortaktır.
Komutları
Su çalışan:
- sonradan görme:
su
- systemd:
machinectl shell
(aşağıdaki "su komutu değiştirme" bölümüne bakın)
Çalışan ekran:
- sonradan görme:
screen
- systemd:
systemd-run --user --scope screen
(aşağıdaki "Beklenmeyen arka plan işlemlerinin öldürülmesi" bölümüne bakın)
Çalışan tmux:
- sonradan görme:
tmux
- systemd:
systemd-run --user --scope tmux
(aşağıdaki "Beklenmeyen arka plan işlemlerinin öldürülmesi" bölümüne bakın)
İş başında foo:
- sonradan görme:
start foo
- systemd:
systemctl start foo
İş foo'yu durdurmak:
- sonradan görme:
stop foo
- systemd:
systemctl stop foo
İş foo'yu yeniden başlatma:
- sonradan görme:
restart foo
- systemd:
systemctl restart foo
Liste işleri:
- sonradan görme:
initctl list
- systemd:
systemctl status
İş foo yapılandırmasını kontrol etme:
- sonradan görme:
init-checkconf /etc/init/foo.conf
- systemd:
systemd-analyze verify /lib/systemd/system/foo.service
İşin ortam değişkenlerini listeleme:
- sonradan görme:
initctl list-env
- systemd:
systemctl show-environment
İşin ortam değişkenini ayarlama:
- sonradan görme:
initctl set-env foo=bar
- systemd:
systemctl set-environment foo=bar
İşin ortam değişkenini kaldırma:
- sonradan görme:
initctl unset-env foo
- systemd:
systemctl unset-environment foo
Kütükler
Başlangıçta, günlükler / var / log / upstart dizinindeki normal metin dosyalarıdır, böylece onları her zamanki gibi işleyebilirsiniz:
cat /var/log/upstart/foo.log
tail -f /var/log/upstart/foo.log
Sistemd'de günlükler dahili bir ikili formatta (metin dosyaları olarak değil) saklanır, bu nedenle journalctlbunlara erişmek için komut kullanmanız gerekir:
sudo journalctl -u foo
sudo journalctl -u foo -f
Kodlar
Yazılan örnek başlangıç betiği/etc/init/foo.conf :
description "Job that runs the foo daemon"
start on runlevel [2345]
stop on runlevel [016]
env statedir=/var/cache/foo
pre-start exec mkdir -p $statedir
exec /usr/bin/foo-daemon --arg1 "hello world" --statedir $statedir
Örnek systemd senaryo yazılmış /lib/systemd/system/foo.service:
[Unit]
Description=Job that runs the foo daemon
Documentation=man:foo(1)
[Service]
Type=forking
Environment=statedir=/var/cache/foo
ExecStartPre=/usr/bin/mkdir -p ${statedir}
ExecStart=/usr/bin/foo-daemon --arg1 "hello world" --statedir ${statedir}
[Install]
WantedBy=multi-user.target
su komutu değiştirme
su# 1022 çekme isteğinde bir komut değiştirme sistemde birleşti:
Çünkü, Lennart Poettering’e göre “su gerçekten kırılmış bir kavram” .
O açıklıyor "Daha önce olarak su ve sudo kullanabilirsiniz, ancak bunun tam olarak çalışacağını sanmıyoruz " .
Bir subenzeri davranış elde etmenin resmi yolu şudur:
machinectl shell
Bundan başka edilmiş
Lennart Pöttering ile açıklanabilir
# 825 sorunu tartışmada:
“Eh, bu konuda uzun tartışmalar oldu, ama sorun şu ki, su ne yapması gereken çok net değil. […] Uzun lafın kısası: su gerçekten kırılmış bir kavram. , ve bunun için kullanmak iyidir, ancak bu tam bir giriş değildir ve bunun için yanlış olmamalıdır. " - Lennart Poettering
Ayrıca bakınız:
Beklenmedik arka plan işlemlerinin öldürülmesi
Gibi komutlar:
artık beklendiği gibi çalışmıyor . Örneğin, nohupoturumunuzdan çıktıktan sonra işlemin devam etmesini sağlamak için bir POSIX komutudur. Artık systemd üzerinde çalışmıyor . Ayrıca gibi programlar screenve tmuxözel bir şekilde çağrılacak veya başka ihtiyaç onlarla koşmak süreçleri öldürdü alacak (ilk etapta ekranı veya tmux çalışan ana nedeni genellikle ölenlerin süreçleri almıyor iken).
Bu bir hata değil, bilinçli bir karardır, bu nedenle gelecekte düzeltilmesi muhtemel değildir. Lennart Poettering'in bu konuda söylediği şey:
Benim görüşüme göre, UNIX'in varsayılan olarak oturumu kapattıktan sonra keyfi kullanıcı kodunun sınırsız kalmasına izin vermesi oldukça garipti. Günümüzde birçok işletim sistemi çalışanı arasında, bunun mümkün olması, ancak kesinlikle varsayılan olmaması gerektiği tartışılmıştır, ancak şimdiye kadar hiç kimse anahtarı bir varsayılandan bir seçeneğe çevirmek için düğmeyi çevirmeye cesaret edemedi. Oturumu kapattıktan sonra kullanıcı oturumlarını temizlememek sadece çirkin ve biraz da rahatsız edici değil, aynı zamanda bir güvenlik sorunudur. systemd 230 şimdi nihayet anahtarı çevirdi ve nihayet varsayılan olarak kullanıcı oturumu kapattığında her şeyi doğru temizledi.
Daha fazla bilgi için bakınız:
Üst seviye başlangıç konsepti
Bir şekilde systemd geriye doğru çalışır - başlangıçta işler olabildiğince çabuk başlar ve sistemd'de işler gerektiğinde başlar. Günün sonunda aynı işler her iki sistem tarafından ve hemen hemen aynı sırayla başlatılabilir, ancak konuşmak için ters yönden bakmayı düşünürsünüz.
İşte Başlangıcı Kullanıcıları için Systemd şöyle açıklıyor:
Sonradan görme süreçleri (iş) başlama 'ın modeli 'açgözlü olay tabanlı' dir, kimin başlangıç olaylar meydana olabildiğince erken başlatılır yani mevcut tüm işler. Önyükleme sırasında upstart, başlangıç veya rcS gibi bazı başlangıç olaylarını "ağaç kökü" olarak sentezler, erken hizmetler bunlar üzerinde başlar ve daha sonra eski hizmetler çalışır. Yeni bir işin aktif olabilmesi için yapılandırma dosyasını / etc / init / içine yüklemesi yeterlidir.
sistemin başlangıç işlemleri için sistemi (birimler) "tembel bağımlılığa dayalı" dır, yani bir birim ancak başka bir başlangıç biriminin buna bağlı olması durumunda başlayacaktır. Önyükleme sırasında, systemd "root unit" (varsayılan.target, grubun içinde geçersiz kılınabilir) başlatır, bu daha sonra geçişsel olarak genişler ve bağımlılıklarına başlar. Yeni bir ünitenin aktif olabilmesi için kendini önyükleme sırasının bir birimine (genellikle multi-user.target) bağımlı olarak eklemesi gerekir.
Dağıtımlarda kullanım
Şimdi Wikipedia'ya göre bazı yeni veriler:
Varsayılan olarak upstart kullanan dağıtımlar:
Varsayılan olarak systemd kullanan dağılımlar:
( En güncel bilgiler için Wikipedia'ya bakın )
Ne Upstart ne de systemd kullanan dağılımlar:
tartışma
Geçmişte , sistemin önüne geçmek için bir Debian çatalı önerildi . Devuan GNU + Linux yaratıldı - systemd olmadan Debian bir çatal (sayesinde fpmurphy1 yorumlar kısmında işaret için).
Bu tartışma hakkında daha fazla bilgi için, bakınız:
Birçoğunuzun zaten bildiği gibi, Ian Jackson tarafından teşvik edilen Init GR Debian oyları, Debian'ın mirasını ve kullanıcılarını sistemdeki çığdan korumakta yardımcı olmadı.
Bu durum, kalkınma özgürlüğünü fiilen tehdit eden fiili olan ve Debian, yukarı havası ve aşağı havası için ciddi sonuçları olan sistem bağımlılıklarında kilitlenme beklemektedir.
CTTE, bir bağımlılığı değiştirmeyi başardı ve bize svinvinit üzerindeki ince bir sistem kurulumunda bize zaman kazandırdı, ancak bu süreç bile yorucu ve drama dolu idi. Sonuçta, bir hafta önce, Ian Jackson istifa etti. [...]
Derhal yürürlüğe girerek Teknik Komiteden istifa ediyorum.
Benimle aynı fikirde olan projenin% 30-40'ının görüşlerinin TC'de temsil edilmeye devam etmesi önemli olsa da, bu noktada bunu yapmak için kesinlikle tartışmalıyım. Projenin yönetimi hakkındaki konuşmaların ne ölçüde kişiselleştirileceğini azaltmaya çalışmak için kenara çekilmeliyim. [...]
Devuan, Debian için varsayılan init sistemi olarak kullanma kararı konusundaki tartışmalardan doğdu. Sistemdeki resmi Debian pozisyonu, başkalarının borçlarını aldıklarını iddia ediyor . İlgilenen okuyucular, bu tartışmalı konu başlıklarını sistem tartışması bölümünde tartışmaya devam edebilir . Ancak, kafanızı serin ve sesinizi sivil tutmanız için teşvik ediyoruz. Devuan'da geriye dönüp bakmak yerine yanlış programlama yapmakla ilgileniyoruz. [...]
Sistem tartışmasına adanmış bazı web siteleri ve makaleler oluşturuldu:
Orada bir sürü Hacker News ilginç tartışma:
Diğer dağıtımlardaki benzer eğilimler de gözlemlenebilir:
Felsefe
upstart , DOTADIW'ın Unix felsefesini izliyor - "Bir Şey Yap ve İyi Yap." Geleneksel init daemonunun yerine geçmiştir. Hizmetleri başlatmak ve durdurmaktan başka bir şey yapmaz. Diğer görevler diğer uzmanlaşmış alt sistemlere devredilmiştir.
systemd bundan daha fazlasını yapar. Hizmetlerin başlatılması ve durdurulmasının yanı sıra, parolaları, girişleri, terminalleri, güç yönetimini, fabrika sıfırlamalarını, günlük işlemlerini, dosya sistemi bağlama noktalarını, ağları ve daha fazlasını da yönetir - bazı özellikler için NEWS dosyasına bakın .
Genişleme planları
Göre Elde ve What Lies Ahead Has Been Ne systemd için bir Perspektif GNOME.asia de 2014 yılında Lennart Pöttering tarafından sunum, burada systemd ana hedefleri, zaten kapalı ve halen devam edildi olanlar edilen alanlar;
sistem hedefleri:
Hedeflerimiz
- Bir bit torbasından Linux'u rekabetçi bir Genel Amaçlı İşletim Sistemine dönüştürmek.
- İnternetin Yeni Nesil İşletim Sistemini Kurmak Dağıtımlar arasındaki anlamsız farkları birleştirmek
Yeniliğin temel işletim sistemine geri getirilmesi
Masaüstü, Sunucu, Konteyner, Gömülü, Mobil, Bulut, Küme,. . . Bu alanlar birlikte düşündüğünüzden daha yakın
- Yönetici karmaşıklığını azaltmak, gözetim olmadan güvenilirlik
- Her şey içilemez
- Otomatik keşif, tak ve çalıştır özelliği anahtardır
- Kırıldıkları şeyleri düzeltiriz, asla bantlanmadık
Zaten kapsanan alanlar:
Zaten neyi koruduğumuz:
init sistemi, günlük kaydı, giriş yönetimi, cihaz yönetimi, geçici ve geçici dosya yönetimi, ikili format kaydı, arka ışık kaydet / geri yükle, rfkill kaydet / geri yükle, bootchart, yeniden okuma, şifreli depolama ayarları, EFI / GPT bölüm bulma, sanal makine / konteyner kayıt, minimum kap yönetimi, ana bilgisayar adı yönetimi, yerel yönetim, zaman yönetimi, rastgele tohum yönetimi, sysctl değişken yönetimi, konsol yönetimi. . .
Çalışma devam ediyor:
Ne üzerinde çalışıyoruz:
- ağ yönetimi
- systemd-networkd
- Yerel DNS önbelleği, mDNS yanıtlayıcısı, LLMNR yanıtlayıcısı, DNSSEC doğrulaması
- Çekirdekte IPC
- kdbus, sd-bus
- NTP ile zaman senkronizasyonu
- systemd-timesyncd
- Konteynerlerle daha fazla entegrasyon
- Hizmetlerin Sanallaştırılması
- Apps Sandboxing
- Os görüntü formatı
- Konteyner görüntü formatı
- Uygulama görüntü formatı
- Otomatik keşif özellikli GPT
- Vatansız sistemler, anlık sistemler, fabrika ayarlarına sıfırlama
- / usr işletim sistemidir
- / etc (isteğe bağlı) yapılandırma
- / var (isteğe bağlı) durum
- Atomik düğüm başlangıcı ve güncellemeleri
- Bulut ile entegrasyon
- Düğümler arasında servis yönetimi
- Doğrulanabilir işletim sistemi görüntüleri
- Firmware'e kadar
- Önyükleme Yükleniyor
Bu cevabın kapsamı
Fpmurphy1'in yorumlarında belirttiği gibi , " Sistemdinin çalışma alanını yıllar içinde, sistemin başlamasından çok daha fazla genişlettiğine işaret edilmelidir."
İlgili bilgilerin çoğunu buraya eklemeye çalıştım. Burada, Upstart ile systemd'in ortak özelliklerini karşılaştırarak, soruda init sistemler olarak kullanıyorum ve sadece init sistemlerin kapsamının ötesine geçen systemd özelliklerinden bahsettim, çünkü bunlar Startup ile karşılaştırılamaz, ancak bunların varlığı önemlidir. Bu iki proje arasındaki farkı anlamak. Daha fazla bilgi için ilgili dokümantasyon kontrol edilmelidir.
Daha fazla bilgi
Daha fazla bilgi bulunabilir:
Ekstralar
LinOxide Takım bir yarattı SysV Init Linux Pardus vs systemd .