ctrl+c никогда не убивает программу,
Есть набор сигналов, которые стандарт POSIX определяет, они используются для управления запущенной программой.
First the signals described in the original POSIX.1-1990 standard.
Signal Value Action Comment
──────────────────────────────────────────────────────────────────────
SIGHUP 1 Term Hangup detected on controlling terminal
or death of controlling process
SIGINT 2 Term Interrupt from keyboard
SIGQUIT 3 Core Quit from keyboard
SIGILL 4 Core Illegal Instruction
SIGABRT 6 Core Abort signal from abort(3)
SIGFPE 8 Core Floating point exception
SIGKILL 9 Term Kill signal
SIGSEGV 11 Core Invalid memory reference
SIGPIPE 13 Term Broken pipe: write to pipe with no
SIGTERM 15 Term Termination signal
- http://man7.org/linux/man-pages/man7/signal.7.html
ctrl+c посылает сигнал 2
, "Прерывание с клавиатуры" на программу, которую вы запустили с терминала.
Вплоть до программы, которая обрабатывает этот сигнал, она может делать с ним все, что захочет. Многие интерпретаторы скриптового языка могут справиться с этим по умолчанию, убивая вызываемый скрипт и изящно завершая работу.
Если вы хотите, чтобы программа выходила, эпизодически из автоматического контекста, рекомендуется Singal 15, программа kill
может быть использована для отправки сигналов процессу по id (pid).
kill -15
Насколько я знаю, программа все равно сама принимает этот сигнал и должна завершить ASAP как можно чище.
Если же программа игнорирует сигнал 15, и программа продолжает жить (и вы не можете не послать сигнал из-за ошибки разрешения)
kill -9
Сигнал 9, насколько мне известно, интерпретируется ядром (диспетчером задач и аппаратным интерфейсом), ядро резко останавливает обработку программы и деблокирует/освобождает все ее ресурсы.
Нет, вам не нужно пересекать -компиляцию (, которая была бы необходима, если бы вы выбрали другую архитектуру. )Я могу придумать два способа настроить свои системы для этого:
Используйте distcc
. Вики Gentoo и Arch хорошо описывают, как установить и настроить программу, поэтому я не буду копировать все здесь целиком. Вкратце, вам нужно настроить следующее, чтобы оно работало:
Ваш CFLAGS
в/etc/portage/make.conf
не должен использовать march=native
или mtune=native
, потому что удаленный компьютер будет использовать свою идею «родного» ЦП, а не локального компьютера. Если вы используете «native», узнайте, какие флаги использовать , запустив:
$ gcc -v -E -x c -march=native -mtune=native - < /dev/null 2>&1 | grep cc1 | perl -pe 's/^.* - //g;'
Оба компьютера нуждаются в одинаковых версиях компилятора и binutils.
distcc
быть установлены, настроены и запущены. Используйте среду chroot
в вашей системе Arch с копией файловой системы вашего Chromebook (относитесь к этому как к установке Gentoo, поэтому скопируйте resolv.conf
из вашей установки Arch и смонтируйте соответствующие файловые системы внутри в соответствии с руководством по установке Gentoo , учитывая предупреждение о /dev/shm
, если версия Arch является символической ссылкой. )Он должен быть как можно ближе к среде вашего Chromebook, иначе вы, возможно, получите неправильные двоичные файлы; если вы сделаете копию, вам придется пересобирать меньше пакетов. Внутри этой среды:
FEATURES="buildpkg"
к /etc/portage/make.conf
. /usr/portage/packages
. Вы также можете скомпилировать ядро таким же образом и просто скопировать сгенерированное ядро и соответствующий каталог /lib/modules
на Chromebook. (Помните, что расположение этих каталогов относится к chroot! )Вики рекомендует иметь монтирование NFS или другой сервер, чтобы вам не приходилось копировать файлы вручную :это можно настроить в самой системе Arch.Мне нравится настраивать rsyncd
для этой цели, но используйте любой метод, который вы предпочитаете для доступа к файлам. На Chromebook:
FEATURES="getbinpkg"
к /etc/portage/make.conf
, если вы хотите предотвратить локальную компиляцию. PORTAGE_BINHOST="protocol://path/to/your/chroot/usr/portage/packages"
к /etc/portage/make.conf
. Дополнительную информацию см. в руководстве Двоичный пакет на вики Gentoo .
Я использовал оба этих метода в прошлом, и они оба работают очень хорошо. Мои наблюдения над двумя методами:
distcc
привередлив в работе, даже если у вас идентичные настройки с обеих сторон. Сохранение одинаковых версий gcc
и binutils
будет вашей самой большой проблемой. Однако, как только вы начнете это делать, это будет довольно быстро, и если у вас есть дополнительные компьютеры, которые достаточно быстры, вы можете добавить их.
Среда chroot
менее привередлива, но если вы вносите изменения в любую часть среды portage (CFLAGS
, USE
флаги, маски, профили и т. д. )вы должны убедиться, что обе стороны оставайтесь последовательными, иначе вы можете получить пакеты с неправильными зависимостями. Gentoo очень хорошо проверяет совпадение USE-флагов, но не отслеживает параметры компилятора в бинарных пакетах. Одним из преимуществ является то, что вы не ограничены (нехваткой )дискового пространства и памяти на Chromebook для компиляции.
Если вы собираетесь использовать метод chroot
, я бы написал скрипт для выполнения всей неинтересной работы, необходимой для его настройки (замените /mnt/gentoo
на ваше расположение в chroot):
cp -L /etc/resolv.conf /mnt/gentoo/etc
mount -t proc proc /mnt/gentoo/proc
mount --rbind /sys /mnt/gentoo/sys
mount --make-rslave /mnt/gentoo/sys
mount --rbind /dev /mnt/gentoo/dev
mount --make-rslave /mnt/gentoo/dev
chroot /mnt/gentoo /bin/bash
umount -R /mnt/gentoo/dev
umount -R /mnt/gentoo/sys
umount /mnt/gentoo/proc