[Bug 1403646] Re: /etc/init.d/autofs confuses upstart
The system where this was observed had stray /etc/rc*.d/*autofs symlinks in place. Not sure why these weren't removed by autofs.postinst on upgrade to trusty, but I've now removed them. I assume this is a sufficient solution to the problem. ** Changed in: autofs (Ubuntu) Status: New => Invalid -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to autofs in Ubuntu. https://bugs.launchpad.net/bugs/1403646 Title: /etc/init.d/autofs confuses upstart To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/autofs/+bug/1403646/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1403646] [NEW] /etc/init.d/autofs confuses upstart
Public bug reported:
autofs 5.0.7-3ubuntu3.1 installs *both* /etc/init/autofs.conf and
/etc/init.d/autofs. (One wonders what this duplication is needed for.)
It is apparently possible for /etc/init.d/autofs start to be run before
Upstart decides to act on /etc/init/autofs.conf. When this happens on my
systems,
1) there is an automount instance running and its PID can be found in
/run/autofs.pid (this is OK);
2) "service autofs status" prints "autofs stop/waiting" and returns exit code 0;
3) my Puppet configuration, which contains a "service { autofs: ensure =>
running }" or equivalent somewhere, causes noisy attempts by Upstart to restart
the autofs service (which fails since the service is already running).
Eventually these result in an "init: autofs respawning too fast, stopped"
message in the logs (until the next puppet run).
About point 2), I'll note that "/etc/init.d/autofs status" correctly
prints " * automount is running". However, the presence of
/etc/init/autofs.conf results in the official tools (/usr/sbin/service,
/usr/sbin/invoke-rc.d) ignoring /etc/init.d/autofs status.
I have a hunch that the solution to this bug will be to remove
/etc/init.d/autofs from the Ubuntu autofs package; is there any good
reason not to do so?
** Affects: autofs (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to autofs in Ubuntu.
https://bugs.launchpad.net/bugs/1403646
Title:
/etc/init.d/autofs confuses upstart
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/autofs/+bug/1403646/+subscriptions
--
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1304377] [NEW] powernapd runaway
Public bug reported: Very occasionally powernapd runs away on me and starts using almost 100% of available CPU cycles. I'm running version 2.17-0ubuntu2 on i386, Ubuntu 12.04.4. The hardware is a Fujitsu Siemens LifeBook S7020 with BIOS version 1.05. The last two entries in /var/log/powernap.log are: 2014-04-08_12:49:54 WARNING Taking action [/usr/sbin/powernap] 2014-04-08_13:54:37 WARNING Taking recover action [/usr/sbin/pm-powersave false] I assume that something goes wrong during the transition away from powersave. Attaching to the running /usr/sbin/powernapd process with gdb yields the following backtrace: #0 0x002b5416 in __kernel_vsyscall () #1 0x00549bd1 in select () at ../sysdeps/unix/syscall-template.S:82 #2 0x080fbdf3 in time_sleep.52928 () #3 0x08137591 in PyEval_EvalFrameEx () #4 0x08137abc in PyEval_EvalFrameEx () #5 0x0813da90 in PyEval_EvalCodeEx () #6 0x0813e361 in run_mod () #7 0x0813e851 in PyRun_FileExFlags () #8 0x08087565 in PyRun_SimpleFileExFlags () #9 0x0808909f in Py_Main () #10 0x0805eabb in main () I'm attaching a few seconds' worth of strace output. My only workaround so far is to run service powernap restart (or equivalent) whenever this happens. Unfortunately I don't know how to reproduce the problem at will. ** Affects: powernap (Ubuntu) Importance: Undecided Status: New ** Attachment added: "powernap.trace" https://bugs.launchpad.net/bugs/1304377/+attachment/4074620/+files/powernap.trace -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to powernap in Ubuntu. https://bugs.launchpad.net/bugs/1304377 Title: powernapd runaway To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/powernap/+bug/1304377/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 980290] Re: In Xen domU, "facter virtual" prints "physical"
*** This bug is a duplicate of bug 980291 *** https://bugs.launchpad.net/bugs/980291 ** This bug has been marked a duplicate of bug 980291 In Xen domU, "facter virtual" prints "physical" -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to facter in Ubuntu. https://bugs.launchpad.net/bugs/980290 Title: In Xen domU, "facter virtual" prints "physical" To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/facter/+bug/980290/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 980291] [NEW] In Xen domU, "facter virtual" prints "physical"
Public bug reported: I've installed precise in virtual machines running on top of the Xen 4.0 hypervisor (with a Debian squeeze dom0). In both i386 machines (running 3.2.0-23-generic-pae #36-Ubuntu) and amd64 machines (with 3.2.0-23-generic #36-Ubuntu), "facter is_virtual" prints out "false" and "facter virtual" prints out "physical". The desired answers are "true" and "xenu", respectively. This is related to upstream issue #2747 but I'm not aware of upstream having found a definitive solution to this problem. I have tested a patch, based on an analysis of the systems I run, and it does the job for me but of course I cannot vouch for its universality. I will be attaching my patch to this bug report. ** Affects: facter (Ubuntu) Importance: Undecided Status: New ** Tags: precise ** Tags added: precise -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to facter in Ubuntu. https://bugs.launchpad.net/bugs/980291 Title: In Xen domU, "facter virtual" prints "physical" To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/facter/+bug/980291/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 980291] Re: In Xen domU, "facter virtual" prints "physical"
** Attachment added: "xen-detection-fix" https://bugs.launchpad.net/ubuntu/+source/facter/+bug/980291/+attachment/3055752/+files/xen-detection-fix -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to facter in Ubuntu. https://bugs.launchpad.net/bugs/980291 Title: In Xen domU, "facter virtual" prints "physical" To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/facter/+bug/980291/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 980290] [NEW] In Xen domU, "facter virtual" prints "physical"
Public bug reported: I've installed precise in virtual machines running on top of the Xen 4.0 hypervisor (with a Debian squeeze dom0). In both i386 machines (running 3.2.0-23-generic-pae #36-Ubuntu) and amd64 machines (with 3.2.0-23-generic #36-Ubuntu), "facter is_virtual" prints out "false" and "facter virtual" prints out "physical". The desired answers are "true" and "xenu", respectively. This is related to upstream issue #2747 but I'm not aware of upstream having found a definitive solution to this problem. I have tested a patch, based on an analysis of the systems I run, and it does the job for me but of course I cannot vouch for its universality. I will be attaching my patch to this bug report. ** Affects: facter (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to facter in Ubuntu. https://bugs.launchpad.net/bugs/980290 Title: In Xen domU, "facter virtual" prints "physical" To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/facter/+bug/980290/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
