Почему файловые дескрипторы разделяются между разветвленными процессами?
PAM участвует в изменении пароля, потому что именно так вы выполняете такие действия, как проверка на прочность пароля. Вводы пароля в конфигурационных элементах PAM управляют тем, что сделано.
Моя гипотеза в этой ситуации заключается в том, что это странное взаимодействие между Arch и Debian. Вы запускаете Arch chpasswd , который делает кучу вещей (в основном загружает общие библиотеки), а затем прыгает в контейнер Wheezy и пытается сорваться с его конфигурацией.
Я думаю, что вам повезет значительно больше, просто опустив опцию -root с chpasswd и приклеив перед ней chroot .
Также, только для полноты, вы запускаете chpasswd как root, верно? (усмешка)
Вы запустили ifconfig , чтобы увидеть имена интерфейсов, это хорошее начало. После этого проверьте, подключен ли кабель Ethernet и работает ли он:
[root@splunge ~]# mii-tool enp3s8
enp3s8: negotiated 100baseTx-FD flow-control, link ok
Это от работающего сервера Arch. Для проверки соединения и кабеля можно использовать mii-tool или ethtool .
После того, как вы уверены, что кабель подключен и работает, избавьтесь от любого dhcpcd , который еще работает или зависает или что-то еще:
dhcpcd -k enp3s0
Затем запустите dhcpcd с включенными отладочными сообщениями:
dhcpcd -d enp3s0
Сообщения из этого вызова могут помочь вам решить, что делать дальше.
Обратите внимание, что я предполагаю, что вы su - для входа в систему как root, я считаю использование sudo все время громоздким. Если требуется sudo , измените указанные выше команды соответствующим образом.
ИЗМЕНИТЬ:
Возможно, я неправильно понял ваш вопрос. Если dhcpcd работает, он всегда будет пытаться получить тот же IP-адрес, что и в прошлый раз при аренде.
Вы можете заставить dhcpcd получить совершенно другой IP-адрес, удалив /var/lib/dhcpcd/dhcpcd-enp3s0.lease , а затем остановив и запустив процесс dhcpcd .
работал после изменения availiveLastLine
к availableLastLine= $ (sed 's/\//\\\//' $consolidatedCSVFile$lastLines/$ (basename $file) $lastLine) .
POSIX объясняет рассуждение следующим образом:
There are two reasons why POSIX programmers call fork(). One reason is to create a new thread of control within the same program (which was originally only possible in POSIX by creating a new process); the other is to create a new process running a different program. In the latter case, the call to fork() is soon followed by a call to one of the exec functions.
Когда fork()используется как «потоки бедняка -человека», имеет смысл скопировать файловые дескрипторы. Этот случай использования -должен продолжать поддерживаться, поэтому эта функция останется...