Public bug reported:
The currently shipped systemd unit file causes varnishlog to exit when
SIGHUP is sent to it.
SIGHUP has two meanings for varnishlog:
1) when running in daemon mode: reopen logfile
2) when not running in daemon mode: exit
Since the current systemd unit file doesn't run
What would it take to get this update going?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1547702
Title:
iputils-ping does not support IPv6 in ping command
To manage notifications about this bug
This decision has some REALLY annoying side effects on Trusty, which
took us quite some time to figure out.
With the commented reload stanza, the reload function is broken in a
horrible way:
It sends SIGHUP to the php5-fpm master process causing it to terminate!
Without any warning or indication
This decision has some REALLY annoying side effects on Trusty, which
took us quite some time to figure out.
With the commented reload stanza, the reload function is broken in a
horrible way:
It sends SIGHUP to the php5-fpm master process causing it to terminate!
Without any warning or indication
I can confirm that removing libapache2-mod-perl2 fixes this. Question
remains: why does libapache2-mod-perl2 break it in the first place?
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to apache2 in Ubuntu.
I can confirm that removing libapache2-mod-perl2 fixes this. Question
remains: why does libapache2-mod-perl2 break it in the first place?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1008385
Title:
Just did an interesting find:
When starting Apache using the usual apache2ctl start, the process name is
mangled.
When starting Apache using the not-so-usual . /etc/apache2/envvars apache2
-k start, the process name isn't mangled.
Investigation continues...
--
You received this bug
Turns out apache2 doesn't strip off the path properly:
/usr/sbin/apache2 -k start yields /usr/sbin/apach
apache2 -k start yields apache2
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to apache2 in Ubuntu.
Unfortunately this isn't part of the actual solution. On good servers,
invoking it through /usr/sbin/apache2 works fine as well.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to apache2 in Ubuntu.
https://bugs.launchpad.net/bugs/1008385
Just did an interesting find:
When starting Apache using the usual apache2ctl start, the process name is
mangled.
When starting Apache using the not-so-usual . /etc/apache2/envvars apache2
-k start, the process name isn't mangled.
Investigation continues...
--
You received this bug
Turns out apache2 doesn't strip off the path properly:
/usr/sbin/apache2 -k start yields /usr/sbin/apach
apache2 -k start yields apache2
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1008385
Title:
Unfortunately this isn't part of the actual solution. On good servers,
invoking it through /usr/sbin/apache2 works fine as well.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1008385
Title:
Really curious as to what could be used as a fix or workaround.
Currently it's breaking the New Relic agent on quite a few of our
servers (it fails to detect the Apache2 processes properly).
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed
Really curious as to what could be used as a fix or workaround.
Currently it's breaking the New Relic agent on quite a few of our
servers (it fails to detect the Apache2 processes properly).
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
Here's my revised patch. As there was still some stuff not working
properly.
** Attachment added: fix-gethostinfo-v2
https://bugs.launchpad.net/ubuntu/+source/resource-agents/+bug/985198/+attachment/3432065/+files/fix-gethostinfo-v2
--
You received this bug notification because you are a
Patch appears to work for me as well. Any plans to release an update
yet?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/985198
Title:
Ldirectord Subroutine main::pack_sockaddr_in6 redefined
To
Public bug reported:
Fresh install of Ubuntu Server 12.04. 2 mdadm volumes, one for /boot and
one for LVM for the rest of the system. At each boot this error shows
up:
The disk drive for /boot is not yet ready or not present
If I choose manual recovery, I can do mount /boot exit and the
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1020914
Title:
The disk drive for /boot is not yet ready or not present
To manage notifications about this bug go to:
On Thursday 15 October 2009 at 19:06 (CET), Chuck Short wrote:
1. Is this reproducible?
Yes.
2. If so, what specific steps should we take to recreate this bug? Be as
detailed as possible. This will help us to find and resolve the problem.
As described in the bugreport itself:
$ sudo crontab
On Thursday 15 October 2009 at 19:06 (CET), Chuck Short wrote:
1. Is this reproducible?
Yes.
2. If so, what specific steps should we take to recreate this bug? Be as
detailed as possible. This will help us to find and resolve the problem.
As described in the bugreport itself:
$ sudo crontab
Public bug reported:
Binary package hint: ipvsadm
As /sbin/ipvsadm is a wrapper script for 2 versions of ipvsadm and isn't
using full paths to those executables, running /sbin/ipvsadm when /sbin
is not part of $PATH, the script will fail. (Root) Cronjobs by default
don't appear to have /sbin in
Public bug reported:
Binary package hint: installation-report
Example:
# ls /var/log/installer/initial-status.gz -l
-rw-r--r-- 1 root root 0 2009-03-02 12:02 /var/log/installer/initial-status.gz
I get similar results on Hardy and Intrepid, i386 and amd64.
** Affects: installation-report
I have another works-for-me (tm) solution (other than adding vmxnet to
initrd):
Modify /etc/init.d/open-vm-tools:
--- /etc/init.d/open-vm-tools.orig 2009-01-19 10:57:02.0 +0100
+++ /etc/init.d/open-vm-tools 2009-01-19 10:51:49.0 +0100
@@ -67,6 +67,7 @@
then
Travis,
I think it was as simple as adding vmxnet (on a single line) to the
file /etc/initramfs-tools/modules and rebuild your initrd (using: sudo
update-initramfs -u). Followed by a reboot ofcourse.
This is what I recall from what I did (I had same other projects take up
my time in the mean
The above mentioned fix/workaround didn't work for me for some reason.
Adding vmxnet to the list modules to be included in the initrd did
work for me though.
--
network interface does not come up after installing open-vm-tools
https://bugs.launchpad.net/bugs/289921
You received this bug
Works for me as well (ESXi 3.5 host).
--
open-vm-source doesn't build
https://bugs.launchpad.net/bugs/278711
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
Public bug reported:
10:50 _ruben another annoying thing btw (havent checked if there's a bug for
it already) .. say you create a /dev/md0 for /boot and a /dev/md1 for lvm ..
format /dev/md0 as ext2 and assign to /boot .. then go setup your lvm .. the
reference to /boot will be gone
Mohamed,
The current workaround is to use sudo apt-get install lamp-server^
instead of using tasksel. It also *seems* to be safe to just kill the
processes that tasksel has hanging around, since when doing so
everything *looks* being installed just ok. I ran a sudo apt-get
install lamp-server^ to
Excerpt from ps uaxfww :
ruben 4576 0.0 0.1 20692 3640 pts/0Ss 20:13 0:00 | \_
-bash
root 4796 0.1 0.4 36460 12568 pts/0S+ 20:13 0:00 |
\_ /usr/bin/perl /usr/bin/tasksel
root 4816 0.0 0.3 47924 10772 pts/0S+ 20:13 0:00 |
Same issue here. Installing any task (tried SSH/LAMP/Samba) causes
tasksel to hang at 100%. I don't recall the details but it involves a
process ending up in the Zombie state. Killing procs works, but is a
nasty workaround.
This is on a fresh-feisty-with-all-updates-upgraded-to-gutsy. As in: I
*** This bug is a duplicate of bug 149319 ***
https://bugs.launchpad.net/bugs/149319
I had a hunch it would be related; I created this extra bug just to be
sure in case there wouldn't be an unilateral fix. Good job on the quick
fix!
--
Having /var/log as a seperate partition breaks udev and
Public bug reported:
After a clean install of Ubuntu Gutsy Gibbon on a Dell PowerEdge860, the
network configuration is more or less messed up.
During installation there's an eth0 and eth1 interface (two broadcom nics, tg3
driver), which are configured fine. Yet after first reboot the devices
** Changed in: udev (Ubuntu)
Sourcepackagename: None = udev
--
network interfaces not properly configured
https://bugs.launchpad.net/bugs/149319
You received this bug notification because you are a member of Ubuntu
Bugs, which is the bug contact for Ubuntu.
--
ubuntu-bugs mailing list
After some troubleshooting with help from soren and ivoks on IRC, we
found out that a restart of udev (sudo /etc/init.d/udev stop sudo
/etc/init.d/udev start) in fact does populate the file
/etc/udev/rules.d/70-persistent-net.rules properly.
Also in order to have the file properly generated when
Public bug reported:
Binary package hint: udev
I have /var/log as a separate partition on top of lvm on top software raid. At
the time udev starts, /var/log isn't available yet. This causes the problem
that it can't move the logfile to /var/log/udev.log.
Furthermore, /var/log/boot shows
Some more information that might be related to this issue: /var/log
resides on a separate partition (lvm volume on software raid) which
causes some errors during boot. It complains about a command similar to
'mv /dev/.udev.log /var/log/udev.log'. This fails because /var/log isn't
available at that
36 matches
Mail list logo
