Bug 1676917 - [Ganesha] nfs-ganesha not starting after upgrade, shared_storage got unmount when tried to start nfs-ganesha
Summary: [Ganesha] nfs-ganesha not starting after upgrade, shared_storage got unmount...
Keywords:
Status: CLOSED DUPLICATE of bug 1676904
Alias: None
Product: Red Hat Gluster Storage
Classification: Red Hat Storage
Component: nfs-ganesha
Version: rhgs-3.4
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: ---
: ---
Assignee: Kaleb KEITHLEY
QA Contact: Jilju Joy
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-02-13 15:28 UTC by Jilju Joy
Modified: 2019-09-10 05:04 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-02-14 09:40:55 UTC
Embargoed:


Attachments (Terms of Use)

Comment 4 Daniel Gryniewicz 2019-02-13 17:29:42 UTC
It seems like the local glusterd is crashing, and so Ganesha can't load it's config from the cluster mount.

Comment 5 Jiffin 2019-02-14 05:35:19 UTC
Agreeing to what Dan mentioned, The ganesha.conf is saved in shared_storage which is a fuse mount. Here either glusterd/nfs-ganesha was trying to access the ganesha.conf as part of gluster nfs-ganesha enable command which resulted in the crash. It has similar bt mentioned https://bugzilla.redhat.com/show_bug.cgi?id=1676904
gdb /core.5009
Missing separate debuginfos, use: debuginfo-install glibc-2.17-260.el7_6.3.x86_64 krb5-libs-1.15.1-37.el7_6.x86_64
(gdb) bt
#0  meta_flush (frame=0x7fa3d0009b38, this=0x7fa3d401c7f0, fd=0xfdfdfdfd, xdata=0x0) at meta.c:83
#1  0x00007fa3e146c808 in fuse_flush_resume (state=0x7fa3d0007da0) at fuse-bridge.c:2979
#2  0x00007fa3e1460c65 in fuse_resolve_done (state=<optimized out>) at fuse-resolve.c:663
#3  fuse_resolve_all (state=<optimized out>) at fuse-resolve.c:690
#4  0x00007fa3e1460978 in fuse_resolve (state=0x7fa3d0007da0) at fuse-resolve.c:654
#5  0x00007fa3e1460cae in fuse_resolve_all (state=<optimized out>) at fuse-resolve.c:686
#6  0x00007fa3e145ff93 in fuse_resolve_continue (state=state@entry=0x7fa3d0007da0) at fuse-resolve.c:706
#7  0x00007fa3e14608f6 in fuse_resolve_fd (state=0x7fa3d0007da0) at fuse-resolve.c:566
#8  fuse_resolve (state=0x7fa3d0007da0) at fuse-resolve.c:643
#9  0x00007fa3e1460c8e in fuse_resolve_all (state=<optimized out>) at fuse-resolve.c:679
#10 0x00007fa3e1460cd0 in fuse_resolve_and_resume (state=0x7fa3d0007da0, fn=0x7fa3e146c380 <fuse_flush_resume>) at fuse-resolve.c:718
#11 0x00007fa3e1478a42 in fuse_thread_proc (data=0x5561abeb6040) at fuse-bridge.c:5783
#12 0x00007fa3e8ee9dd5 in start_thread () from /lib64/libpthread.so.0
#13 0x00007fa3e87b1ead in clone () from /lib64/libc.so.6

Hence requesting QA to mark it as duplicate


Note You need to log in before you can comment on or make changes to this bug.