Mulai layanan systemd di dalam chroot

38

Dengan skrip init (atau dengan openrc) saya selalu dapat menjalankan layanan dari root instalasi yang berbeda.
tetapi ketika saya berlari chroot /somepath/to_root /usr/bin/systemctl start someservicesaya mendapat:

Running in chroot, ignoring request.

Apakah ada cara untuk memaksa systemd menjalankan layanan?

Pembaruan:
Saya lupa mengatakan sistem host saya menjalankan skrip init atau openrc, tetapi tidak pernah systemd, dan bahwa saya menggunakan chroot untuk memecahkan masalah sistem Unix yang bahkan tidak dapat meluncurkan shell minimal.

unix systemd chroot pengguna2284570
sumber
1
Saya juga perlu menjalankan layanan ke chroot, selalu berfungsi sebelum openrc2, sepertinya tidak mungkin sekarang; (
neofutur
Anda mencoba menyelesaikan masalah yang salah. Jika Anda memiliki OpenRC, Anda perlu mengubah layanan systemd menjadi layanan OpenRC. Benar-benar tidak ada jalan lain untuk itu.
Daniel B
@DanielB: TIDAK! Apakah Anda pernah mendengar tentang systemrescuecd?
user2284570
Tidak. Saya juga tidak mengerti bagaimana ini berhubungan dengan pertanyaan Anda.
Daniel B

Jawaban:

29

Masalah yang terkenal di distro systemd (Arch Linux, OpenSUSE, Fedora).

Systemd menggantikan sysvinit, dan memberikan satu keuntungan besar atas ini. Di sysvinit, ketika Anda meminta layanan untuk memulai, ia mewarisi konteks eksekusi dari orang yang memanggil skrip, yang meliputi variabel lingkungan, ulimit, dan sebagainya. Systemd memperbaiki hal ini sebaliknya dengan memberi tahu daemon, yang akan memulai layanan dalam lingkungan yang terdefinisi dengan baik, sehat, dan konstan, di mana tentu saja kinerja layanan lebih mudah diprediksi, karena lingkungan selalu sama.

Ini menyiratkan bahwa, ketika saya memanggil systemctl dari dalam chroot, itu tidak relevan bahwa saya di dalam chroot, lingkungan yang akan diwarisi masih dari PID 1, bukan yang saya miliki saat ini. Tetapi ini menjadi lebih buruk dari ini: karena soket komunikasi diletakkan di dalam / run / systemd, sebuah proses di chroot bahkan tidak akan dapat berbicara dengan sistem init!

Jadi bagaimana Anda melakukan chroot di distro systemd?

  1. Jika semua yang Anda ingin lakukan adalah memiliki wadah Linux, halaman Arch Wiki ini akan memberi tahu Anda cara mengatur wadah Linux dalam waktu kurang dari 30 detik, terima kasih systemd-nspawn.

  2. Jika Anda benar-benar menginginkan lingkungan chroot, halaman Web yang indah dan sebening kristal ini akan memberi Anda dua solusi yang berfungsi (yang kedua adalah versi modifikasi dari yang ditawarkan di titik # 1).

MariusMatutiae
sumber
Saya sudah mencari systemd-nspawntetapi saya tidak bisa menjalankannya. Dan Tidak, ini bukan untuk wadah karena layanan harus digunakan oleh tuan rumah dan arsitektur target.
user2284570
2
Bahwa saya tidak pernah menggunakan systemd di root sistem host saya. Dalam kasus saya, saya tidak dapat mencampur systemd dengan openrc.
user2284570
1
@ Dua. Itu tidak akan berhasil. Menjalankan systemd-nspawngagal dengan "Tidak berjalan pada sistem systemd." kecuali tuan rumah menggunakan systemd juga.
hvd
1
@ Dua Dan saya menjawab karena tidak terdengar sama sekali bagi saya. :) "Saya tidak bisa menjalankannya" adalah hal yang aneh untuk mengatakan jika Anda mengalami kesulitan menemukan executable, itulah sebabnya saya menduga bahwa masalahnya adalah apa yang saya masukkan dalam komentar saya: menjalankannya memberikan pesan kesalahan dan tidak dapat melakukan sesuatu yang bermanfaat. Tetapi bahkan jika ternyata masalahnya benar-benar di mana menemukannya systemd-nspawn, maka menunjuk ke root baru tidak akan membantu. Entah host sudah memilikinya (karena menjalankan systemd), dalam hal ini versi host dapat digunakan, atau host tidak memilikinya, tetapi versi root yang baru tidak akan berfungsi.
hvd
1
systemdakan menolak dijalankan dichroot
Erkin Alp Güney
4

systemd hanya mengabaikan "layanan", jadi saya hanya menjalankan perintah daemon secara manual.

Jadi, bukannya 

service sshd start

saya menggunakan 

/usr/sbin/sshd -D &
JohnP
sumber
Ini tidak berfungsi untuk semua layanan. Beberapa harus dimulai sebagai bagian dari starter layanan sistem seperti Xorg.
user2284570
startxakan bekerja untuk Xorg.
Erkin Alp Güney
@ ErkinAlpGüney: tidak di chroot ... Karena Dbus.
user2284570
4

Beberapa tahun belakangan saya harus mengakui bahwa hanya ada satu solusi untuk sebagian besar masalah praktis Systemd. Karena kesalahannya adalah Systemd sendiri

Saya benar-benar muak dengan Systemd karena saya punya masalah yang tidak pernah saya hadapi dengan hal-hal seperti Upstart atau Openrc:

  • Penegakan kernel yang membutuhkan dukungan cgroups (bukannya dibuat opsional tetapi diaktifkan secara default di dalam file konfigurasi) bahkan untuk sistem embedded dengan hanya 24Mb ram dan tidak ada penyimpanan yang dapat ditulis.
  • Meskipun mengklaim sebagai modular, pada saat runtime neraka dependensi membuatnya menjadi objek dewa yang kuat: ingin boot melalui satu rootf reiser4 tunggal? Itu tidak mungkin karena banyak program systemd-udevdyang membutuhkan systemd-inityang membutuhkan systemd-bootpaket yang tidak dapat diinstal pada saat yang sama daripada grub2juga tidak dapat membaca gambar kernel dari partisi reiser4.
  • Ingin terhubung ke internet melalui dialup Bluetooth? Jika tidak bekerja dengan ponsel java java samsung Anda, maka Anda tidak dapat menjalankan skrip dan perangkat lunak baris perintah yang sebelumnya bekerja secara manual karena networkd.
  • Meskipun saya mengenali masalah terbesar adalah jika Anda membangun dan memelihara distribusi Linux Anda sendiri: modul systemd init itu sendiri memiliki begitu banyak ketergantungan sehingga Anda tidak dapat mengusulkan untuk memilih sistem init lain melalui paket instalasi yang berbeda.
  • Semoga beruntung untuk melihat log jika Anda tidak bisa chroot di sistem Anda atau jika Anda memutakhirkan dari libdb4.8 (padahal setidaknya, dalam kasus terburuk Microsoft memiliki file log itu dalam format xml) .

Satu-satunya solusi:

Systemd adalah kompleks unessary untuk memecahkan masalah: seperti alsa, bukan ossv4. Jadi jika Anda memiliki sesuatu yang menggunakan systemd cukup hapus semua data:

dd if=/dev/urandom of=/dev/dm−0 bs=1M

dan instal sesuatu yang tidak menggunakannya sama sekali sambil menyelesaikan masalah SysV Init seperti Gentoo dengan Openrc.
Mengenai sistem pertanyaan saya, membuat hal-hal seperti registri Windows®: jika sebagian dari itu kacau, maka sudah berakhir.

user2284570
sumber
3
Perlu diketahui bahwa desain sesuatu dapat benar-benar mencegah dari mendapatkan jawaban sehingga jawabannya adalah beralih ke sesuatu yang berfungsi . Dan ini adalah jawaban nyata.
user2284570
1
Saya memiliki pendapat yang sama, sekarang saya memiliki pandangan yang sedikit lebih seimbang. Systemd memiliki keunggulan yang sangat besar sehingga dapat benar-benar membunuh apa yang harus dibunuh . Itu karena ia melacak semua sub-proses bercabang dengan fitur cgroup kernel. Tidak ada alat yang lebih tua yang bisa melakukannya. Selain itu, apakah Anda ingat omong kosong skrip di /etc/init/*.sh? Saya juga, tapi itu hanya memori buruk bagi saya hari ini. File layanan systemd jelas dan konfigurasi panjang sekitar 10 baris . Bukan skrip panjang 200 baris . Keuntungan besar ini memiliki systemd, saya setuju bahwa semua fitur lainnya kurang menguntungkan.
peterh mengatakan mengembalikan Monica
Btw, saya memilih jawaban Anda karena, di samping kelebihannya, persis jenis kritik ini, tepatnya dalam nada ini adalah apa yang dibutuhkan pengembangan sistem dan peningkatan. Sebagai contoh, saya baru saja mencoba untuk memulai postgresql dalam chroot dan saya harus mengacaukan sistem root saya untuk melakukan itu. Banyak, banyak hal jelek masih ada, benar.
peterh mengatakan mengembalikan Monica
@peterh: sayangnya tidak semua orang membagikannya maksud saya sampai menghapus postingan. Ini bukan tentang SysV init terhadap Systemd tetapi lebih terhadap hal-hal seperti Openrc atau bahkan Upstart (yang memungkinkan untuk skrip startup pendek serta mulai layanan paralel). Setidaknya saya belajar satu hal: Darwin sebagian besar ᴏꜱ dari Apple ™ Windows adalah ᴏꜱ dari desain Microsoft dan Linux kebanyakan dijalankan oleh topi merah. Meskipun SysV init saat menjadi lebih lambat tidak membatasi Anda pada apa yang dapat Anda lakukan saat runtime.
user2284570
Skrip @peterh Services juga sangat jelas ketika Anda menggunakan Openrc. Masalah dengan cgroup di Systemd adalah ini bukan pilihan yang mencegah Systemd menjalankan hal-hal seperti Darwin atau NetBSD.
user2284570
3

Tidak. Layanan dijalankan oleh systemd (pid 1), bukan oleh systemctl secara langsung (yang hanya mengirimkan permintaan awal), dan karena systemd berjalan di luar chroot, maka layanannya juga akan dijalankan.

Meskipun secara teknis dimungkinkan untuk mengimplementasikan ini (dengan membuat systemctl entah bagaimana meneruskan akarnya ke systemd), itu agak tidak mungkin terjadi karena sudah ada alat untuk membuat kontainer penuh ( systemd-nspawn /somepath/to_root). Anda selalu dapat menghubungi milis .

grawity
sumber
1
Bagus, Tapi saya perlu menggunakan systemctl karena sistem host saya menggunakan oepnrc. Saya ingin solusi independen penuh
user2284570
3
Saya akan mengeruhkan air lebih jauh dengan mengatakan: Psst! Sebutkan RootDirectory=juga karena Anda sangat kekurangan upvotes. (-:
JdeBP
@ JdeBP: Apa perbedaan (dalam hal hasil) antara variabel RootDirectorydan chrootperintah?
user2284570
@grawity: Jadi Apa yang ditambahkan jika pid 1init?
user2284570
1

Menghadapi masalah ini sekali mencoba memunculkan jaringan dalam mode penyelamatan menggunakan konfigurasi jaringan dari chroot. Akhirnya ini bekerja untuk saya:

service --skip-redirect <service> restart

atau:

SYSTEMCTL_SKIP_REDIRECT=_ /etc/init.d/<service> restart
titik merah
sumber
Bagus. Tapi itu hanya bekerja dengan layanan kompatibel Init yang lama (tidak akan berfungsi untuk jaringan di Fedora rawhide) . Seperti yang saya katakan dalam jawaban saya, solusi sebenarnya adalah dengan mengacaukan apapun yang menggunakan systemd.
user2284570
0

Jika Anda meluncurkan layanan gaya inetd dengan aktivasi soket, pertimbangkan untuk meluncurkan stunnel sebagai gantinya dengan file konfigurasi yang menentukan chroot dan biner Anda sebagai target peluncuran gaya inetd.

Perhatikan bahwa Anda mungkin memiliki masalah SELINUX. Pada sistem Oracle Linux 7.1, saya harus "chcon -v --type = stunnel_etc_t" pada semua file yang perlu dibaca oleh stunnel.

Anda harus menggunakan enkripsi TLS di sisi klien soket (yaitu, stunnel lain dengan "client = yes" di konfigurasi). Beri tahu saya jika Anda ingin detail lebih lanjut tentang ini.

chas
sumber
tidak, ini tentang hal-hal seperti d-bus. Saya melakukannya untuk mendiagnosis masalah pada chroot target.
user2284570
-1

Anda dapat menggunakan nohupperintah untuk memulai layanan di chroot. Untuk memulai httpdlayanan misalnya, saya melakukannya seperti ini.

nohup httpd /dev/null &

untuk menghentikannya pkill httpd

ellooku
sumber
Bagaimana dengan layanan seperti Dbus yang hanya dapat dimulai dengan skrip systemd binary yang diinstal?
user2284570
Anda dapat memulai layanan tersebut dari direktori dengan perintah mulai.
ellooku
Yang merupakan symlink terhadap systemctl. Jadi itu tidak berhasil.
user2284570
Saya melakukan ini sepanjang waktu pada Fedora yang berjalan di Android saya. Mungkin saya tidak tahu apa masalah Anda.
ellooku
Konsekuensinya adalah pesan ini: Running in chroot, ignoring request.. Saya tidak berpikir Anda melakukannya sepanjang waktu chroot. Memang, skrip startup membutuhkan systemd.
user2284570