最初に少し背景を説明しapt-get install
ます。会社のインターネットからダウンロードすると、最初の 10 秒間は高速バースト (400 ~ 500KB/秒) になり、その後 10 分の 1 (40 ~ 50KB/秒) に落ちます。そして数分後、本当に惨めな状態になります (4-5KB/秒)。これは、システム管理者がある種のネットワーク スロットリング スキームを実装したと思わせます。
これで、ネットワークが単に不安定ではないことがわかりましapt-get install foo
た.すべてのパッケージがダウンロードされます。大きなパッケージでも非常に高速にダウンロードできます。特に、Ctrl-C でダウンロードを中断した後でも、apt-get は次の呼び出しでダウンロードを再開できるようです。Ctrl-C
apt-get install foo
もちろん、10 秒ごとに Ctrl-C Up Enter を押しながら画面を見つめていると、すぐに飽きてしまうので、シェル スクリプトを作成しました。
#!/bin/sh
for i in `seq 1 100` ; do
sudo apt-get install foo -y &
sleep 10
sudo kill -2 $!
done
これはうまくいくようです。apt-get を生成し、10 秒間実行してから (SIGINT を送信して) 強制終了し、再度起動します。ただし、apt-get はその後の呼び出しでダウンロードを再開しないため、実際には機能しません。
sudo apt-get install foo
ある端末から実行kill -2 <PID of apt-get>
し、別の端末から実行した実験。その場合でも、apt-get を再起動しても、ダウンロードが再開されません。
したがって、明らかに Ctrl-C はSIGINT と同等ではありません。また、Ctrl-C を手動で実行すると、apt-get にダウンロードの状態を保存する機会が与えられます。問題は - それは何ですか?
編集
これらは私がこれまでに受け取った提案ですが、葉巻はありません. 謎が深まる!-
信号ではの代わりに に
sudo kill -2 $!
行く可能性があります。上記のように、特に apt-get の PID に SIGINT を送信しようとしても、apt-get がその状態を保存できないため、これは理由ではありません。sudo
apt-get
Sudo はシグナルをキャッチし、別のシグナルを apt-get に送信します。考えられるすべてのシグナルをapt-getに送信してみました!いずれのダウンロードも再開されません。Ctrl-C を実行して強制終了した場合にのみ、ダウンロードが再開されます。
Apt-get は、対話型シェルではなくスクリプトからのものである場合、SIGINT を異なる方法で処理します。繰り返しますが、上記の「実験」は、これが正しくないことを証明しています。