[Touch-packages] [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 Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1252121 Title: missing PrepareForSleep signal after resuming, causing networking to stay disabled Status in systemd package in Ubuntu: New Status in systemd-shim package in Ubuntu: Confirmed Status in systemd-shim source package in Saucy: Won't Fix Status in systemd source package in Trusty: New Status in systemd-shim source package in Trusty: Confirmed Bug description: As per request from bug #1184262, this is a new report, along with dbus (to be attached) ProblemType: Bug DistroRelease: Ubuntu 13.10 Package: systemd-services 204-0ubuntu19 Uname: Linux 3.12.0-custom x86_64 ApportVersion: 2.12.5-0ubuntu2.1 Architecture: amd64 Date: Sun Nov 17 20:24:41 2013 MarkForUpload: True SourcePackage: systemd UpgradeStatus: Upgraded to saucy on 2013-10-17 (31 days ago) SRU INFORMATION: FIX: https://github.com/desrt/systemd-shim/commit/9e1ebe3ab (in trusty already) Regression potential: Low. Flushing the session bus was introduced in version 4 and is obviously bogus as in a system D-BUS service there is no session bus. This causes lots of confusing error messages and unnecessary overhead like trying to start dbus-launch. Flushing the system bus is low-risk, in most cases it's a no-op and it would otherwise prevent losing signals after waking up. No known regressions. TEST CASE: Run several suspend/resume cycles with the lid, session indicator menu, and verify that the network comes back up. It is known that this fix is necessary but not sufficient, so it is not expected to fix all cases. But it should not make things worse, so if network now does not come up any more on a machine where it previously worked this would count as failure/regression. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1252121/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [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 Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1252121 Title: missing PrepareForSleep signal after resuming, causing networking to stay disabled Status in systemd package in Ubuntu: New Status in systemd-shim package in Ubuntu: Confirmed Status in systemd source package in Saucy: New Status in systemd-shim source package in Saucy: Won't Fix Status in systemd source package in Trusty: New Status in systemd-shim source package in Trusty: Confirmed Bug description: As per request from bug #1184262, this is a new report, along with dbus (to be attached) ProblemType: Bug DistroRelease: Ubuntu 13.10 Package: systemd-services 204-0ubuntu19 Uname: Linux 3.12.0-custom x86_64 ApportVersion: 2.12.5-0ubuntu2.1 Architecture: amd64 Date: Sun Nov 17 20:24:41 2013 MarkForUpload: True SourcePackage: systemd UpgradeStatus: Upgraded to saucy on 2013-10-17 (31 days ago) SRU INFORMATION: FIX: https://github.com/desrt/systemd-shim/commit/9e1ebe3ab (in trusty already) Regression potential: Low. Flushing the session bus was introduced in version 4 and is obviously bogus as in a system D-BUS service there is no session bus. This causes lots of confusing error messages and unnecessary overhead like trying to start dbus-launch. Flushing the system bus is low-risk, in most cases it's a no-op and it would otherwise prevent losing signals after waking up. No known regressions. TEST CASE: Run several suspend/resume cycles with the lid, session indicator menu, and verify that the network comes back up. It is known that this fix is necessary but not sufficient, so it is not expected to fix all cases. But it should not make things worse, so if network now does not come up any more on a machine where it previously worked this would count as failure/regression. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1252121/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [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 Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1656341 Title: Packaging error (trusty) suspend/resume scripts missing Status in systemd package in Ubuntu: New Bug description: 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. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1656341/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [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 Touch seeded packages, which is subscribed to cups in Ubuntu. https://bugs.launchpad.net/bugs/537970 Title: Evince does not print images in some pdf files. Status in Poppler: Confirmed Status in cups package in Ubuntu: Confirmed Status in poppler package in Ubuntu: Confirmed Bug description: Binary package hint: evince Evince fails to print the image in .pdf file. It shows up correctly in preview, acroread prints it properly. To reproduce: 1) Download this here invoice: http://www.mlink.net.pl/~imachine/faktura_24_2010_12-03-2010.pdf 2) Preview in Evince - company logo is here. 3) Print - company logo is not on paper. Frustrating, used to work, just stopped at some point, too far back in time now to find out tho :/ Cheers! ProblemType: Bug Architecture: amd64 Date: Fri Mar 12 10:58:00 2010 DistroRelease: Ubuntu 10.04 ExecutablePath: /usr/bin/evince NonfreeKernelModules: nvidia Package: evince 2.29.91-0ubuntu2 ProcEnviron: SHELL=/bin/bash LANG=pl_PL.utf8 LANGUAGE=pl_PL:pl:en_GB:en ProcVersionSignature: Ubuntu 2.6.32-16.25-generic SourcePackage: evince Uname: Linux 2.6.32-16-generic x86_64 To manage notifications about this bug go to: https://bugs.launchpad.net/poppler/+bug/537970/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [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 Touch seeded packages, which is subscribed to cups in Ubuntu. https://bugs.launchpad.net/bugs/537970 Title: Evince does not print images in some pdf files. Status in Poppler: Confirmed Status in cups package in Ubuntu: Confirmed Status in poppler package in Ubuntu: Confirmed Bug description: Binary package hint: evince Evince fails to print the image in .pdf file. It shows up correctly in preview, acroread prints it properly. To reproduce: 1) Download this here invoice: http://www.mlink.net.pl/~imachine/faktura_24_2010_12-03-2010.pdf 2) Preview in Evince - company logo is here. 3) Print - company logo is not on paper. Frustrating, used to work, just stopped at some point, too far back in time now to find out tho :/ Cheers! ProblemType: Bug Architecture: amd64 Date: Fri Mar 12 10:58:00 2010 DistroRelease: Ubuntu 10.04 ExecutablePath: /usr/bin/evince NonfreeKernelModules: nvidia Package: evince 2.29.91-0ubuntu2 ProcEnviron: SHELL=/bin/bash LANG=pl_PL.utf8 LANGUAGE=pl_PL:pl:en_GB:en ProcVersionSignature: Ubuntu 2.6.32-16.25-generic SourcePackage: evince Uname: Linux 2.6.32-16-generic x86_64 To manage notifications about this bug go to: https://bugs.launchpad.net/poppler/+bug/537970/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 304393] Re: cups: 127.0.0.1:631 - Address already in use.
Re: #32 Cups and other processes expect to be able to assign their configured ports, But rpcbind / portmap etc. assign ports randomly. e.g.: http://www.linuxproblem.org/art_13.html This bug has just hit me, with a deadline to print and no way to reboot the computer without losing work. It took a lot of debugging before I stumbled upon the article above, and I've been using linux since it came on two floppies. The problem has been noted in redhat, suse, even BSD. I propose a solution: rpcbind should NOT assign random ports, it should assign random *unallocated* ports (i.e. it should make a list of things listed in /etc/services and avoid those ports.) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to cups in Ubuntu. https://bugs.launchpad.net/bugs/304393 Title: cups: 127.0.0.1:631 - Address already in use. Status in cups package in Ubuntu: Confirmed Status in rpcbind package in Ubuntu: New Bug description: Binary package hint: cups cups 1.3.9-2ubuntu4 From /var/log/cups/error_log: cups: unable to bind socket for address 127.0.0.1:631 - Address already in use. Nothing actually looks wrong. 127.0.0.1:631 is only in use by cupsd when started. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/304393/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 304393] Re: cups: 127.0.0.1:631 - Address already in use.
** Also affects: rpcbind (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to cups in Ubuntu. https://bugs.launchpad.net/bugs/304393 Title: cups: 127.0.0.1:631 - Address already in use. Status in cups package in Ubuntu: Confirmed Status in rpcbind package in Ubuntu: New Bug description: Binary package hint: cups cups 1.3.9-2ubuntu4 From /var/log/cups/error_log: cups: unable to bind socket for address 127.0.0.1:631 - Address already in use. Nothing actually looks wrong. 127.0.0.1:631 is only in use by cupsd when started. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/304393/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
