CPU
Процесс может снизить свой приоритет CPU (но не уменьшить его, man 2 setpriority
). Кроме того, он может усыпить себя в течение определенного времени. Но он не может решить, как экономить время ЦП другим процессам.
Ситуацию с потоками см. в комментарии psusi.
память
Новый процесс получает начальный объем ОЗУ (однако не знаю, является ли это значением ядра по умолчанию или заданным в данных заголовка двоичного файла). Если требуется больше оперативной памяти, процесс запрашивает у ядра дополнительную информацию (см. man 2 mmap
).
Как и во время ЦП, процесс не может решить, какой процесс получит больше памяти, если освободит часть.
Выход из процесса
Если процесс завершает работу (либо по собственному решению, либо в результате прекращения), то ядро автоматически освобождает свои ресурсы. Процесс может освободить «все» его ОЗУ перед выходом, но нет причин для этого. Вместо этого используются вызовы _ exit
или exit _ group
.
Попробуйте этот парень =):
sed -n 'line_num p' | bash
или
"$(sed -n 'line_num p')"
-121--41183- Поскольку $ ДИСПЛЕЯ
правильно наборы и файл ~/.Xauthority
не создан, это может означать, что, хотя X11 пересылка принимается во внимание, xauth
не выполняется. Одной из причин может быть то, что его нет в пути (у меня была эта проблема в Mac OS X, но это было бы странно в Linux). Можно выполнить работу самостоятельно, создав файл ~/.ssh/rc
. Например, у меня есть следующее:
if [ -n "$DISPLAY" ]; then
echo "DISPLAY: $DISPLAY" >&2
if read proto cookie; then
if [ `echo $DISPLAY | cut -c1-10` = 'localhost:' ]; then
echo add unix:`echo $DISPLAY | cut -c11-` $proto $cookie
else
echo add $DISPLAY $proto $cookie
fi | $HOME/.ssh/xauth.wrapper -q -
fi
fi
, где ~/.ssh/xauth.wrapper
является оболочкой для xauth
, которая реализует блокировку файла ~/.Xauthority
. Но вы можете использовать только xauth
или полный путь к xauth
на всякий случай... Это во многом похоже на то, что описано на справочной странице sshd (8) (см. раздел «SSHRC»).
Будьте осторожны, чтобы не ошибиться.
Как заметил Дероберт, hda -> sda
- ожидаемое изменение с давних пор.
Изменение имени рейд-массива было странным, но в конце концов оно разрешилось само собой.
Я попытался загрузиться с live cd-дистрибутива, смонтировать массив raid, смонтировать загрузочный раздел, затем apt-get install
новое ядро. Эта процедура вызвала ошибку, потому что я не знал, что мне следовало смонтировать / boot
, / proc
и / sys
.
Таким образом, точная процедура такова:
загрузка из живого дистрибутива (debian CD 1 в режиме восстановления в порядке)
смонтировать корневой раздел (например, в / chroot) и, в конечном итоге, загрузочный раздел, если он отличается от корневого)
bind монтировать специальные устройства:
mount --bind / sys / chroot / sys
mount --bind / proc / chroot / proc
mount - привязать / dev / chroot / dev
chroot к корневому разделу
установить новое ядро
перезагрузить
новый драйвер ATA в ядре использует /dev/sda, старые драйверы все еще поддерживаются, но вам придется редактировать ядро с помощью chrooting в вашей системе с помощью livecd.
Device drivers --->
<*> ATA/ATAPI/MFM/TLL support (deprecated)
<*> Serial ATA and Parallel ATA drivers --->
Для chrooting я всегда использую минимальную установку gentoo cd и как работать в chrooting в вашей системе вы можете прочитать в gentoo handbook, он также должен работать с вашей системой. Возможно, есть другой способ для пользователей debian, но этот способ должен работать для вас двоих.
Я надеюсь, что это решение вашей проблемы.