I’ve just tried this out and unfortunately it seems that this technique can’t be applied to ‘apt-get upgrade’. It does work with ‘update’, but I’d like notification on successful upgrade, not update. Not to worry, I’ll keep looking.
Thanks @ashtonaut !!! Keep us posted, I’m really interessted in this topic to push mobile notification with Pushover for example !!!
Instead of
APT::Update::Post-Invoke {"YYYYYYY";};
Try
APT::Upgrade::Post-Invoke {"YYYYYYY";};
(I have not tested it)
yes, the apt&dpkg config options are completely auto-generated with hierarchy:
APT (tool name)
Get (get tool from APT)
Upgrade (command name)
Assume-Yes (options / those normally specified with --xxx)
true (option related value)
what rewritten gets
APT::Get::Upgrade::Assume-Yes true;
and those post-invoke, pre-invoke hooks are defined for any command (of apt).
I tried this and it didn’t appear to work, but that could have been because therre were no longer any updates to install.
I’m trying a few alternatives noted above in the same 99-post-update file and I’ll see which fire at which times over the next while.
Edit: For clarity, I’m trying all of the following:
APT::Update::Post-Invoke-Success {"XX";};
APT::Update::Post-Invoke {"YY";};
APT::Upgrade::Post-Invoke {"ZZ";};
APT::Upgrade::Post-Invoke-Success {"AA";};
Dpkg::Post-Invoke {"BB";};
As a quick update, I am getting daily notifications against
APT::Update::Post-Invoke-Success
APT::Update::Post-Invoke
The notifications come through like clockwork at the same time that I have OSMC set to check for updates each day.
I’ve yet to see the other three events trigger, but this is not a surprise as the system hasn’t updated yet.
Out of interest, should
APT::Dist-Upgrade::Post-Invoke-Success
also work? Based on @mk01’s most recent post my guess is that it should?
Update is just checking for updates - which is why it runs every day on your schedule. That doesn’t tell you whether any were found though, also if any were, this hook would run before they were installed.
Another quick update:
I continue to consistently get notifications following apt-get update as expected.
I tried manually running sudo apt-get upgrade this evening. Several packages were upgraded successfully.
Interestingly, the only notification that fired during the package upgrade process was Dpkg::Post-Invoke (which fired once). I expected APT::Upgrade::Post-Invoke and Post-Invoke-Success to fire as well, but they didn’t…
Edit: From a quick google it seems like there is no APT::Upgrade hook. This would explain why it doesn’t appear to work.
I think you’re right. I couldn’t get the Upgrade hook to work when I tried it either, which is a bit disappointing.
Is there an install hook perhaps ? Upgrades may just count as an install.
The updates you got when you manually ran upgrade would have just been Debian updates - we don’t prompt the user every time some small, usually irrelevant Debian update is released, however when OSMC updates are available the updater will grab all pending Debian updates as well. (Or you can manually install them at any time, as you did)
Any idea what the install hook might look like? There is almost zero documentation on the web about this stuff…
OK, so after going through the recent July update, I can now confirm that the apt-get update hook is the only one that works, even when apt-get upgrade and apt-get dist-upgrade are invoked successfully.
Dpkg::Post-Invoke appears to fire reliably once when packages are upgraded, so I will use this as my trigger to push a notification that packages have been installed.
On a related note, my updatecheck.sh script from earlier in this thread does work, but calling it prior to mediacentre.service doesn’t successfully push the notification - I’m guessing networking is not guaranteed to be up at this point. I need to run this script after networking is up - I recall this question has been answered before so I’ll see if I can find that thread.
Localhost is brought up much earlier than Ethernet so it shouldn’t be that. You won’t be able to send a notification to Kodi before the mediacenter service is running because that is Kodi and Kodi has to be running to receive messages from xbmc-send…
Interesting. You’re right, because the script should fire on restart of the mediacentre service without a reboot, and networking remains up throughout. I can see in the log that the updatecheck.sh script fires correctly but for some reason the push notification doesn’t go through. If it’s not networking it must be something else. I’ll keep looking.
Most likely Kodi is not yet ready to receive messages. The mediacenter service will count as “running” as soon as /usr/bin/mediacenter starts executing but it can take Kodi as much as 10 seconds from that point to reach the Kodi home page where it would be ready to receive and display notifications. So you probably just need a delay after the mediacenter service starts before sending your message of say 10 seconds.
Your point is entirely valid, but I’m not sending messages to Kodi, I’m sending them to my mobile via www.pushover.net from a command line script.
Ah, sorry I thought you were sending Kodi notifications.
So where is your script running from then ? If it is a service you should add an
After = network-online.target
To your service definition, that will cause your service to wait until actual network connectivity is up before running. You also need “wait for network” enabled in the Networking GUI for this to work.
It’s currently firing prior to mediacenter.service:
Looks like I might need to change it to be standalone.
Ah, if you’re running it in the mediacenter service as an ExecStartPre then simply enable “wait for network” in the Networking GUI and your job should be done.
This will delay the mediacenter service until network is up and working. Of course this will slow Kodi boot slightly as well but only by a couple of seconds.
You could create a service of your own but it would only run once on boot - the way you are hooked into the mediacenter service now means that your script will get run again every time the media center service is restarted - which includes after external (blue screen) updates are installed.
Thanks. I’ve just created a standalone updatecheck.service as well:
[Unit]
Description=Run the updatecheck script once on startup after networking is up
After=network-online.target
[Service]
Type=oneshot
ExecStart=/home/osmc/updatecheck.sh | systemd-cat -t updatecheck
[Install]
WantedBy=multi-user.target
I’ll leave both enabled and see if one, both, or none work.
Out of interest, does restarting Kodi from the GUI (using “exit” from the home screen) restart mediacenter.service, or does this service remain running throughout? I’m curious because the script hooked into mediacenter.service doesn’t fire when I exit and restart Kodi from the GUI.
Exiting Kodi from the GUI does not restart the mediacenter service, no. Have a look at the script /usr/bin/mediacenter and you will see a big “while true” (infinite) loop around kodi.bin. This restarts Kodi after waiting for ESC to be pressed.
However when you run updates and it exits to the blue update screen the sequence is the My OSMC updater starts the manual-update service, (/usr/bin/manual-update) the manual-update service stops the mediacenter service, updates proceed, the manual-update service then either initiates a reboot or restarts the mediacenter service depending on whether any update flagged that a reboot was needed. (Most updates don’t actually need a reboot)