Hi everyone.
It seems like the TGT bug (when stopping, reloading or restarting the
TGT deamon) is solved in Ubuntu Artful (17.10). I did not make tests,
but now TGT uses the upstream init.d script or the TGT systemd config
file (both of them address all of the previous described problems).
The
** Description changed:
Hi,
I've had a problem when using the `grub-probe` binary to probe large LVM
partitions (for example, a 1.5 TB partition).
This problem was discovered/tested in an Ubuntu 12.04.5.
When trying to probe these large LVM partitions, we get erros like:
-
If its a duplicate
(https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1475337), its
already fixed in Ubuntu 14.04 or newer.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1027363
Title:
Maybe related.
http://mx.gw.com/pipermail/file/2013/001244.html
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1646233
Title:
file command incorrectly identifies a gzipped file as being a Minix
And...
** Patch added: "etc_default_jetty.reachable.patch"
https://bugs.launchpad.net/ubuntu/+source/jetty/+bug/1646202/+attachment/4786562/+files/etc_default_jetty.reachable.patch
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Hi,
I discovered another strange and related behavior.
When leaving JETTY_HOST empty, instead of listening on all IPs (0.0.0.0
- IPv4 and IPv6), the server is listening on localhost (IPv4 127.0.0.1).
I run some tests and I discovered that passing an empty jetty.host as
param is different than
I updated the workarounds in this post:
http://stackoverflow.com/a/40893892/2530295.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1508562
Title:
Broken symlinks for JSP support in
** Attachment added: "jsp-2.1-6.0.2.jar"
https://bugs.launchpad.net/ubuntu/+source/jetty/+bug/1508562/+attachment/4785985/+files/jsp-2.1-6.0.2.jar
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Sorry, the last workaround does NOT work. Use the first or the second
one.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1508562
Title:
Broken symlinks for JSP support in libjetty-extra-java
Public bug reported:
In Ubuntu 14.04, the command `file` (1:5.14-2ubuntu3.3) incorrectly
identifies a gzipped file as being a Minix filesystem.
Example:
```
$ file gzip-minix.eml
gzip-minix.eml: Minix filesystem, V3, 43470 zones
$ file -v
file-5.14
magic file from
Public bug reported:
When starting/stopping Jetty via its init script (/etc/init.d/jetty), we
can get strange/wrong/inconsistent information about the host and port
in which Jetty is/was listen.
This occurs in Ubuntu 14.04, but probably occurs in other Ubuntu/Debian
versions since the
The bug is fixed also in Ubuntu 16.04. So, basically, it's only
necessary a backport.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1596032
Title:
jetty init file has bad rotatelogs location
To
In Debian: Fixed in version jetty/6.1.26-3
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1596032
Title:
jetty init file has bad rotatelogs location
To manage notifications about this bug go to:
Reported also here in Debian: https://bugs.debian.org/cgi-
bin/bugreport.cgi?bug=719875
I think this is already fixed in Debian.
I fixed it in my servers the same way: changing /usr/sbin to /usr/bin.
** Bug watch added: Debian Bug tracker #719875
Hi,
I'm having the same problem when trying to run Solr from the `solr-
jetty` package in Trusty.
I discovered that the problem was solved in Debian, and I'm hope the
solution will be backported to Ubuntu 14.04 soon.
However, I'm here to share three **workarounds**.
All of them consist on use
I've tested all the previous three workarounds with Jetty+Solr, and Solr
is working normally.
Maybe the last solution is the better one.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1508562
Title:
Hi,
I'm sorry for don't response these questions in the last months.
However, in the last days, I had some time and I understood better the
situation.
I'll split my post in three parts.
1 - Technical background
1.1 - Lack of documentation
The `wait-for-start` job is not documented. Because
Of course.
I actually only know two examples:
- mounting-glusterfs.conf: The glusterfs-client package uses the command
"wait-for-state WAIT_FOR=static-network-up WAITER=mounting-glusterfs" without
passing "WAIT_STATE=running";
- So, this command doesn't works;
- See:
One question:
The solution made by Mathieu Trudel-Lapierre mathieu...@ubuntu.com
is marked as Fix Released.
However, I can't update my grub package to the released one. The new
version is 2.02~beta2-26ubuntu3, and mine is 2.02~beta2-9ubuntu1.3.
I've tried to get it from the trusty-proposed
I've discovered that the seg-extent_count and vg-extent_size counters
are 64 bits in the upstream.
So, the problem is only in the Ubuntu 12.04 LTS release (I don't know if
it exists in the Ubuntu 14.04 LTS.
So, consider applying this patch in Ubuntu 12.04 or backporting the
64bit counters to
More info:
The output of the problematic LV is:
$ lvs -o seg_size,vg_extent_size --units s --nosuffix \
/dev/data/mail
SSize Ext
4294967296 8192
And if I do not specify the LV (output of all LVs):
$ lvs -o seg_size,vg_extent_size --units s --nosuffix
SSize Ext
1949696 8192
3221225472 8192
Hi Carlos,
Could you check the output of this grub-probe command (with three times
'v'):
/usr/sbin/grub-probe --device-map=/boot/grub/device.map
--target=fs -vvv /boot/grub
If your LVM where /boot is instaled is large, it's possible that its bug
(with a proposed patch) is your same case:
Public bug reported:
Hi,
I've had a problem when using the `grub-probe` binary to probe large LVM
partitions (for example, a 1.5 TB partition).
This problem was discovered/tested in an Ubuntu 12.04.5.
When trying to probe these large LVM partitions, we get erros like:
$ grub-probe -vvv
I also proposed a patch for the upstream code here:
https://savannah.gnu.org/bugs/index.php?45562
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1475337
Title:
grub-probe can't probe large logical
Public bug reported:
**Note:** This bug is already reported at upstream. However, as it
occurs only in Ubuntu, I thought it makes sense to report it here again.
So, if the upstream team do not merge the patch (they are mostly
developers from Red Hat and may prioritize problems that affect RedHat
** Patch added: Patch to the mounting-glusterfs.conf file
https://bugs.launchpad.net/ubuntu/+source/glusterfs/+bug/1465382/+attachment/4415273/+files/mounting-glusterfs.conf.patch
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
I made an error when choosing the package. Please ignore the upstart
package and consider only the glusterfs package.
** Package changed: upstart (Ubuntu) = ubuntu
** No longer affects: ubuntu
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
This is not a bug. It's a feature.
However, it's a desired feature.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/962047
Title:
document wait-for-state
To manage notifications about this bug go
Public bug reported:
In Ubuntu 14.04, the wait-for-state job uses the env vars
WAIT_STATE=started or WAIT_STATE=stopped. if the GOAL env var is set
to 'start' or 'stop'.
However, according to the upstart cookbook, the desired states for a
already started/stopped job are 'start/running' and
It seems that this bug is not more present in Ubuntu 14.04 (exim4-base
version 4.82-3ubuntu2).
However, we've really liked if the Ubuntu Team merged this simple fix in
the Ubuntu 12.04 LTS. It isn't good to be obligated to update the
distribution just because only some fixes are merged in the old
It seems that this bug is not more present in Ubuntu 14.04 (exim4-base
version 4.82-3ubuntu2).
However, we've really liked if the Ubuntu Team merged this simple fix in
the Ubuntu 12.04 LTS. It isn't good to be obligated to update the
distribution just because only some fixes are merged in the old
** Summary changed:
- Gluster mount using volfile-bak fails on boot
+ Gluster mount using backupvolfile-server fails on boot
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1464494
Title:
Gluster
Public bug reported:
Consider that we have a fstab entry that uses both volfile-server and
backupvolfile-server in a Ubuntu 14.04.2 LTS Server:
mygluster:/mydir /var/mydir glusterfs
defaults,nobootwait,nofail,_netdev,backupvolfile-server=mygluster-bak 0
0
If the host mygluster is accessible
** Attachment added: dmesg
https://bugs.launchpad.net/ubuntu/+source/glusterfs/+bug/1464494/+attachment/4413586/+files/dmesg
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1464494
Title:
Gluster
** Attachment added: boot.log
https://bugs.launchpad.net/ubuntu/+source/glusterfs/+bug/1464494/+attachment/4413585/+files/boot.log
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1464494
Title:
** Attachment added: var-lib-glance-images.log
https://bugs.launchpad.net/ubuntu/+source/glusterfs/+bug/1464494/+attachment/4413588/+files/var-lib-glance-images.log
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
** Attachment added: mountall.log
https://bugs.launchpad.net/ubuntu/+source/glusterfs/+bug/1464494/+attachment/4413587/+files/mountall.log
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1464494
I'm attaching a better patch here (file
glusterfs-3.4.2/xlators/mount/fuse/utils/mount.glusterfs.in).
** Patch added: mount.glusterfs.in.patch
https://bugs.launchpad.net/ubuntu/+source/glusterfs/+bug/1464494/+attachment/4413589/+files/mount.glusterfs.in.patch
--
You received this bug
I'm sorry. Consider this patch instead of the previous one.
** Patch added: mount.glusterfs.in.patch
https://bugs.launchpad.net/ubuntu/+source/glusterfs/+bug/1464494/+attachment/4413591/+files/mount.glusterfs.in.patch
--
You received this bug notification because you are a member of Ubuntu
The workaround in post 35 (https://bugs.launchpad.net/ubuntu/+source
/initramfs-tools/+bug/50437/comments/35) works, but there's a more
simple workaround to get the same result:
1) Update your /etc/fstab with your new SWAP partition (or partitions);
2) /var/lib/dpkg/info/initramfs-tools.preinst
At first, the GRUB `insmod` command is idempotent. It is, loading many
times the same module is not a great problem. Moreover, fixing this bug
could increase complexity, and complexity often leads to bugs.
However, some people may thing a smaller generated GRUB config file
easier to debug and
*** This bug is a duplicate of bug 991997 ***
https://bugs.launchpad.net/bugs/991997
** This bug is no longer a duplicate of bug 880240
system doesn't turn off if sudo halt is given
** This bug has been marked a duplicate of bug 991997
Wrong comment in /etc/default/halt: Default
*** This bug is a duplicate of bug 991997 ***
https://bugs.launchpad.net/bugs/991997
** This bug is no longer a duplicate of bug 880240
system doesn't turn off if sudo halt is given
** This bug has been marked a duplicate of bug 991997
Wrong comment in /etc/default/halt: Default
*** This bug is a duplicate of bug 991997 ***
https://bugs.launchpad.net/bugs/991997
** This bug is no longer a duplicate of bug 880240
system doesn't turn off if sudo halt is given
** This bug has been marked a duplicate of bug 991997
Wrong comment in /etc/default/halt: Default
*** This bug is a duplicate of bug 991997 ***
https://bugs.launchpad.net/bugs/991997
** This bug is no longer a duplicate of bug 880240
system doesn't turn off if sudo halt is given
** This bug has been marked a duplicate of bug 991997
Wrong comment in /etc/default/halt: Default
I think the current behavior is correctly, but the comment in
/etc/default/halt sould be updated.
Currently, this file is only used by /sbin/shutdown (or by the
/etc/init.d/halt, that can be called by the /sbin/shutdown depending of
the situation).
Updating the comment may avoid user
*** This bug is a duplicate of bug 991997 ***
https://bugs.launchpad.net/bugs/991997
** This bug is no longer a duplicate of bug 880240
system doesn't turn off if sudo halt is given
** This bug has been marked a duplicate of bug 991997
Wrong comment in /etc/default/halt: Default
*** This bug is a duplicate of bug 991997 ***
https://bugs.launchpad.net/bugs/991997
** This bug is no longer a duplicate of bug 880240
system doesn't turn off if sudo halt is given
** This bug has been marked a duplicate of bug 991997
Wrong comment in /etc/default/halt: Default
*** This bug is a duplicate of bug 991997 ***
https://bugs.launchpad.net/bugs/991997
** This bug is no longer a duplicate of bug 880240
system doesn't turn off if sudo halt is given
** This bug has been marked a duplicate of bug 991997
Wrong comment in /etc/default/halt: Default
*** This bug is a duplicate of bug 991997 ***
https://bugs.launchpad.net/bugs/991997
** This bug is no longer a duplicate of bug 880240
system doesn't turn off if sudo halt is given
** This bug has been marked a duplicate of bug 991997
Wrong comment in /etc/default/halt: Default
*** This bug is a duplicate of bug 991997 ***
https://bugs.launchpad.net/bugs/991997
** This bug is no longer a duplicate of bug 880240
system doesn't turn off if sudo halt is given
** This bug has been marked a duplicate of bug 991997
Wrong comment in /etc/default/halt: Default
*** This bug is a duplicate of bug 991997 ***
https://bugs.launchpad.net/bugs/991997
** This bug is no longer a duplicate of bug 880240
system doesn't turn off if sudo halt is given
** This bug has been marked a duplicate of bug 991997
Wrong comment in /etc/default/halt: Default
*** This bug is a duplicate of bug 991997 ***
https://bugs.launchpad.net/bugs/991997
** This bug is no longer a duplicate of bug 880240
system doesn't turn off if sudo halt is given
** This bug has been marked a duplicate of bug 991997
Wrong comment in /etc/default/halt: Default
*** This bug is a duplicate of bug 991997 ***
https://bugs.launchpad.net/bugs/991997
** This bug is no longer a duplicate of bug 880240
system doesn't turn off if sudo halt is given
** This bug has been marked a duplicate of bug 991997
Wrong comment in /etc/default/halt: Default
*** This bug is a duplicate of bug 991997 ***
https://bugs.launchpad.net/bugs/991997
** This bug is no longer a duplicate of bug 880240
system doesn't turn off if sudo halt is given
** This bug has been marked a duplicate of bug 991997
Wrong comment in /etc/default/halt: Default
*** This bug is a duplicate of bug 991997 ***
https://bugs.launchpad.net/bugs/991997
Hi,
I think the current behavior is correctly, but the comment in
/etc/default/halt sould be updated.
So, I proposed a patch in
https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/991997/comments/6
(a
I confirmed that this bug ocour in Ubuntu 12.04 and 14.04.
The @thorsten-hesemeyer response [#11] is right! The definitive solution
is right and the explanation why adding `createUser $user $Aalgorithm
$apassphrase $Xalgorithm $xpassphrase` entries work is right too.
More info: The Ubuntu team
I confirmed that this bug ocour in Ubuntu 12.04 and 14.04.
The @thorsten-hesemeyer response [#11] is right! The definitive solution
is right and the explanation why adding `createUser $user $Aalgorithm
$apassphrase $Xalgorithm $xpassphrase` entries work is right too.
More info: The Ubuntu team
A similar patch was applyed in the package 3.8.1-1ubuntu2, as showed in:
https://bugs.launchpad.net/ubuntu/+source/ddclient/+bug/980409
However, the last version in Ubuntu 12.04 LTS is 3.8.0-11.4ubuntu1. It
is, the patch was not applyed to all Ubuntu versions.
Maybe the correct solution is apply
Hi.
Although this thread shows the bug was fixed in the package
ddclient@3.8.1-1ubuntu2, the last version in Ubuntu 12.04 LTS actualy is
the 3.8.0-11.4ubuntu1. It is, the patch was not applyed to all supported
Ubuntu versions.
I tested this and a similar patch as posted in the follow link, and
** Changed in: ddclient (Ubuntu)
Status: In Progress = Confirmed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1241612
Title:
'service ddclient stop' doesn't work
To manage notifications
Anders, I tested your patch (adapted and applied to the
`/etc/grub.d/00_header` file), and it worked well.
Thanks for the patch.
If someone don't want to wait for the Debian guys confirm, test and
merge the Anders patch, I'm updating my Github gist with a new patch to
be applied in the
Anders Kaseorg (anders-kaseorg), thanks for the links. Really, it's more
safe not implementing LVM write support instead of accepting a risk.
And about the RAID write support? Are there any considerations about?
Well, I had a different idea (but a complex idea) about the write
support: users
I added more info about this bug here:
http://askubuntu.com/a/498281/197497
To trying to help everybody with the problem solution, I'm copy/past my
answer in the Ask Ubuntu here.
This bug appears when you create the boot partition (or the root
partition, when the boot partition doesn't
In the last comment, I wrote:
However, the best solution would be if Grub implements the
`grub_diskfilter_write` function of the `diskfilter` module.
This is because, with the actual patch, we lost some Grub features in
RAID/LVM Grub instalations: the recordfail feature no more works.
--
You
Nowdays, an other bug (with a better description) is a duplicated entry
(same problem described here):
https://bugs.launchpad.net/ubuntu/+source/ddclient/+bug/1241612
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Now, the entire file...
** Attachment added: ddclient.init.new
https://bugs.launchpad.net/ubuntu/+source/ddclient/+bug/1241612/+attachment/4129372/+files/ddclient.init.new
** Changed in: ddclient (Ubuntu)
Status: Confirmed = In Progress
** Changed in: ddclient (Ubuntu)
Status:
*** This bug is a duplicate of bug 1241612 ***
https://bugs.launchpad.net/bugs/1241612
** This bug has been marked a duplicate of bug 1241612
'service ddclient stop' doesn't work
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
The reason is why the start-stop-daemon (--stop, --start and --status),
when using the --name atribute, search for a program who had the correct
PID file and the correct program name too. However, ddclient, when
running in deamon mode, changes its name each 10 seconds (it starts with
the name
I'm not a frequent commiter in Ubuntu Launchpad. So, I don't know if I
must mark this BUG as 'In Progress' or as 'Fix Commited'.
As my patch was not checked by the Ubuntu ddclient Team, some other
improvements may be necessary in the patch, and I have no permition to
commit to the Ubuntu branch
Hi Serge Hallyn,
I run some new tests and, in short, the problem I found is actually three
problems (maybe this bug should be broke in three).
I will summarize the problems I found:
- Tgtd breaks when it receives a SIGHUP;
- When we send a SIGHUP to tgtd (`reload tgt`), the deamon stops (and
Hi Serge Hallyn,
I run some new tests and, in short, the problem I found is actually three
problems (maybe this bug should be broke in three).
I will summarize the problems I found:
- Tgtd breaks when it receives a SIGHUP;
- When we send a SIGHUP to tgtd (`reload tgt`), the deamon stops (and
I discovered that, although sending a SIGHUG signal to TGT (using the
`reload tgt` command) doesn't works, I can correctly reload TGT using
the following command:
tgt-admin --update ALL
I know upstart has the option to change the signal send to a deamon.
However, if we could change the
Public bug reported:
In the multipath-tools upstream, there is a prioritizer called
weightedpath.
See: http://git.opensvc.com/?p=multipath-
tools/.git;a=blob;f=libmultipath/prioritizers/weightedpath.h;h=509f21565d06d8c10a0f0a79756195a5583125d8;hb=HEAD
This prioritizer exists in some
In the attachment, I implemented a fix for the `restart` and
`stop+start` bug.
It's a poor fix, but it may help.
Unfortunately, I don't found any fix for the reload method, since
upstart (in Ubuntu 12.04) always send a SIGHUP signal to the deamon.
** Attachment added: tgt.override
I discovered that, although sending a SIGHUG signal to TGT (using the
`reload tgt` command) doesn't works, I can correctly reload TGT using
the following command:
tgt-admin --update ALL
I know upstart has the option to change the signal send to a deamon.
However, if we could change the
Public bug reported:
In the multipath-tools upstream, there is a prioritizer called
weightedpath.
See: http://git.opensvc.com/?p=multipath-
tools/.git;a=blob;f=libmultipath/prioritizers/weightedpath.h;h=509f21565d06d8c10a0f0a79756195a5583125d8;hb=HEAD
This prioritizer exists in some
In the attachment, I implemented a fix for the `restart` and
`stop+start` bug.
It's a poor fix, but it may help.
Unfortunately, I don't found any fix for the reload method, since
upstart (in Ubuntu 12.04) always send a SIGHUP signal to the deamon.
** Attachment added: tgt.override
Public bug reported:
Sometime, after run a `reload tgt`, some LUNs aren't correctly added to
the targets.
The error will be reproduced above:
$ tgt-admin --dump
default-driver iscsi
target iqn.2014-03.br.com.2aliancas.storage2:vmware_iscsi_4
backing-store /dev/vg_vmware/vmware_4
I think the problem can be related to this fact: the TGT daemon don't
add a block storage to a LUN if some process was accessing it.
The following command show another operation in which a similar problem
occours:
# All block storage added to the targets
$ tgt-admin --dump | grep -o
Sometimes, the restart operation doesn't works also:
$ tgt-admin --dump
default-driver iscsi
target iqn.2014-03.br.com.2aliancas.storage2:vmware_iscsi_4
backing-store /dev/vg_vmware/vmware_4
initiator-address 192.168.130.0/24
initiator-address 127.0.0.1
/target
target
Public bug reported:
Sometime, after run a `reload tgt`, some LUNs aren't correctly added to
the targets.
The error will be reproduced above:
$ tgt-admin --dump
default-driver iscsi
target iqn.2014-03.br.com.2aliancas.storage2:vmware_iscsi_4
backing-store /dev/vg_vmware/vmware_4
Sometimes, the restart operation doesn't works also:
$ tgt-admin --dump
default-driver iscsi
target iqn.2014-03.br.com.2aliancas.storage2:vmware_iscsi_4
backing-store /dev/vg_vmware/vmware_4
initiator-address 192.168.130.0/24
initiator-address 127.0.0.1
/target
target
I think the problem can be related to this fact: the TGT daemon don't
add a block storage to a LUN if some process was accessing it.
The following command show another operation in which a similar problem
occours:
# All block storage added to the targets
$ tgt-admin --dump | grep -o
I had the same problem. When I read the source-code of the exiqgrep
(exim-base package), I realized a question character was missing, and I
applied the same patch.
I'm using the 4.76-3ubuntu3 version too.
So I was going to report the patch when I discovered that this bug was
fixed in new
I had the same problem. When I read the source-code of the exiqgrep
(exim-base package), I realized a question character was missing, and I
applied the same patch.
I'm using the 4.76-3ubuntu3 version too.
So I was going to report the patch when I discovered that this bug was
fixed in new
** Attachment added: Third coredump
https://bugs.launchpad.net/ubuntu/+source/php5/+bug/1226833/+attachment/3826027/+files/core.60117
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to php5 in Ubuntu.
** Attachment added: Second coredump
https://bugs.launchpad.net/ubuntu/+source/php5/+bug/1226833/+attachment/3826026/+files/core.14792
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to php5 in Ubuntu.
** Attachment added: dmesg output
https://bugs.launchpad.net/ubuntu/+source/php5/+bug/1226833/+attachment/3826012/+files/dmesg
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to php5 in Ubuntu.
https://bugs.launchpad.net/bugs/1226833
** Attachment added: Apport file
https://bugs.launchpad.net/ubuntu/+source/php5/+bug/1226833/+attachment/3826013/+files/_usr_sbin_php5-fpm.33.crash
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to php5 in Ubuntu.
Public bug reported:
When the server is with a big load and, mainly, using a lot of memory
(and swapping), the php5-fpm process crashs with a SIGFAULT signal.
The service works again when I do a `service php5-fpm restart` command.
The problem occours a few times (everytime, the server was with
** Attachment added: Third coredump
https://bugs.launchpad.net/ubuntu/+source/php5/+bug/1226833/+attachment/3826027/+files/core.60117
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1226833
Title:
** Attachment added: Second coredump
https://bugs.launchpad.net/ubuntu/+source/php5/+bug/1226833/+attachment/3826026/+files/core.14792
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1226833
Title:
Public bug reported:
When the server is with a big load and, mainly, using a lot of memory
(and swapping), the php5-fpm process crashs with a SIGFAULT signal.
The service works again when I do a `service php5-fpm restart` command.
The problem occours a few times (everytime, the server was with
** Attachment added: Apport file
https://bugs.launchpad.net/ubuntu/+source/php5/+bug/1226833/+attachment/3826013/+files/_usr_sbin_php5-fpm.33.crash
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
** Attachment added: dmesg output
https://bugs.launchpad.net/ubuntu/+source/php5/+bug/1226833/+attachment/3826012/+files/dmesg
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1226833
Title:
zend
96 matches
Mail list logo
