Создайте для него файл:
sudo vim /etc/ld.so.conf.d/my_application.conf
И содержимое этого файла:
/home/jim/usr/lib
Сохранить. Восстановить кеш:
sudo ldconfig -v
Возможно, я опаздываю, и это может быть очевидно, но для меня работала проверка файла конфигурации /etc/ssh/sshd_config: запуск демона с помощью /etc/init.d/ssh start или любой другой комбинации показало, что служба работает, даже если она была нет, но если я запустил исполняемый файл с его абсолютным путем (в моем случае /usr/sbin/sshd), я увидел, что в конце файла конфигурации добавлен «0B», который вызвал ошибку при запуске, удалив его, решив проблему.
Другая потенциальная причина - ufw потеря конфигурации конфигурации правила SSH. Это произошло со мной, по крайней мере, в один или два раза, когда после применения обновлений и перезагрузки конфигурация брандмауэра блокировала доступ к серверу. Использование консоли VPS консоли моего хостинга позволило мне выйти на компьютер и диагностировать проблему. Пример ниже показывает проблему (т. Е. Нет записи для порта 22):
user@host:~$ sudo ufw status verbose
[sudo] password for user:
Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), disabled (routed)
New profiles: skip
To Action From
-- ------ ----
80,443/tcp (Nginx Full) ALLOW IN Anywhere
25/tcp ALLOW IN Anywhere
143 ALLOW IN Anywhere
110 ALLOW IN Anywhere
993/tcp (Dovecot Secure IMAP) ALLOW IN Anywhere
995/tcp (Dovecot Secure POP3) ALLOW IN Anywhere
25/tcp (Postfix) ALLOW IN Anywhere
465/tcp (Postfix SMTPS) ALLOW IN Anywhere
80,443/tcp (Nginx Full (v6)) ALLOW IN Anywhere (v6)
25/tcp (v6) ALLOW IN Anywhere (v6)
143 (v6) ALLOW IN Anywhere (v6)
110 (v6) ALLOW IN Anywhere (v6)
993/tcp (Dovecot Secure IMAP (v6)) ALLOW IN Anywhere (v6)
995/tcp (Dovecot Secure POP3 (v6)) ALLOW IN Anywhere (v6)
25/tcp (Postfix (v6)) ALLOW IN Anywhere (v6)
465/tcp (Postfix SMTPS (v6)) ALLOW IN Anywhere (v6)
Повторное включение порта следующим образом делает трюк:
user@host:~$ sudo ufw allow ssh
Rule added
Rule added (v6)
Для моей системы проблема заключалась в том, что скрипт ssh init /etc/init.d/ssh был единственным, кто проверял наличие вывернутой версии init.
Так что /etc/init.d/ssh не запускается ssh, потому что он считает, что он будет запущен upstart.
В моем случае выскочка не запускается из-за моей конкретной конфигурации:
В /etc/init/ssh.conf была правильная конфигурация, , но также был /etc/init/ssh.override файл, содержащий manual, что означает, что ssh, как ожидается, будет запущен вручную.
Этот файл был создан сценарием установки get-remnux.sh.
Запуск вручную или удаление файла /etc/init/ssh.override решает проблему.