Не удалось разрешить хост: content.dropboxapi.com, когда загружать файл при выключении
Метод 1
Если это проблема, с которой сталкиваются все пользователи в вашей системе ... Возможно, подумайте о том, чтобы добавить ее в /etc/profile, поскольку она запускается каждый раз, когда пользователь регистрируется? ???
Способ 2
Если вы не хотите использовать этот метод, вы можете просто добавить что-то вроде source ~/.bashrc в конец /etc/profile, чтобы он автоматически сделал это. .
Но в любом случае ... Любой метод должен исправить вашу проблему ...
9 ответов
метод 1: /etc/systemd/system/upload.service 1.1 /etc/systemd/system/upload.service
sudo vim /etc/systemd/system/upload.service
[Unit]
Description=upload files into dropbox
Before=shutdown.target reboot.target
Requires=network-online.target
After=network.target
[Service]
ExecStop=/bin/true
ExecStart=/bin/bash /home/upload.sh
StandardOutput=journal
StandardError=journal
[Install]
WantedBy=multi-user.target
1.2 vim /home/upload.sh
[ f2]1.3 sudo systemctl enable upload service
метод 2: /lib/systemd/system-shutdown/upload.service 2.1 / lib / systemd / system-shutdown / upload.service
sudo vim /lib/systemd/system-shutdown/upload.service
[Unit]
Description=upload files into dropbox
Before=shutdown.target reboot.target
Requires=network-online.target
After=network.target
[Service]
ExecStop=/bin/true
ExecStart=/bin/bash /home/upload.sh
StandardOutput=journal
StandardError=journal
[Install]
WantedBy=multi-user.target
2.2 vim /home/upload.sh
cd /home
curl -X POST https://content.dropboxapi.com/2/files/upload \
--header "Authorization: Bearer xxxx" \
--header "Dropbox-API-Arg: {\"path\":\"/test.txt\",\"mode\":{\".tag\":\"overwrite\"}}" \
--header "Content-Type: application/octet-stream" \
--data-binary @"test.txt"
2.3 sudo systemctl включить /lib/systemd/system-shutdown/upload.service [!d7 ]
метод 1: /etc/systemd/system/upload.service 1.1 /etc/systemd/system/upload.service
sudo vim /etc/systemd/system/upload.service
[Unit]
Description=upload files into dropbox
Before=shutdown.target reboot.target
Requires=network-online.target
After=network.target
[Service]
ExecStop=/bin/true
ExecStart=/bin/bash /home/upload.sh
StandardOutput=journal
StandardError=journal
[Install]
WantedBy=multi-user.target
1.2 vim /home/upload.sh
cd /home
curl -X POST https://content.dropboxapi.com/2/files/upload \
--header "Authorization: Bearer xxxx" \
--header "Dropbox-API-Arg: {\"path\":\"/test.txt\",\"mode\":{\".tag\":\"overwrite\"}}" \
--header "Content-Type: application/octet-stream" \
--data-binary @"test.txt"
1.3 sudo systemctl enable upload service
метод 2: /lib/systemd/system-shutdown/upload.service 2.1 / lib / systemd / system-shutdown / upload.service
sudo vim /lib/systemd/system-shutdown/upload.service
[Unit]
Description=upload files into dropbox
Before=shutdown.target reboot.target
Requires=network-online.target
After=network.target
[Service]
ExecStop=/bin/true
ExecStart=/bin/bash /home/upload.sh
StandardOutput=journal
StandardError=journal
[Install]
WantedBy=multi-user.target
2.2 vim /home/upload.sh
cd /home
curl -X POST https://content.dropboxapi.com/2/files/upload \
--header "Authorization: Bearer xxxx" \
--header "Dropbox-API-Arg: {\"path\":\"/test.txt\",\"mode\":{\".tag\":\"overwrite\"}}" \
--header "Content-Type: application/octet-stream" \
--data-binary @"test.txt"
2.3 sudo systemctl включить /lib/systemd/system-shutdown/upload.service
метод 1: /etc/systemd/system/upload.service 1.1 /etc/systemd/system/upload.service
sudo vim /etc/systemd/system/upload.service
[Unit]
Description=upload files into dropbox
Before=shutdown.target reboot.target
Requires=network-online.target
After=network.target
[Service]
ExecStop=/bin/true
ExecStart=/bin/bash /home/upload.sh
StandardOutput=journal
StandardError=journal
[Install]
WantedBy=multi-user.target
1.2 vim /home/upload.sh
cd /home
curl -X POST https://content.dropboxapi.com/2/files/upload \
--header "Authorization: Bearer xxxx" \
--header "Dropbox-API-Arg: {\"path\":\"/test.txt\",\"mode\":{\".tag\":\"overwrite\"}}" \
--header "Content-Type: application/octet-stream" \
--data-binary @"test.txt"
1.3 sudo systemctl enable upload service
метод 2: /lib/systemd/system-shutdown/upload.service 2.1 / lib / systemd / system-shutdown / upload.service
sudo vim /lib/systemd/system-shutdown/upload.service
[Unit]
Description=upload files into dropbox
Before=shutdown.target reboot.target
Requires=network-online.target
After=network.target
[Service]
ExecStop=/bin/true
ExecStart=/bin/bash /home/upload.sh
StandardOutput=journal
StandardError=journal
[Install]
WantedBy=multi-user.target
2.2 vim /home/upload.sh
cd /home
curl -X POST https://content.dropboxapi.com/2/files/upload \
--header "Authorization: Bearer xxxx" \
--header "Dropbox-API-Arg: {\"path\":\"/test.txt\",\"mode\":{\".tag\":\"overwrite\"}}" \
--header "Content-Type: application/octet-stream" \
--data-binary @"test.txt"
2.3 sudo systemctl включить /lib/systemd/system-shutdown/upload.service
Лучший способ запустить программу или скрипт во время спуска системы - использовать ExecStop= устройства для запуска такой программы. [F5] может быть либо фиктивным сценарием (например, /bin/true), либо в последних версиях systemd его можно даже опустить.
Что касается зависимостей, вы хотите разместить свое подразделение после служб вам нужно, например network-online.target и, возможно, systemd-resolved.service, если вы используете его для разрешения DNS. Причиной этого является то, что системы останавливаются при выключении в обратном порядке, в котором они запускаются. Таким образом, заказывая свою службу после зависимостей, это означает, что ваш скрипт ExecStop= будет запущен до того, как будут остановлены зависимости.
Что-то вроде этого должно работать:
[Unit]
Description=upload files into dropbox
After=network.target systemd-resolved.service
Requires=network-online.target
[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/bin/true
ExecStop=/bin/bash /home/upload.sh
StandardOutput=journal
StandardError=journal
[Install]
WantedBy=multi-user.target
Включить как обычно (аргумент --now также запускает его):
$ sudo systemctl enable --now upload.service
И он выполнит загрузку, когда после , с которой вы можете проверить:
$ sudo systemctl stop upload.service
Это было недавно обсуждено в списке рассылки systemd-devel.
Execstop и Execstart изменились в обратном направлении
Согласно этому Unix & amp; Ответ на Linux: как запустить скрипт с systemd перед выключением, Execstop и Execstart будут отменены.
Строки:
ExecStop=/bin/true
ExecStart=/bin/bash /home/upload.sh
Должно читать:
В дальнейшем упоминается перезапуск служб. Поэтому после создания файла убедитесь, что systemctl daemon-reload и systemctl enable yourservice --now
Альтернативный метод не работает
before=, requires=, и т. д. иногда могут вводить в заблуждение. Вместо этого вы можете поместить свой скрипт в каталог /usr/lib/systemd/system-shutdown/. Он будет запущен сразу после выключения. См.: Как запустить скрипт с systemd прямо перед выключением
Префикс /usr может быть другим в некоторых системах, то есть просто запустите имя каталога с помощью /lib. 10]
-
1Пожалуйста, попробуйте на своем компьютере такую же ошибку, как и раньше. – it_is_a_literature 17 April 2018 в 03:36
-
2@it_is_a_literature Я пересмотрел ответ и добавил systemd метод, основанный на вашем вопросе. Старый ответ был устаревшим в «Альтернативный». раздел. Обратите внимание, что ответ, который вы приняли, имеет start и stop отмененный? – WinEunuuchs2Unix 22 April 2018 в 21:34
Лучший способ запустить программу или скрипт во время спуска системы - использовать ExecStop= устройства для запуска такой программы. [F5] может быть либо фиктивным сценарием (например, /bin/true), либо в последних версиях systemd его можно даже опустить.
Что касается зависимостей, вы хотите разместить свое подразделение после служб вам нужно, например network-online.target и, возможно, systemd-resolved.service, если вы используете его для разрешения DNS. Причиной этого является то, что системы останавливаются при выключении в обратном порядке, в котором они запускаются. Таким образом, заказывая свою службу после зависимостей, это означает, что ваш скрипт ExecStop= будет запущен до того, как будут остановлены зависимости.
Что-то вроде этого должно работать:
[Unit]
Description=upload files into dropbox
After=network.target systemd-resolved.service
Requires=network-online.target
[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/bin/true
ExecStop=/bin/bash /home/upload.sh
StandardOutput=journal
StandardError=journal
[Install]
WantedBy=multi-user.target
Включить как обычно (аргумент --now также запускает его):
$ sudo systemctl enable --now upload.service
И он выполнит загрузку, когда после , с которой вы можете проверить:
$ sudo systemctl stop upload.service
Это было недавно обсуждено в списке рассылки systemd-devel.
Execstop и Execstart изменились в обратном направлении
Согласно этому Unix & amp; Ответ на Linux: как запустить скрипт с systemd перед выключением, Execstop и Execstart будут отменены.
Строки:
ExecStop=/bin/true
ExecStart=/bin/bash /home/upload.sh
Должно читать:
ExecStart=/bin/true
ExecStop=/bin/bash /home/upload.sh
В дальнейшем упоминается перезапуск служб. Поэтому после создания файла убедитесь, что systemctl daemon-reload и systemctl enable yourservice --now
Альтернативный метод не работает
before=, requires=, и т. д. иногда могут вводить в заблуждение. Вместо этого вы можете поместить свой скрипт в каталог /usr/lib/systemd/system-shutdown/. Он будет запущен сразу после выключения. См.: [D2] Как запустить скрипт с systemd прямо перед выключением
Префикс /usr может быть другим в некоторых системах, то есть просто запустите имя каталога с помощью /lib.
Лучший способ запустить программу или скрипт во время спуска системы - использовать ExecStop= устройства для запуска такой программы. [F5] может быть либо фиктивным сценарием (например, /bin/true), либо в последних версиях systemd его можно даже опустить.
Что касается зависимостей, вы хотите разместить свое подразделение после служб вам нужно, например network-online.target и, возможно, systemd-resolved.service, если вы используете его для разрешения DNS. Причиной этого является то, что системы останавливаются при выключении в обратном порядке, в котором они запускаются. Таким образом, заказывая свою службу после зависимостей, это означает, что ваш скрипт ExecStop= будет запущен до того, как будут остановлены зависимости.
Что-то вроде этого должно работать:
[Unit]
Description=upload files into dropbox
After=network.target systemd-resolved.service
Requires=network-online.target
[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/bin/true
ExecStop=/bin/bash /home/upload.sh
StandardOutput=journal
StandardError=journal
[Install]
WantedBy=multi-user.target
Включить как обычно (аргумент --now также запускает его):
$ sudo systemctl enable --now upload.service
И он выполнит загрузку, когда после , с которой вы можете проверить:
$ sudo systemctl stop upload.service
Это было недавно обсуждено в списке рассылки systemd-devel.
Execstop и Execstart изменились в обратном направлении
Согласно этому Unix & amp; Ответ на Linux: как запустить скрипт с systemd перед выключением, Execstop и Execstart будут отменены.
Строки:
ExecStop=/bin/true
ExecStart=/bin/bash /home/upload.sh
Должно читать:
ExecStart=/bin/true
ExecStop=/bin/bash /home/upload.sh
В дальнейшем упоминается перезапуск служб. Поэтому после создания файла убедитесь, что systemctl daemon-reload и systemctl enable yourservice --now
Альтернативный метод не работает
before=, requires=, и т. д. иногда могут вводить в заблуждение. Вместо этого вы можете поместить свой скрипт в каталог /usr/lib/systemd/system-shutdown/. Он будет запущен сразу после выключения. См.: [D2] Как запустить скрипт с systemd прямо перед выключением
Префикс /usr может быть другим в некоторых системах, то есть просто запустите имя каталога с помощью /lib.
-
1Пожалуйста, попробуйте на своем компьютере такую же ошибку, как и раньше. – it_is_a_literature 17 April 2018 в 03:36
-
2@it_is_a_literature Я пересмотрел ответ и добавил systemd метод, основанный на вашем вопросе. Старый ответ был устаревшим в «Альтернативный». раздел. Обратите внимание, что ответ, который вы приняли, имеет start и stop отмененный? – WinEunuuchs2Unix 22 April 2018 в 21:34