Ubuntu

如何在 Ubuntu 雲虛擬機映像上禁用“apt-daily.service”?

  • December 18, 2020

Ubuntu 16.04 伺服器 VM 映像顯然每 12 小時左右啟動一次“apt-daily.service”;此服務執行各種與 APT 相關的任務,例如刷新可用軟體包列表、在需要時執行無人值守升級等。

當從虛擬機“快照”啟動時,服務會立即被觸發,因為(我認為)systemd 很快意識到計時器早就應該關閉了。

但是,正在執行的 APT 會阻止其他apt程序執行,因為它持有/var/lib/dpkg. 指示這一點的錯誤消息如下所示:

E: Could not get lock /var/lib/dpkg/lock-frontend - open (11: Resource temporarily unavailable)
E: Unable to acquire the dpkg frontend lock (/var/lib/dpkg/lock-frontend), is another process using it?

我需要禁用這個自動 APT 任務,直到 Ansible 完成機器設置(這通常涉及安裝包);有關更多資訊和上下文,請參閱https://github.com/gc3-uzh-ch/elasticluster/issues/304

我已經嘗試了各種選項來通過“使用者數據”腳本禁用“無人值守升級”功能cloud-init,但到目前為止所有這些選項都失敗了。

1.禁用systemd任務

systemd 任務apt-daily.serviceapt-daily.timer. 我試圖通過以下命令的各種組合禁用其中一個或兩個,或兩者兼而有之;仍然,apt-daily.service在 VM 準備好接受 SSH 連接後立即啟動::

   #!/bin/bash

   systemctl stop apt-daily.timer
   systemctl disable apt-daily.timer
   systemctl mask apt-daily.service
   systemctl daemon-reload

2.禁用配置選項APT::Periodic::Enable

腳本/usr/lib/apt/apt.systemd.daily讀取一些 APT 配置變數;該設置APT::Periodic::Enable完全禁用該功能(第 331–337 行)。我嘗試使用以下腳本禁用它::

   #!/bin/bash

   # cannot use /etc/apt/apt.conf.d/10periodic as suggested in
   # /usr/lib/apt/apt.systemd.daily, as Ubuntu distributes the
   # unattended upgrades stuff with priority 20 and 50 ...
   # so override everything with a 99xxx file
   cat > /etc/apt/apt.conf.d/99elasticluster <<__EOF
   APT::Periodic::Enable "0";
   // undo what's in 20auto-upgrade
   APT::Periodic::Update-Package-Lists "0";
   APT::Periodic::Unattended-Upgrade "0";
   __EOF

然而,儘管APT::Periodic::Enable0來自命令行的值(見下文),unattended-upgrades程序仍在執行……

   ubuntu@test:~$ apt-config shell AutoAptEnable APT::Periodic::Enable
   AutoAptEnable='0'

3./usr/lib/apt/apt.systemd.daily完全刪除

以下cloud-init腳本完全刪除了無人值守的升級腳本:

   #!/bin/bash

   mv /usr/lib/apt/apt.systemd.daily /usr/lib/apt/apt.systemd.daily.DISABLED

儘管如此,任務仍在執行,我可以在程序表中看到它!雖然如果從命令行探測該文件不存在::

ubuntu@test:~$ ls /usr/lib/apt/apt.systemd.daily
ls: cannot access '/usr/lib/apt/apt.systemd.daily': No such file or directory

看起來cloud-init腳本(連同 SSH 命令行)和 root systemd 程序在單獨的文件系統和程序空間中執行……

問題

我有什麼明顯的遺漏嗎?還是有一些我不知道的命名空間魔法?

最重要的是:如何apt-daily.service通過 cloud-init腳本禁用?

是的,我錯過了一些明顯的東西。

Systemd 是關於服務的並發啟動,因此cloud-init腳本在觸發的同時執行。apt-daily.servicecloud-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 雲映像上執行的解決方案。

引用自:https://unix.stackexchange.com/questions/315502