[Bug 1252121] Re: missing PrepareForSleep signal after resuming, causing networking to stay disabled
I've recently upgraded from 12.04 to 14.04. In 12.04 all worked perfectly. I see the same sort of thing as discussed. I attach a log from dbus-monitor. PrepareForSleep True is sent, sleep state is never reached, PrepareForSleep false is never sent I have no problem suspend/hybernate via pm-suspend. sudo /lib/systemd/systemd-sleep suspend also works fine for suspend, hibernate and hybrid-sleep systemd/network manager get in a mess. seemingly together (see test results below) Since I'm on 14.04, I don't have systemd-shim, so this seems to be a systemd problem, not just -shim I used to have tlp installed, but have purged it, and re-installed systemd, the problem has not cleared. Test results: $ sudo gdbus call -y -d org.freedesktop.login1 -o /org/freedesktop/login1 -m org.freedesktop.login1.Manager.Suspend true >> network manager disables, no suspend 2nd call: $ sudo gdbus call -y -d org.freedesktop.login1 -o /org/freedesktop/login1 -m org.freedesktop.login1.Manager.Suspend true Error: GDBus.Error:org.freedesktop.systemd1.LoadFailed: Unit systemd-suspend.service failed to load: No such file or directory. See system logs and 'systemctl status systemd-suspend.service' for details. $ sudo killall NetworkManager >> Network returns. $ sudo gdbus call -y -d org.freedesktop.login1 -o /org/freedesktop/login1 -m org.freedesktop.login1.Manager.Suspend true >> network manager disables, no suspend - Test results2: $ systemctl suspend >> network manager disables, no suspend (no error msg) $ systemctl suspend Failed to issue method call: Unit systemd-suspend.service failed to load: No such file or directory. See system logs and 'systemctl status systemd-suspend.service' for details. Failed to issue method call: Access denied $ sudo killall NetworkManager >> Network returns. $ systemctl suspend >> network manager disables, no suspend (no error msg) $ sudo systemctl status systemd-suspend.service systemd-suspend.service Loaded: error (Reason: No such file or directory) Active: inactive (dead) $ sudo nmcli nm sleep false >> NM restarts, however, it is NOT as 'cleansing' as killing NM As: $ systemctl suspend Failed to issue method call: Unit systemd-suspend.service failed to load: No such file or directory. See system logs and 'systemctl status systemd-suspend.service' for details. ** Attachment added: "dbus log, kill NetworkManager, wait, try to suspend, wait, kill N-Mgr" https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1252121/+attachment/4810108/+files/dbus.log ** No longer affects: systemd (Ubuntu Saucy) -- You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1252121 Title: missing PrepareForSleep signal after resuming, causing networking to stay disabled To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1252121/+subscriptions -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 1252121] Re: missing PrepareForSleep signal after resuming, causing networking to stay disabled
** Also affects: systemd (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1252121 Title: missing PrepareForSleep signal after resuming, causing networking to stay disabled To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1252121/+subscriptions -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 1656341] [NEW] Packaging error (trusty) suspend/resume scripts missing
Public bug reported: systemd-204-5ubuntu20.20, on trusty. sudo /lib/systemd/systemd-sleep suspend / hibernate / hybrid-sleep all function perfectly, however: sudo systemctl suspend / hibernate / hybrid-sleep totally fails. further investigation shows that while man-pages for systemd-suspend.service, etc. are installed, the actual .service and .target files are missing. ** Affects: systemd (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1656341 Title: Packaging error (trusty) suspend/resume scripts missing To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1656341/+subscriptions -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 537970] Re: Evince does not print images in some pdf files.
Further to above... Print to file (tested with pdf, ps and svg) similarly partially removes the logo, which I count as clear evidence the bug is not related to CUPS in any way. -- You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to poppler in Ubuntu. https://bugs.launchpad.net/bugs/537970 Title: Evince does not print images in some pdf files. To manage notifications about this bug go to: https://bugs.launchpad.net/poppler/+bug/537970/+subscriptions -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 537970] Re: Evince does not print images in some pdf files.
Tracked down this bug on meeting the same problem on (fully patched) 14.04 LTS. Print via lpr is fine, via xpdf all is fine, but evince does not print part of embedded pdf logo (the missing bit is pale blue... is there a connection here??) Printing in greyscale does not bring back the missing logo. -- You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to poppler in Ubuntu. https://bugs.launchpad.net/bugs/537970 Title: Evince does not print images in some pdf files. To manage notifications about this bug go to: https://bugs.launchpad.net/poppler/+bug/537970/+subscriptions -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 625357] Re: Previous custom ubuntu-wallpaper disappears after an Ubuntu upgrade
This caught me on upgrading from oneiric to precise, so it is still a problem. I would suggest that the remove script (or a separate tool?) searches known methods for setting the wall paper (unity-2d, unity-3d, gnome2, gnome3, xfce, etc) for all users and deletes what is left. Otherwise every wallpaper-setting tool would need to be modified. -- You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to gnome-control-center in Ubuntu. https://bugs.launchpad.net/bugs/625357 Title: Previous custom ubuntu-wallpaper disappears after an Ubuntu upgrade To manage notifications about this bug go to: https://bugs.launchpad.net/hundredpapercuts/+bug/625357/+subscriptions -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 293535] Re: CPU always 100% CPU
** Package changed: ubuntu = gconf (Ubuntu) ** Changed in: gconf (Ubuntu) Status: Incomplete = Confirmed -- CPU always 100% CPU https://bugs.launchpad.net/bugs/293535 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to gconf in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 293535] Re: CPU always 100% CPU
I've assigned this as a gconf bug, because: (a) it fairly clearly is, from the work-arounds (b) it just shouldn't happen that certain configuration item should put the program into a loop. (c) this bug needs some activity to stop it being deleted. Features of this bug as I've seen it: On upgrading our laptop from intrepid to jaunty (amd64) my login is fine, but my wife's login suffers from gconfd taking 20-20% CPU. Running ltrace on the process gives what seems to be a semi-repeating pattern of: 1. about 400 lines of CORBA_string_dup, gconf_entry_get_is_default, gconf_entry_get_is_writable, gconf_entry_free, CORBA_string_dup, gconf_entry_get_value, gconf_fill_corba_value_from_gconf_value, 2. about 400 lines of g_str_hash, which includes an unchanging 6-line repeat (return codes and parameters unchanging) 3. then about 5 pairs of ORBit_small_allocORBit_small_allocbuff, Then the CORBA_string_dup lines restart after a while of this I sometimes get this sort of pattern too: time(NULL) = 1243842609 gconf_sources_query_value(0x113a300, 0x11ed131, 0x11ea560, 1, 0x75d59d14) = 0 CORBA_string_dup(0x40c726, 0, 0x75d59d80, 0x, 0xfefefefefefefeff) = 0x11d56b1 g_free(0, 0x40c727, 0, 0, 0xfefefefefefefeff)= 0x11d56b1 gconf_locale_list_unref(0x11e34c0, 0x40c727, 0, 0, 0xfefefefefefefeff) = 1 gconf_invalid_corba_value(0x11e34c0, 0x40c727, 0, 0, 0xfefefefefefefeff) = 0x11f9ef0 gconf_log(7, 0x40bfd0, 0x11d56b1, 0x40c296, 88) = 0x60f7a0 gconf_locale_cache_get_list(0x148cc20, 0x11d56b1, 0, 1, 0x75d59da0 unfinished ... g_str_hash(0x11d56b1, 0x11d56b1, 0, 1, 0x75d59da0) = 0x81510175 g_str_equal(0x11f9e30, 0x11d56b1, 0x4054c0, 0x11d56bc, 0x75d59da0) = 1 ... gconf_locale_cache_get_list resumed ) = 0x11e34c0 time(NULL) = 1243842609 Killing gconfd-2 just makes it respawn and the problem is not resolved. -- CPU always 100% CPU https://bugs.launchpad.net/bugs/293535 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to gconf in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 293535] Re: CPU always 100% CPU
Hmm further testing shows: 1. Removing .gconf solves the problem for one login, but it returns on second login. 2. I saw occasional defunct copies of metacity in top. 3. Disabling desktop effects seems to solve the problem So does that make it a metacity / compiz bug? If I understand you right, there is some probably some client (metacity / compiz?) asking for gconf data, crashing because of it, and re-spawning? On the other hand I think there could still be a gconf - related solution to the problem, in that gconf potentially has the ability to stop this cycle. It could well see an activity that is suspect (excessive access to a config item) and make it hang for a while, much like init will stop a task that is respawing too fast... by the way, all those calls to gconf_log... where does the logging data go? -- CPU always 100% CPU https://bugs.launchpad.net/bugs/293535 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to gconf in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
