838203 - test_alerts.html times out on ubuntu 12.04 VM, please remove notification-daemon package

Status: RESOLVED FIXED

(Release Engineering :: General, defect)

Description

[Joel Maher ( :jmaher ) (UTC -8)]

We are moving our linux unittests to ubuntu 12.04 VM machines.  test_alerts.html fails due to a time out.  I run this same OS on my desktop and it works just fine.

I have played around with this in the VM and clicking the alert will allow the test to pass, but anything else will cause the test to timeout.

Is this supported in a VM?
Are there things I could try to make this work?
Should I disable this test for linux?

Comment 1

[Chris Coulson]

That's odd. We haven't had to disable this test for our Ubuntu builds of Firefox. Are you running the test inside a full user session (ie, with session Dbus etc)?

Comment 2

[Joel Maher ( :jmaher ) (UTC -8)]

This is in a virtual machine on Amazon EC2 via an Xfvb session.

Comment 3

[Karl Tomlinson (:karlt)]

The screenshot in https://tbpl.mozilla.org/php/getParsedLog.php?id=19101631&tree=Cedar#error0 seems to be a full session.  (I don't know what a full session would usually look like.)

What is not expected there is the "Show All Downloads" dropdown.  That appears to be left over from a previous test.  Perhaps that might be preventing the session from displaying the alert.  Are you able to run just test_alerts on the VM?

Perhaps 'INFO -  Xlib:  extension "RANDR" missing on display ":0".' could also be a clue to the differences between the desktop and VM.  Are you able to check ~/.xsession-errors for any hints that the session alert service failed?

Comment 4

[Joel Maher ( :jmaher ) (UTC -8)]

I can reproduce this if I do it with just the single test (not leftover stuff).  I don't see anythin in .xsession-errors.  The RANDR stuff might be a good clue.

Comment 5

[Karl Tomlinson (:karlt)]

I don't know what is happening here.  The test is waiting for the system notification server to close the notification.  There is no guarantee or really even an expectation that the daemon will close the notification within any given time period because the timeout period is selected by the server.  However, the test seems to work fine on Desktop Ubuntu and in Ubuntu's testing.

It is odd that there is no notification visible in the screenshot.

I wonder whether it is possible that the DBUS_SESSION_BUS_ADDRESS environment variable could be pointing to a session on another display.
Is the process that runs the tests a descendant of the process that started the user session?

Comment 6

[Karl Tomlinson (:karlt)]

Bug 794174 was a problem using GConf on mock slaves.  GConf uses DBus, so perhaps this might be related.

Comment 7

[Joel Maher ( :jmaher ) (UTC -8)]

The notification is dismissed in the same amount of time as a desktop instance of ubuntu or the vm instance.  The resulting screenshot is of the OS desktop 5 minutes after the test was launched (about 4:55 after the notification dismissed itself).

Comment 8

[Joel Maher ( :jmaher ) (UTC -8)]

I don't know how to determine if the DBUS_SESSION_BUS_ADDRESS is for another display.  It is different from my desktop, but it doesn't appear incorrect.  

Any tips for things to try out with this test?

Comment 9

[Karl Tomlinson (:karlt)]

If the alert is showing on the VM display, then DBUS_SESSION_BUS_ADDRESS must be OK.
Sounds like we may not be getting the NotificationClosed signal when the notification is timing out.

I haven't reproduced running against Xfvb here (Gentoo).

Can you get a trace with dbus-monitor?  DBUS_SESSION_BUS_ADDRESS will need to be set for dbus-monitor.  Perhaps you can read that from /proc/<pid>/environ from something in the session.

Comment 10

[Joel Maher ( :jmaher ) (UTC -8)]

aha, the dbus-monitor set me on the right path.

For my working desktop I was using notify-osd, and the failing VM I was using notification-daemon.  

I did a 'apt-get remove notification-daemon; reboot', then the test passed for me.

Is this expected?  
Should we just remove that in our master image and move forward?
I am open to trying other ideas to debug or resolve this.

Comment 11

[Karl Tomlinson (:karlt)]

It's not a difference in behavior that I would have expected.
I don't have any other ideas for investigation beyond debugging notification-daemon, but I don't think we need to get into that unless this is actually causing real issues for users.  If it is working with notify-osd, then it sounds like it is not our problem.

Is notify-osd installed on the VM?  It would be good to have a system Notifications service because, if there is not any, then a fallback path is used.  I'd prefer to have the system Notifications path tested (though I am seeing an abort on shutdown due to a cairo hash table entry memory leak when running the test without a system Notifications service).

Comment 12

[Joel Maher ( :jmaher ) (UTC -8)]

The vm has both notification-daemon and notify-osd installed, it just uses the notification-daemon by default.  From the sounds of the previous comment, using notify-osd is valid enough for testing, and we should have test cases or bugs open to ensure compatibility with other systems.

Comment 13

[Karl Tomlinson (:karlt)]

(In reply to Joel Maher (:jmaher) from comment #12)
> From the sounds of the previous
> comment, using notify-osd is valid enough for testing

Yes, that is what I meant.

Comment 14

[Rail Aliiev [:rail]]

Attachment: remove notification-daemon

Removing this package doesn't remove any other dependent package. libv8-3.7.12.22 can be ignored since it was obsoleted by libv8-3.11.10 upgraded in bug 831771.

# apt-get remove notification-daemon 
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following package was automatically installed and is no longer required:
  libv8-3.7.12.22
Use 'apt-get autoremove' to remove them.
The following packages will be REMOVED:
  notification-daemon
0 upgraded, 0 newly installed, 1 to remove and 164 not upgraded.
After this operation, 168 kB disk space will be freed.
Do you want to continue [Y/n]? ^C

Comment 15

[Dustin J. Mitchell [:dustin] (he/him)]

Comment on attachment 718405 [details] [diff] [review]
remove notification-daemon

This is fine, but would it make more sense to put this in disableservices?

Comment 16

[Rail Aliiev [:rail]]

(In reply to Dustin J. Mitchell [:dustin] from comment #15)
> Comment on attachment 718405 [details] [diff] [review]
> remove notification-daemon
> 
> This is fine, but would it make more sense to put this in disableservices?

Could be, since notification-daemon is a service-like package even thought it runs from userland. I'll update the patch.

Comment 17

[Rail Aliiev [:rail]]

Attachment: remove notification-daemon

Comment 18

[Rail Aliiev [:rail]]

Comment on attachment 718444 [details] [diff] [review]
remove notification-daemon

http://hg.mozilla.org/build/puppet/rev/d028b5c1ef99

Comment 19

[Rail Aliiev [:rail]]

The package should be removed by now.