[Bug 1771802] [NEW] enable rc-local.service unit by default
Public bug reported: Every other systemd-infected distribution leaves the rc-local.service unit enabled; this is probably because provisioning systems need to use it to launch first-boot tasks. Ubuntu has been blindly following suit in every other respect and should do the same here also. It's a null op unless the file exists and is executable, so enabling it gives all the benefits for extremely negligible cost. Example reproducable bug: * preseed a new host and an rc.local expected to run on boot * boot and realise rc.local didn't run * realise you can't enable it in the preseed as systemctl is not affecting the target system * curse Lennart (again) and run Devuan instead where things just work as they should ** Affects: systemd (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1771802 Title: enable rc-local.service unit by default To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1771802/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1663066] Re: firefox crashes on every web site
I discovered the root cause; DNS was broken. That being the case, I'd expect a better response from Firefox than to simply segfault its renderer. Chromium was able to pinpoint the problem with a helpful error message. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1663066 Title: firefox crashes on every web site To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1663066/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1663066] [NEW] firefox crashes on every web site
Public bug reported: Ubuntu 14.04.5 LTS, with xenial HWE & apt-get update/upgrade @1486597947 UTC Firefox: 51.0.1+build2-0ubuntu0.14.04.2 Tried both HTTP and HTTPS sites. All cause a crash. Firefox displays "Bad news first: This tab has crashed". Attempting to reload the tab restores the stock "new tab page" instead of attempting to reload the site. I had the apparmor workaround from the bug for the previous package which wasn't tested under apparmor enabled, but disabling it makes no difference. Apparmor doesn't log anything related to firefox in either case. in dmesg: Web Content[2401]: segfault at 18 ip 7f34b9b26cda sp 7ffc28d34810 error 4 in libxul.so[7f34b7ede000+3fad000] Web Content[2450]: segfault at 0 ip 7efd8576b469 sp 7ffc8a42e5e0 error 6 in libxul.so[7efd84553000+3fad000] in .xsession-errors: Assertion failure: ((bool)(__builtin_expect(!!(!NS_FAILED_impl(rv)), 1))) && thread (should successfully create image decoding threads), at /build/firefox-sdnpce/firefox-51.0.1+build2/image/DecodePool.cpp:255 #01: ???[/usr/lib/firefox/libxul.so +0x1228be2] #02: ???[/usr/lib/firefox/libxul.so +0xa79b62] #03: ???[/usr/lib/firefox/libxul.so +0xa7ac53] #04: ???[/usr/lib/firefox/libxul.so +0xa7b28d] #05: ???[/usr/lib/firefox/libxul.so +0xa7c615] #06: ???[/usr/lib/firefox/libxul.so +0xa9aeb4] #07: ???[/usr/lib/firefox/libxul.so +0xa9483d] #08: ???[/usr/lib/firefox/libxul.so +0x11beda9] #09: ???[/usr/lib/firefox/libxul.so +0x11bef10] #10: ???[/usr/lib/firefox/libxul.so +0x1c4b96e] #11: XRE_InitChildProcess[/usr/lib/firefox/libxul.so +0x2408bad] #12: ???[/usr/lib/firefox/plugin-container +0x8a15] #13: __libc_start_main[/lib/x86_64-linux-gnu/libc.so.6 +0x21f45] #14: ???[/usr/lib/firefox/plugin-container +0x84e5] #15: ??? (???:???) [Parent 2326] WARNING: pipe error (48): Connection reset by peer: file /build/firefox-sdnpce/firefox-51.0.1+build2/ipc/chromium/src/chrome/common/ipc_channel_posix.cc, line 323 [Parent 2326] WARNING: pipe error (66): Connection reset by peer: file /build/firefox-sdnpce/firefox-51.0.1+build2/ipc/chromium/src/chrome/common/ipc_channel_posix.cc, line 323 [Parent 2326] WARNING: pipe error (64): Connection reset by peer: file /build/firefox-sdnpce/firefox-51.0.1+build2/ipc/chromium/src/chrome/common/ipc_channel_posix.cc, line 323 [Parent 2326] WARNING: pipe error (65): Connection reset by peer: file /build/firefox-sdnpce/firefox-51.0.1+build2/ipc/chromium/src/chrome/common/ipc_channel_posix.cc, line 323 [Parent 2326] WARNING: pipe error (63): Connection reset by peer: file /build/firefox-sdnpce/firefox-51.0.1+build2/ipc/chromium/src/chrome/common/ipc_channel_posix.cc, line 323 ###!!! [Parent][MessageChannel] Error: (msgtype=0x2E007F,name=PBrowser::Msg_Destroy) Channel error: cannot send/recv ** Affects: firefox (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1663066 Title: firefox crashes on every web site To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1663066/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1473000] [NEW] Child processes not reaped when parent dash terminated
Public bug reported: When dash is used as /bin/sh and is called with -c to execute commands, dash doesn't appear to pass signals to the child process. When the process spawning dash sends dash a SIGTERM for example, it causes those subprocesses to never die, and wrecks havoc on servers as tons of spawned processes get reparented to init and continue to run or get zombied. I've seen this problem mentioned in various guises around the internet (depending on the context of what's spawning dash), and in every case the supplied solution is the same: stop using dash e.g. see http://answers.splunk.com/answers/261159/python-eventgenpy- process-not-killed-when-stopping.html debconf-set-selections dash dash/sh string false dpkg-reconfigure -f noninteractive dash This has always been the case, you can find examples going back to Ubuntu 6.10 which first enabled the use of dash as /bin/sh and exists in at least 14.04 LTS I'd like to think there's a better solution for this misbehaviour in dash than to stop using it altogether! ** Affects: dash (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1473000 Title: Child processes not reaped when parent dash terminated To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dash/+bug/1473000/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 253985] Re: Package Awesome 3.0-rc1 for Intrepid
awesome 3.0 final has been released. It relies on xcb-util 0.3.0. Both can be built from Debian experimental. Pull down the 3 files from the source distribution, and run something like: dpkg-source -x xxx.dsc cd whatever_dir_just_got_made debuild (substituting the right .dsc filename and the right directory the source was extracted to from dpkg-source -x) You can then install the .deb files when it successfully builds. Note you will need to install the -dev packages from xcb-util before you attempt to build awesome 3. -- Package Awesome 3.0-rc1 for Intrepid https://bugs.launchpad.net/bugs/253985 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 19775] Re: Missing hostname in /etc/hosts causes sudo to fail
I got this with a fresh install of 8.04 too, and I've had to help a few people on IRC who have been bitten by it. My solution was as follows: boot into recovery console (the only way to get root now since sudo is broken) edit /etc/hosts and add the shortname - I added it to both the 127.0.0.1 and the 127.0.1.1 lines. At this stage I don't do IPv6 so don't know about that one chmod 0444 /etc/hosts (this is necessary because shortly after rebooting some idiot process will erase the fix unless this file is read-only) -- Missing hostname in /etc/hosts causes sudo to fail https://bugs.launchpad.net/bugs/19775 You received this bug notification because you are a member of Ubuntu Bugs, which is a direct subscriber. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 234111] Re: network-admin fails to correctly edit /etc/hosts, causes sudo to fail
*** This bug is a duplicate of bug 19775 *** https://bugs.launchpad.net/bugs/19775 ** This bug has been marked a duplicate of bug 19775 Missing hostname in /etc/hosts causes sudo to fail -- network-admin fails to correctly edit /etc/hosts, causes sudo to fail https://bugs.launchpad.net/bugs/234111 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
