This was actually fixed in v14.2.22 [1].
"""
This is the 22nd and likely the last backport release in the Nautilus series.
Ultimately, we recommend all users upgrade to newer Ceph releases.
...
rgw: beast frontend uses 512k mprotected coroutine stacks (pr#39947, Yaakov
Selkowitz, Mauricio Faria
It seems unlikely to be another Nautilus release
as the ceph releases index page [1] shows it EOL
as of 2021-06-01 (~3 weeks ago.)
Thus closing this bug.
https://docs.ceph.com/en/latest/releases/
** Changed in: cloud-archive/train
Status: Confirmed => Invalid
--
You received this bug
Another ceph hotfix release (v14.2.21) has pushed this one release
further, thus at least v14.2.22.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1921749
Title:
nautilus: ceph radosgw beast
Another ceph bugfix release (v14.2.20) has pushed this one release
further, thus at least v14.2.21.
** Description changed:
[Impact]
The radosgw beast frontend in ceph nautilus might hit coroutine stack
corruption on startup and requests.
This is usually observed right at the
** Description changed:
[Impact]
The radosgw beast frontend in ceph nautilus might hit coroutine stack
corruption on startup and requests.
This is usually observed right at the startup of the ceph-radosgw systemd
unit; sometimes 1 minute later.
But it might occur any time
Comments #1- #6: example stack traces and GDB debug snippets of the
issue.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1921749
Title:
nautilus: ceph radosgw beast frontend coroutine stack
coredump #6
RIP address in stack is actually not an instruction address, but a stack
address (corrupted stack).
GDB searched hard for stack unwinding, and got a very long trace, that might
not be correct.
Oct 23 16:41:27 HOSTNAME radosgw[3572]: *** Caught signal (Segmentation
fault)
coredump #5
Oct 23 16:41:01 HOSTNAME radosgw[1616]: tcmalloc: large alloc
94195528343552 bytes == (nil) @ 0x7f97ec494887 0x7f97ec1cb1b2 0x7f97ec1ff948
0x7f97ec1d08be 0x7f97ec1db01e 0x7f97ec1dd433 0x7f97ec1e843d 0x7f97ec1e8680
0x7f97ec1afe3a 0x7f97ec1857ec 0x55ab96ae9dbc 0x55ab967d8a22
coredump #4
Shorter stack trace reported in ceph logs than in GDB.
Oct 23 16:41:28 HOSTNAME radosgw[4319]: *** Caught signal (Segmentation
fault) **
Oct 23 16:41:28 HOSTNAME radosgw[4319]: in thread 7fb79e999700
thread_name:msgr-worker-2
Oct 23 16:41:28 HOSTNAME
coredump #3
(gdb) bt
#0 raise (sig=sig@entry=11) at ../sysdeps/unix/sysv/linux/raise.c:51
#1 0x55bd9a04f6b0 in reraise_fatal (signum=11) at
./src/global/signal_handler.cc:81
#2 handle_fatal_signal (signum=11) at
./src/global/signal_handler.cc:326
coredump #1
(gdb) bt
#0 raise (sig=sig@entry=11) at ../sysdeps/unix/sysv/linux/raise.c:51
#1 0x555f023cf6b0 in reraise_fatal (signum=11) at
./src/global/signal_handler.cc:81
#2 handle_fatal_signal (signum=11) at
./src/global/signal_handler.cc:326
coredump #2
(gdb) bt
#0 raise (sig=sig@entry=11) at ../sysdeps/unix/sysv/linux/raise.c:51
#1 0x557c23db26b0 in reraise_fatal (signum=11) at
./src/global/signal_handler.cc:81
#2 handle_fatal_signal (signum=11) at
./src/global/signal_handler.cc:326
12 matches
Mail list logo
