Ada sesuatu yang menyebabkan pembangunan berakhir sebelum waktunya. Ini bukan pembunuh OOM, dan kernel tidak mempunyai sesuatu yang berguna untuk dikatakan di log. Mungkinkah tes bahasa D mengirimkan sinyal ke suatu proses, dan itulah yang mematikan make ? Kami mulai melacak sinyal yang dikirim bpftrace dengan menulis skrip berikut, signals.bt:
tracepoint:signal:signal_generate {
printf("%s PID %d (%s) sent signal %d to PID %d\n", comm, pid, args->sig, args->pid);
}
Dan mengeksekusinya dengan sudo bpftrace signals.bt.
Pembangunannya memakan waktu lama, dan gagal. Melihat keluaran jejak ada yang mencurigakan process.exe mengakhiri barang.
process.exe (PID: 2868133) sent signal 15 to PID 711826
Kelihatannya menarik, tapi kami tidak tahu apa itu PID 711826. Mari kita ubah skripnya sedikit, dan lacak sinyal yang diterima juga.
tracepoint:signal:signal_generate {
printf("PID %d (%s) sent signal %d to %d\n", pid, comm, args->sig, args->pid);
}
tracepoint:signal:signal_deliver {
printf("PID %d (%s) received signal %d\n", pid, comm, args->sig);
}
Versi sbuild yang berfungsi sedang digunakan dumb-initsedangkan yang baru memiliki fitur
sedikit init di Perl. Kami menambal versi sbuild saat ini dengan memanfaatkannya
dumb-init sebagai gantinya, dan lacak dua build: satu dengan perl init, satu lagi dengan
dumb-init.
Berikut adalah sinyal yang diamati saat membangun dengan dumb-init.
PID 3590011 (process.exe) sent signal 2 to 3590014 PID 3590014 (sleep) received signal 9 PID 3590011 (process.exe) sent signal 15 to 3590063 PID 3590063 (std.process tem) received signal 9 PID 3590011 (process.exe) sent signal 9 to 3590065 PID 3590065 (std.process tem) received signal 9
Dan inilah yang terjadi dengan init baru di Perl:
PID 3589274 (process.exe) sent signal 2 to 3589291 PID 3589291 (sleep) received signal 9 PID 3589274 (process.exe) sent signal 15 to 3589338 PID 3589338 (std.process tem) received signal 9 PID 3589274 (process.exe) sent signal 9 to 3589340 PID 3589340 (std.process tem) received signal 9 PID 3589274 (process.exe) sent signal 15 to 3589341 PID 3589274 (process.exe) sent signal 15 to 3589323 PID 3589274 (process.exe) sent signal 15 to 3589320 PID 3589274 (process.exe) sent signal 15 to 3589274 PID 3589274 (process.exe) received signal 9 PID 3589341 (sleep) received signal 9 PID 3589273 (sbuild-usernsex) sent signal 9 to 3589320 PID 3589273 (sbuild-usernsex) sent signal 9 to 3589323
Ada beberapa SIGTERM tambahan yang dikirimkan saat menggunakan perl init, itu berguna. Pada titik ini kami cukup yakin akan hal itu process.exe layak untuk diperiksa tambahan. Itu
kode sumber proses.d menunjukkan sesuatu yang menarik:
1221 @system unittest
1222 {
(...)
1247 auto pid = spawnProcess(("sleep", "10000"),
(...)
1260 // kill the spawned process with SIGINT
1261 // and send its return code
1262 spawn((shared Pid pid) {
1263 auto p = cast() pid;
1264 kill(p, SIGINT);
Jadi ya, itu milik kami sleep dan SIGINT (sinyal 2) tepat di unit test process.dseperti yang telah kita amati pada keluaran bpftrace.
Bisakah kita mempelajari perilaku process.exe secara terpisah, terpisah dari bangunan? Memang kita bisa. Mari kita ambil executable dari build yang gagal, dan coba jalankan di /usr/libexec/sbuild-usernsexec.
Pertama, kita menyiapkan chroot di dalam namespace pengguna yang sesuai:
unshare --map-auto --setuid 0 --setgid 0 mkdir /tmp/rootfs cd /tmp/rootfs cat /home/ema/.cache/sbuild/unstable-arm64.tar | unshare --map-auto --setuid 0 --setgid 0 tar xf - unshare --map-auto --setuid 0 --setgid 0 mkdir /tmp/rootfs/whatever unshare --map-auto --setuid 0 --setgid 0 cp process.exe /tmp/rootfs/
Sekarang kita bisa lari process.exe sendiri menggunakan perl init, dan melacak sinyal sesuka hati:
/usr/libexec/sbuild-usernsexec --pivotroot --nonet u:0:100000:65536 g:0:100000:65536 /tmp/rootfs ema /whatever -- /process.exe
Kita dapat membandingkan perilaku perl init dengan yang menggunakan
dumb-init dalam milidetik, bukan menit.
