DietPi-Boot | "[FAILED] Failed to start Daily apt download activities."

[MichaIng]

See this error on every VirtualBox VM (Jessie+Stretch+Buster) and if I remember right also on my RPi:
[FAILED] Failed to start Daily apt download activities.

I remember a commit where we disabled daily apt update, but maybe we can somehow disable the error message?

---

Different error on reboot/shutdown, one of the last messages:
Failed to start Shutdown all ssh sessions before network.

---

Both minor, but just to have it mentioned somwhere

[DarkElvenAngel]

@MichaIng The file /etc/systemd/system/apt-daily.service is a link that points to /dev/null this is what is giving you the error.

I deleted the link and replace the apt-daily.service with this

Description=Apt-daily

[Service]
Type=simple
User=root
ExecStart=/bin/false

[Install]
WantedBy=multi-user.target

That will get rid of the error on the bootup.

[Fourdee]

Reason for mask:

• the service instigates a apt-cache/dpkg lock during updates (daily), which will break dietpi-software and any apt installations.
• DietPi runs G_AGUP as needed.

[MichaIng]

@DarkElvenAngel

Thanks for solution. Simple and clean by dummy service file.

Just for interest, I will try to have a look where the error is produced, maybe we can stop the execution/error msg at it's root.

[DarkElvenAngel]

@MichaIng

I'm not sure I already tried finding the source. I was looking for symlinks to apt-daily.system but I may have already deleted them. but they would be in /etc/systemd/ somewhere if they exists otherwise some other part of the boot process is trying to start the service in another way.

Good luck

[MichaIng]

@DarkElvenAngel
Replacing /etc/systemd/system/apt-daily.service by the dummy service as mentioned above just worked fine, error is gone 🙂!

[MichaIng]

About the ssd stop error:
Found the commit, that was meant to stop error messages: https://github.com/Fourdee/DietPi/commit/0e9806dff2628a41e652a9dc7d11a618b8142aa9#diff-e9e0c6c64b4937739e13ffac58f4a888R290
However systemd seems to have it's own error handling that does not rely on command outputs.

I trief ExecStart=/bin/bash -c '( ps -A | grep sshd ) && killall sshd; ( ps -A | grep dropbear ) && killall dropbear' to do killall only, if process does exist, but the error is just the same. Maybe something else with the service is not right, I am not too deep in this, or simply this commands cannot be run/are not available anymore on shutdown?

@Fourdee
Maybe you have an idea how to suppress this?

[Fourdee]

@MichaIng

Maybe you have an idea how to suppress this?

Not sure, probably needs a full bash script that we can control, check for process/installed service and control it that way. Or systemctl stop dropbear in the service, or something similar.

I'd need to take a stab at it.

[MichaIng]

@Fourdee
Replacing killall by systemctl stop leads to disappearing error message.

The error message only shows up on reboot/shutdown directly on machine terminal, if no SSH session is opened. Persistent system logs need to be enabled to see it after reboot, as it shows up on terminal very short. So to replicate:

1. Use any VirtualBox image, should show up also on all other devices.
2. Start without SSH, directly machines terminal instead and with no SSH session active.
3. mkdir /var/log/journal
4. service systemd-journald restart
5. reboot
6. journalctl -p err -t systemd
7. find Failed to start Shutdown all ssh sessions before network. directly before reboot

To solve error message:

1. sed -i 's/killall/systemctl stop/g' /etc/systemd/system/kill-ssh-user-sessions-before-network.service
2. reboot
3. journalctl -p err -t systemd

BUT:

• systemctl stop dropbear does not quit the current dropbear session, just the listening daemon (2. process)
• So I am not sure what the intention of the service is. Clear signal/message to/on ssh client (putty) that connection was closed on reboot/shutdown only works with killall.

It is finally a bid strange for me, as the service should not know whether it closes daemon AND actual ssh session or just daemon, and in case should not fail, if only a daemon was found. Also on my machine there is no openssh/sshd, thus the first killall sshd anyway 'fails'.

[Fourdee]

@MichaIng

Just a quick look over this:

• Dropbear is a sysinit service /etc/init.d/dropbear. We could probably create our own SystemD one with the additional killall command to kill SSH connections during shutdown.
  -- This all being that OpenSSH no longer requires the the additional killall, nope, it still requires the custom killall.

@MichaIng
I think a bash script to cover both killall and auto detection of Dropbear and OpenSSH, that we can control solution here?

---

Should be resolved with (https://github.com/Fourdee/DietPi/commit/8b2dac62fd81677bcb1dc4cfd329d42da0a25a3c) need to verify with testing later:
[] ensures it does scrape the grep process as a match, as entry must start with the first letter in bracket.

cat << _EOF_ > /etc/systemd/system/kill-ssh-user-sessions-before-network.service
[Unit]
Description=Shutdown all ssh sessions before network
DefaultDependencies=no
Before=network.target shutdown.target

[Service]
Type=oneshot
#ExecStart=/bin/bash -c 'killall sshd &> /dev/null; killall dropbear &> /dev/null'
ExecStart=/bin/bash -c '/var/lib/dietpi/dietpi-software/services/kill-ssh-user-sessions-before-network.sh'

[Install]
WantedBy=poweroff.target halt.target reboot.target
_EOF_
    systemctl daemon-reload
    systemctl enable kill-ssh-user-sessions-before-network

    cat << _EOF_ > /var/lib/dietpi/dietpi-software/services/kill-ssh-user-sessions-before-network.sh
#!/bin/bash
if (( $(ps x | grep -ci -m1 '[s]shd' ) )); then

    killall -w sshd

elif (( $(ps x | grep -ci -m1 '[d]ropbear' ) )); then

    killall -w dropbear

fi

exit 0
_EOF_
    chmod +x /var/lib/dietpi/dietpi-software/services/kill-ssh-user-sessions-before-network.sh

[MichaIng]

@Fourdee
Works on my VMs on Jessie+Stretch+Buster 👍.

@apt-daily.service

• There are three other services: apt-daily.timer, apt-daily-upgrade.service, apt-daily-upgrade.timer and the last two wait for the first and our masked service to start. I guess this the reason, why systemd wants to start them/see them start and even knows the masked services description text.
• So simple solution is to mask all 4 services, as apt upgrade anyway does not make any sense without apt update ;).

[MichaIng]

Fixed and merged changelog: https://github.com/Fourdee/DietPi/pull/1348

[Fourdee]

@MichaIng

Fixed and merged changelog: #1348

Thanks 👍

I'll mark this as closed.