Как отключить `apt-daily.service` в образе облачной виртуальной машины Ubuntu?
Я не уверен, нужно ли отвечать на этот старый вопрос, но поскольку он возвращается в результатах поиска , он также может иметь ответ.
Сценарий lua объявляет функции, которые принимают параметры, например:
функция draw_ring (cr, t, pt) . Решение состоит в том, чтобы объявить функцию, которая получает значения вашего скрипта Python.
function myCustomUI(neededValue)
В вашем conkyrc вы вызываете эту функцию, передавая вывод скрипта python. Примерно так:
${lua myCustomUI ${}}
Ваш следующий вопрос: как передать результат в эту переменную? Вот и все:
${execi 3600 python script.py}
Это заставляет ваш код conkyrc выглядеть так:
${lua myCustomUI ${execi 3600 python script.py}}
Конечно, если ваш сценарий исполняемый файл, то вы можете удалить python из вызова execi. 3600 - это просто задержка повторения, чтобы сценарий не запускался постоянно. Дополнительную информацию можно найти здесь
Кроме того, в среде lua доступны переменные conky, так что вы можете сделать оттуда вызов execi , используя тот же формат.
Да, я упустил кое-что очевидное.
Systemd - это одновременный запуск служб, поэтому сценарий cloud-init
запускается одновременно с apt-daily.service запускается. К тому времени, когда
cloud-init сможет выполнить указанную пользователем полезную нагрузку, apt-get update уже будет
. Итак, попытки 2. и 3. потерпели неудачу не из-за какой-то магии пространства имен
, а потому, что они слишком поздно изменили систему для apt.systemd.daily , чтобы
выбрать изменения вверх.
Это также означает, что в принципе нет способа предотвратить запуск
apt.systemd.daily - его можно убить только после его запуска.
Этот сценарий "пользовательских данных" идет по этому пути ::
#!/bin/bash
systemctl stop apt-daily.service
systemctl kill --kill-who=all apt-daily.service
# wait until `apt-get updated` has been killed
while ! (systemctl list-units --all apt-daily.service | egrep -q '(dead|failed)')
do
sleep 1;
done
# now proceed with own APT tasks
apt install -y python
Еще есть временное окно, в течение которого возможен вход по SSH, но apt-get
не запускается, но я не могу представить другое решение, которое может работать на стандартном облачном образе
Ubuntu 16.04.
Не проще ли замаскировать блок
systemctl mask apt-daily.service
?
{{1 }}Вы можете отключить это с помощью облачного -модуля инициализации «bootcmd». Это запускается до запуска сети, что необходимо, прежде чем apt update сможет запуститься.
#cloud-config
bootcmd:
- echo 'APT::Periodic::Enable "0";' > /etc/apt/apt.conf.d/10cloudinit-disable
- apt-get -y purge update-notifier-common ubuntu-release-upgrader-core landscape-common unattended-upgrades
- echo "Removed APT and Ubuntu 18.04 garbage early" | systemd-cat
После того, как вы подключитесь к экземпляру по ssh, вам также следует дождаться завершения заключительных фаз облачной -инициализации, поскольку она перемещает подходящие источники/списки.
# Wait for cloud-init to finish moving apt sources.list around...
# a good source of random failures
# Note this is NOT a replacement for also disabling apt updates via bootcmd
while [ ! -f /var/lib/cloud/instance/boot-finished ]; do
echo 'Waiting for cloud-init to finish...'
sleep 3
done
Это также полезно, чтобы увидеть, как рано запускается bootcmd:
# Show microseconds in systemd journal
journalctl -r -o short-precise
Вы можете убедиться, что это работает следующим образом:
apt-config dump | grep Periodic
# Verify nothing was updated until we run apt update ourselves.
cd /var/lib/apt/lists
sudo du -sh. # small size
ls -ltr # old timestamps
Это ждет 1 секунду в цикле while и проверяет, снята ли блокировка.
while : ; do
sleep 1
echo $( ps aux | grep -c lock_is_held ) processes are using apt.
ps aux | grep -i apt
[[ $( ps aux | grep -c lock_is_held ) > 2 ]] || break
done
echo Apt released
Примечание :К сожалению, часть приведенного ниже решения не работает в системах Ubuntu 16.04 (, таких как система спрашивающего ), потому что предложенный systemd-runвызов работает только на Ubuntu 18.04 и выше(подробности см. в комментариях ). Я оставлю ответ здесь, потому что этот вопрос по-прежнему популярен, независимо от того, какую версию Ubuntu вы используете...
В Ubuntu 18.04 (и выше )может быть до двух служб, участвующих в обновлении/обновлении во время загрузки. Первый apt-daily.serviceобновляет список пакетов. Однако может быть и второй apt-daily-upgrade.service, который фактически устанавливает критически важные для безопасности пакеты. Ответ на вопрос «Завершить и отключить/удалить автоматическое обновление до возврата команды» дает отличный пример того, как дождаться завершения обоих (скопировано здесь для удобства):
systemd-run --property="After=apt-daily.service apt-daily-upgrade.service" --wait /bin/true
(обратите внимание, что это должно быть запущено от имени пользователя root ). Если вы пытаетесь отключить эти службы при загрузке в будущем, вам нужно будет замаскировать ОБЕ службы :
.systemctl mask apt-daily.service apt-daily-upgrade.service
В качестве альтернативы вы можете systemctl disableиспользовать обе службы И связанные с ними таймеры (, т.е. apt-daily.timerиapt-daily-upgrade.timer).
Обратите внимание, что методы маскирования/отключения в этом ответе только предотвращают обновление/обновление при будущих загрузках -они не остановят их, если они уже запущены в текущей загрузке.
На основе решения Анона я создал этот скрипт, который после запуска и перезагрузки решает проблему за меня:
#!/bin/sh
systemctl mask apt-daily.service apt-daily-upgrade.service
systemctl disable apt-daily.service apt-daily-upgrade.service
systemctl disable apt-daily.timer apt-daily-upgrade.timer
Отличные ответы здесь работали на меня целую вечность, но вдруг я начал получать ужасные
{"changed": false, "msg": "Failed to lock apt for exclusive operation"}
снова из Ansible
Я запускаю образ Ubuntu 20.04 AWS в EC2, проблема оказалась в том, что начиная с 16.04 агент AWS SSM -включен по умолчанию в качестве пакета моментальных снимков, и моментальные снимки выполняются на его собственный график обновлений. Агент SSM -пытался обновить как раз в то время, когда я пытался выполнить подходящее обновление. Существуют различные варианты для изменения расписания обновления для Snap или его приостановки на срок до 60 дней, но похоже, что он игнорирует все, что вы говорите для первого обновления, и все равно приведет к сбою инициализации экземпляра.
Единственное, что мне помогло, это бежать:
snap disable amazon-ssm-agent
в качестве первой команды экземпляра пользователя -данных
и:
snap enable amazon-ssm-agent
как последний
Мне потребовалось много времени, чтобы понять это
[обновление]
отключение привязки не удастся, если обновление привязки уже запущено, у меня это сработало
i=0
while ! snap disable amazon-ssm-agent; do
echo 'attempting to disable snap...' $i
sleep 2
((i=i+1))
if [ $i -gt 10 ]; then
echo unable to disable snap..
exit 1
fi
done
какой беспорядок