u-n does not process a file dropped in /var/lib/update-notifier/user.d until dpkg-run-stamp was written

Bug #248965 reported by Pablo Martí
4
Affects Status Importance Assigned to Milestone
update notifier
Triaged
Medium
Unassigned
update-notifier (Ubuntu)
Incomplete
Medium
Unassigned

Bug Description

This has been detected while trying to restart the package wader-core on an upgrade. We drop the file to /var/lib/update-notifier/user.d but update-notifier does not seem to "see" it. Looks like if it wasn't connected to the signals/events that dropping a file to that dir "fires". The workaround has been to run a "touch /var/lib/update-notifier/dpkg-run-stamp" right after dropping the file, that seems to do the trick.

Running "update-notifier --debug-hooks" seems to stall after this line:

(update-notifier:11839): DEBUG: crashreport_check

And dropping a file fires events as seen in this log:
(I recompiled update-notifier and changed update-notifier.c#L131 to "#if 1")

monitor_uri: file:///var/lib/update-notifier/user.d/
info_uri: file:///var/lib/update-notifier/user.d/wader-core-restart-required
event_type: 0
monitor_uri: file:///var/lib/update-notifier/user.d/
info_uri: file:///var/lib/update-notifier/user.d/wader-core-restart-required
event_type: 5
monitor_uri: file:///var/lib/dpkg/status
info_uri: file:///var/lib/dpkg/status
event_type: 4

But the rest of the sequence is not started either till we run a dpkg -i foo or an apt-get remove bar.

Hope this helps to find the problem

Revision history for this message
Pablo Martí (pmarti) wrote :

I forgot to mention, this is on Hardy w/ update-notifier 0.70.7

Michael Vogt (mvo)
Changed in update-notifier:
assignee: nobody → mvo
importance: Undecided → Medium
status: New → Triaged
Michael Vogt (mvo)
Changed in update-notifier:
importance: Undecided → Medium
status: New → Triaged
Revision history for this message
Michael Vogt (mvo) wrote :

Thanks for your bugreport.

Given that the files installed there are from packages (or the system is designed for that) having the touch requirement sounds not too bad to me. This ensures that e.g. firefox-restart notifciation are not shown until he install is actually finished. Or what is your use-case?

Changed in update-notifier:
status: Triaged → Incomplete
Revision history for this message
Pablo Martí (pmarti) wrote :

We thought that /var/lib/update-notifier/user.d was the place where applications that wanted to use the update-notifier infrastructure should drop a file. Our application required an specific action to be run by the user upon upgrade, thus we dropped a file mimicking how the firefox package does it. The weird part starts here, we found no virtual difference between the way firefox dropped that file there and our way, yet our popup never appeared. Once we started debugging it, we found out that it wouldn't be shown until "touch /var/lib/update-notifier/dpkg-run-stamp".

If u-n shouldn't be used by third-party apps, it should be stated somewhere. If it can be used by third party apps, what are we missing here that the touch command is needed?

Revision history for this message
Michael Vogt (mvo) wrote :

Thanks for this additional information.

There is nothing that prevents third parties from using it, its just that the current main use-case is stuff that is happening during package installation. The dpkg-run-stamp file is automatcially updated when apt is finished
so in practise this should not be a real limitation.

Changed in update-notifier (Ubuntu):
assignee: Michael Vogt (mvo) → nobody
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.