Re: [Gluster-users] Experiences with FUSE in real world - Presentationat Vault 2019

[Raghavendra Gowdappa]

Unfortunately, there is no recording. However, we are willing to discuss
our findings if you've specific questions. We can do that in this thread.

On Thu, Mar 7, 2019 at 10:33 AM Strahil  wrote:

> Thanks a lot.
> Is there a recording of that ?
>
> Best Regards,
> Strahil Nikolov
> On Mar 5, 2019 11:13, Raghavendra Gowdappa  wrote:
>
> All,
>
> Recently me, Manoj and Csaba presented on positives and negatives of
> implementing File systems in userspace using FUSE [1]. We had based the
> talk on our experiences with Glusterfs having FUSE as the native interface.
> The slides can also be found at [1].
>
> [1] https://www.usenix.org/conference/vault19/presentation/pillai
>
> regards,
> Raghavendra
>
>
___
Gluster-users mailing list
Gluster-users@gluster.org
https://lists.gluster.org/mailman/listinfo/gluster-users

Re: [Gluster-users] Upgrade 5.3 -> 5.4 on debian: public IP is used instead of LAN IP

[Amar Tumballi Suryanarayan]

We are talking days. Not weeks. Considering already it is Thursday here. 1
more day for tagging, and packaging. May be ok to expect it on Monday.

-Amar

On Thu, Mar 7, 2019 at 11:54 AM Artem Russakovskii 
wrote:

> Is the next release going to be an imminent hotfix, i.e. something like
> today/tomorrow, or are we talking weeks?
>
> Sincerely,
> Artem
>
> --
> Founder, Android Police , APK Mirror
> , Illogical Robot LLC
> beerpla.net | +ArtemRussakovskii
>  | @ArtemR
> 
>
>
> On Tue, Mar 5, 2019 at 11:09 AM Artem Russakovskii 
> wrote:
>
>> Ended up downgrading to 5.3 just in case. Peer status and volume status
>> are OK now.
>>
>> zypper install --oldpackage glusterfs-5.3-lp150.100.1
>> Loading repository data...
>> Reading installed packages...
>> Resolving package dependencies...
>>
>> Problem: glusterfs-5.3-lp150.100.1.x86_64 requires libgfapi0 = 5.3, but
>> this requirement cannot be provided
>>   not installable providers: libgfapi0-5.3-lp150.100.1.x86_64[glusterfs]
>>  Solution 1: Following actions will be done:
>>   downgrade of libgfapi0-5.4-lp150.100.1.x86_64 to
>> libgfapi0-5.3-lp150.100.1.x86_64
>>   downgrade of libgfchangelog0-5.4-lp150.100.1.x86_64 to
>> libgfchangelog0-5.3-lp150.100.1.x86_64
>>   downgrade of libgfrpc0-5.4-lp150.100.1.x86_64 to
>> libgfrpc0-5.3-lp150.100.1.x86_64
>>   downgrade of libgfxdr0-5.4-lp150.100.1.x86_64 to
>> libgfxdr0-5.3-lp150.100.1.x86_64
>>   downgrade of libglusterfs0-5.4-lp150.100.1.x86_64 to
>> libglusterfs0-5.3-lp150.100.1.x86_64
>>  Solution 2: do not install glusterfs-5.3-lp150.100.1.x86_64
>>  Solution 3: break glusterfs-5.3-lp150.100.1.x86_64 by ignoring some of
>> its dependencies
>>
>> Choose from above solutions by number or cancel [1/2/3/c] (c): 1
>> Resolving dependencies...
>> Resolving package dependencies...
>>
>> The following 6 packages are going to be downgraded:
>>   glusterfs libgfapi0 libgfchangelog0 libgfrpc0 libgfxdr0 libglusterfs0
>>
>> 6 packages to downgrade.
>>
>> Sincerely,
>> Artem
>>
>> --
>> Founder, Android Police , APK Mirror
>> , Illogical Robot LLC
>> beerpla.net | +ArtemRussakovskii
>>  | @ArtemR
>> 
>>
>>
>> On Tue, Mar 5, 2019 at 10:57 AM Artem Russakovskii 
>> wrote:
>>
>>> Noticed the same when upgrading from 5.3 to 5.4, as mentioned.
>>>
>>> I'm confused though. Is actual replication affected, because the 5.4
>>> server and the 3x 5.3 servers still show heal info as all 4 connected, and
>>> the files seem to be replicating correctly as well.
>>>
>>> So what's actually affected - just the status command, or leaving 5.4 on
>>> one of the nodes is doing some damage to the underlying fs? Is it fixable
>>> by tweaking transport.socket.ssl-enabled? Does upgrading all servers to 5.4
>>> resolve it, or should we revert back to 5.3?
>>>
>>> Sincerely,
>>> Artem
>>>
>>> --
>>> Founder, Android Police , APK Mirror
>>> , Illogical Robot LLC
>>> beerpla.net | +ArtemRussakovskii
>>>  | @ArtemR
>>> 
>>>
>>>
>>> On Tue, Mar 5, 2019 at 2:02 AM Hu Bert  wrote:
>>>
 fyi: did a downgrade 5.4 -> 5.3 and it worked. all replicas are up and
 running. Awaiting updated v5.4.

 thx :-)

 Am Di., 5. März 2019 um 09:26 Uhr schrieb Hari Gowtham <
 hgowt...@redhat.com>:
 >
 > There are plans to revert the patch causing this error and rebuilt
 5.4.
 > This should happen faster. the rebuilt 5.4 should be void of this
 upgrade issue.
 >
 > In the meantime, you can use 5.3 for this cluster.
 > Downgrading to 5.3 will work if it was just one node that was upgrade
 to 5.4
 > and the other nodes are still in 5.3.
 >
 > On Tue, Mar 5, 2019 at 1:07 PM Hu Bert 
 wrote:
 > >
 > > Hi Hari,
 > >
 > > thx for the hint. Do you know when this will be fixed? Is a
 downgrade
 > > 5.4 -> 5.3 a possibility to fix this?
 > >
 > > Hubert
 > >
 > > Am Di., 5. März 2019 um 08:32 Uhr schrieb Hari Gowtham <
 hgowt...@redhat.com>:
 > > >
 > > > Hi,
 > > >
 > > > This is a known issue we are working on.
 > > > As the checksum differs between the updated and non updated node,
 the
 > > > peers are getting rejected.
 > > > The bricks aren't coming because of the same issue.
 > > >
 > > > More about the issue:
 https://bugzilla.redhat.com/show_bug.cgi?id=1685120
 > > >
 > > > On Tue, Mar 5, 2019 at 12:56 PM Hu Bert 
 wrote:
 > > > >
 > > > > Interestingly: gluster volume status misses gluster1, while heal
 > > > > statistics show gluster1:
 > > > >
 > > > > gluster volume status workdata
 > > > > Status

Re: [Gluster-users] Upgrade 5.3 -> 5.4 on debian: public IP is used instead of LAN IP

[Artem Russakovskii]

Is the next release going to be an imminent hotfix, i.e. something like
today/tomorrow, or are we talking weeks?

Sincerely,
Artem

--
Founder, Android Police , APK Mirror
, Illogical Robot LLC
beerpla.net | +ArtemRussakovskii
 | @ArtemR



On Tue, Mar 5, 2019 at 11:09 AM Artem Russakovskii 
wrote:

> Ended up downgrading to 5.3 just in case. Peer status and volume status
> are OK now.
>
> zypper install --oldpackage glusterfs-5.3-lp150.100.1
> Loading repository data...
> Reading installed packages...
> Resolving package dependencies...
>
> Problem: glusterfs-5.3-lp150.100.1.x86_64 requires libgfapi0 = 5.3, but
> this requirement cannot be provided
>   not installable providers: libgfapi0-5.3-lp150.100.1.x86_64[glusterfs]
>  Solution 1: Following actions will be done:
>   downgrade of libgfapi0-5.4-lp150.100.1.x86_64 to
> libgfapi0-5.3-lp150.100.1.x86_64
>   downgrade of libgfchangelog0-5.4-lp150.100.1.x86_64 to
> libgfchangelog0-5.3-lp150.100.1.x86_64
>   downgrade of libgfrpc0-5.4-lp150.100.1.x86_64 to
> libgfrpc0-5.3-lp150.100.1.x86_64
>   downgrade of libgfxdr0-5.4-lp150.100.1.x86_64 to
> libgfxdr0-5.3-lp150.100.1.x86_64
>   downgrade of libglusterfs0-5.4-lp150.100.1.x86_64 to
> libglusterfs0-5.3-lp150.100.1.x86_64
>  Solution 2: do not install glusterfs-5.3-lp150.100.1.x86_64
>  Solution 3: break glusterfs-5.3-lp150.100.1.x86_64 by ignoring some of
> its dependencies
>
> Choose from above solutions by number or cancel [1/2/3/c] (c): 1
> Resolving dependencies...
> Resolving package dependencies...
>
> The following 6 packages are going to be downgraded:
>   glusterfs libgfapi0 libgfchangelog0 libgfrpc0 libgfxdr0 libglusterfs0
>
> 6 packages to downgrade.
>
> Sincerely,
> Artem
>
> --
> Founder, Android Police , APK Mirror
> , Illogical Robot LLC
> beerpla.net | +ArtemRussakovskii
>  | @ArtemR
> 
>
>
> On Tue, Mar 5, 2019 at 10:57 AM Artem Russakovskii 
> wrote:
>
>> Noticed the same when upgrading from 5.3 to 5.4, as mentioned.
>>
>> I'm confused though. Is actual replication affected, because the 5.4
>> server and the 3x 5.3 servers still show heal info as all 4 connected, and
>> the files seem to be replicating correctly as well.
>>
>> So what's actually affected - just the status command, or leaving 5.4 on
>> one of the nodes is doing some damage to the underlying fs? Is it fixable
>> by tweaking transport.socket.ssl-enabled? Does upgrading all servers to 5.4
>> resolve it, or should we revert back to 5.3?
>>
>> Sincerely,
>> Artem
>>
>> --
>> Founder, Android Police , APK Mirror
>> , Illogical Robot LLC
>> beerpla.net | +ArtemRussakovskii
>>  | @ArtemR
>> 
>>
>>
>> On Tue, Mar 5, 2019 at 2:02 AM Hu Bert  wrote:
>>
>>> fyi: did a downgrade 5.4 -> 5.3 and it worked. all replicas are up and
>>> running. Awaiting updated v5.4.
>>>
>>> thx :-)
>>>
>>> Am Di., 5. März 2019 um 09:26 Uhr schrieb Hari Gowtham <
>>> hgowt...@redhat.com>:
>>> >
>>> > There are plans to revert the patch causing this error and rebuilt 5.4.
>>> > This should happen faster. the rebuilt 5.4 should be void of this
>>> upgrade issue.
>>> >
>>> > In the meantime, you can use 5.3 for this cluster.
>>> > Downgrading to 5.3 will work if it was just one node that was upgrade
>>> to 5.4
>>> > and the other nodes are still in 5.3.
>>> >
>>> > On Tue, Mar 5, 2019 at 1:07 PM Hu Bert  wrote:
>>> > >
>>> > > Hi Hari,
>>> > >
>>> > > thx for the hint. Do you know when this will be fixed? Is a downgrade
>>> > > 5.4 -> 5.3 a possibility to fix this?
>>> > >
>>> > > Hubert
>>> > >
>>> > > Am Di., 5. März 2019 um 08:32 Uhr schrieb Hari Gowtham <
>>> hgowt...@redhat.com>:
>>> > > >
>>> > > > Hi,
>>> > > >
>>> > > > This is a known issue we are working on.
>>> > > > As the checksum differs between the updated and non updated node,
>>> the
>>> > > > peers are getting rejected.
>>> > > > The bricks aren't coming because of the same issue.
>>> > > >
>>> > > > More about the issue:
>>> https://bugzilla.redhat.com/show_bug.cgi?id=1685120
>>> > > >
>>> > > > On Tue, Mar 5, 2019 at 12:56 PM Hu Bert 
>>> wrote:
>>> > > > >
>>> > > > > Interestingly: gluster volume status misses gluster1, while heal
>>> > > > > statistics show gluster1:
>>> > > > >
>>> > > > > gluster volume status workdata
>>> > > > > Status of volume: workdata
>>> > > > > Gluster process TCP Port  RDMA Port
>>> Online  Pid
>>> > > > >
>>> --
>>> > > > > Brick gluster2:/gluster/md4/workdata49153 0
>>> Y   1723
>>> > > > > Brick gluster3:/gluster/md4/workdata49153 0
>>> Y   2068
>

Re: [Gluster-users] Gluster : Improvements on "heal info" command

[Ashish Pandey]

No, it is not necessary that the first brick would be local one. 

I really don't think starting from local node will make a difference. 
The major time spent is not in getting list of entries from 
.gluster/indices/xattrop folder. 
The LOCK->XATTR_CHECK->UNLOCK is the cycle which takes most of the time which 
is not going to change even if it is from local brick. 

--- 
Ashish 


- Original Message -

From: "Strahil"  
To: "Ashish" , "Gluster" , 
"Gluster"  
Sent: Wednesday, March 6, 2019 10:21:26 PM 
Subject: Re: [Gluster-users] Gluster : Improvements on "heal info" command 



Hi , 

This sounds nice. I would like to ask if the order is starting from the local 
node's bricks first ? (I am talking about --brick=one) 

Best Regards, 
Strahil Nikolov 
On Mar 5, 2019 10:51, Ashish Pandey  wrote: 



Hi All, 

We have observed and heard from gluster users about the long time "heal info" 
command takes. 
Even when we all want to know if a gluster volume is healthy or not, it takes 
time to list down all the files from all the bricks after which we can be 
sure if the volume is healthy or not. 
Here, we have come up with some options for "heal info" command which provide 
report quickly and reliably. 

gluster v heal vol info --subvol=[number of the subvol] --brick=[one,all] 
 

Problem: "gluster v heal  info" command picks each subvolume and 
checks the .glusterfs/indices/xattrop folder of every brick of that subvolume 
to find out if there is any entry 
which needs to be healed. It picks the entry and takes a lock on that entry to 
check xattrs to find out if that entry actually needs heal or not. 
This LOCK->CHECK-XATTR->UNLOCK cycle takes lot of time for each file. 

Let's consider two most often seen cases for which we use "heal info" and try 
to understand the improvements. 

Case -1 : Consider 4+2 EC volume and all the bricks on 6 different nodes. 
A brick of the volume is down and client has written 1 files on one of the 
mount point of this volume. Entries for these 10K files will be created on 
".glusterfs/indices/xattrop" 
on all the rest of 5 bricks. Now, brick is UP and when we use "heal info" 
command for this volume, it goes to all the bricks and picks these 10K file 
entries and 
goes through LOCK->CHECK-XATTR->UNLOCK cycle for all the files. This happens 
for all the bricks, that means, we check 50K files and perform the 
LOCK->CHECK-XATTR->UNLOCK cycle 50K times, 
while only 10K entries were sufficient to check. It is a very time consuming 
operation. If IO"s are happening one some of the new files, we check these 
files also which will add the time. 
Here, all we wanted to know if our volume has been healed and healthy. 

Solution : Whenever a brick goes down and comes up and when we use "heal info" 
command, our *main intention* is to find out if the volume is *healthy* or 
*unhealthy*. A volume is unhealthy even if one 
file is not healthy. So, we should scan bricks one by one and as soon as we 
find that one brick is having some entries which require to be healed, we can 
come out and list the files and say the volume is not 
healthy. No need to scan rest of the bricks. That's where "--brick=[one,all]" 
option has been introduced. 

"gluster v heal vol info --brick=[one,all]" 
"one" - It will scan the brick sequentially and as soon as it will find any 
unhealthy entries, it will list it out and stop scanning other bricks. 
"all" - It will act just like current behavior and provide all the files from 
all the bricks. If we do not provide this option, default (current) behavior 
will be applicable. 

Case -2 : Consider 24 X (4+2) EC volume. Let's say one brick from *only one* of 
the sub volume has been replaced and a heal has been triggered. 
To know if the volume is in healthy state, we go to each brick of *each and 
every sub volume* and check if there are any entries in 
".glusterfs/indices/xattrop" folder which need heal or not. 
If we know which sub volume participated in brick replacement, we just need to 
check health of that sub volume and not query/check other sub volumes. 

If several clients are writing number of files on this volume, an entry for 
each of these files will be created in .glusterfs/indices/xattrop and "heal 
info' 
command will go through LOCK->CHECK-XATTR->UNLOCK cycle to find out if these 
entries need heal or not which takes lot of time. 
In addition to this a client will also see performance drop as it will have to 
release and take lock again. 


Solution: Provide an option to mention number of sub volume for which we want 
to check heal info. 

"gluster v heal vol info --subvol= " 
Here, --subvol will be given number of the subvolume we want to check. 
Example: 
"gluster v heal vol info --subvol=1 " 


=== 
Performance Data - 
A quick performance test done on standalone system. 

Type: Distributed-Disperse 
Volume ID: ea40eb13-d42c-431c-9c89-0153e834e67e 
Status: Started 
Snapshot Count: 0 
Number of Brick

Re: [Gluster-users] Not able to start glusterd

[RAFI KC]

Hi Abhishek,

Good to know that you have resolved your problem. Do you think any more 
information is required to add in the upgrade doc for a smooth upgrade 
flow. It would be great to see a PR to the repo 
https://github.com/gluster/glusterdocs/tree/master/docs/Upgrade-Guide 
for updating the doc with the information.



Regards

Rafi KC

On 3/6/19 2:03 PM, ABHISHEK PALIWAL wrote:

Hi Sanju,

Thanks for the response.

I have resolved the issue, actually I have updated from 3.7.6 to 5.0, 
in new version RPC is coming from libtirpb , but I forgot to enable 
"--with-libtirpc" in configuration.


After enabling able to start glusterd.

Regards,
Abhishek

On Wed, Mar 6, 2019 at 12:58 PM Sanju Rakonde > wrote:


Abhishek,

We need below information on investigate this issue.
1. gluster --version
2. Please run glusterd in gdb, so that we can capture the
backtrace. I see some rpc errors in log, but backtrace will be
more helpful.
    To run glusterd in gdb, you need start glusterd in gdb (i.e.
gdb glusterd, and then give the command "run -N"). when you see a
segmentation           fault, please capture the backtrace and
paste it here.

On Wed, Mar 6, 2019 at 10:07 AM ABHISHEK PALIWAL
mailto:abhishpali...@gmail.com>> wrote:

Hi Team,

I am facing the issue where at the time of starting the
glusterd segmentation fault is reported.

Below are the logs

root@128:/usr/sbin# ./glusterd  --debug
[1970-01-01 15:19:43.940386] I [MSGID: 100030]
[glusterfsd.c:2691:main] 0-./glusterd: Started running
./glusterd version 5.0 (args: ./glusterd --debug)
[1970-01-01 15:19:43.940855] D
[logging.c:1833:__gf_log_inject_timer_event] 0-logging-infra:
Starting timer now. Timeout = 120, current buf size = 5
[1970-01-01 15:19:43.941736] D [MSGID: 0]
[glusterfsd.c:747:get_volfp] 0-glusterfsd: loading volume file
/etc/glusterfs/glusterd.vol
[1970-01-01 15:19:43.945796] D [MSGID: 101097]
[xlator.c:341:xlator_dynload_newway] 0-xlator:
dlsym(xlator_api) on
/usr/lib64/glusterfs/5.0/xlator/mgmt/glusterd.so: undefined
symbol: xlator_api. Fall back to old symbols
[1970-01-01 15:19:43.946279] I [MSGID: 106478]
[glusterd.c:1435:init] 0-management: Maximum allowed open file
descriptors set to 65536
[1970-01-01 15:19:43.946419] I [MSGID: 106479]
[glusterd.c:1491:init] 0-management: Using /var/lib/glusterd
as working directory
[1970-01-01 15:19:43.946515] I [MSGID: 106479]
[glusterd.c:1497:init] 0-management: Using /var/run/gluster as
pid file working directory
[1970-01-01 15:19:43.946968] D [MSGID: 0]
[glusterd.c:458:glusterd_rpcsvc_options_build] 0-glusterd:
listen-backlog value: 10
[1970-01-01 15:19:43.947139] D [rpcsvc.c:2607:rpcsvc_init]
0-rpc-service: RPC service inited.
[1970-01-01 15:19:43.947241] D
[rpcsvc.c:2146:rpcsvc_program_register] 0-rpc-service: New
program registered: GF-DUMP, Num: 123451501, Ver: 1, Port: 0
[1970-01-01 15:19:43.947379] D
[rpc-transport.c:269:rpc_transport_load] 0-rpc-transport:
attempt to load file
/usr/lib64/glusterfs/5.0/rpc-transport/socket.so
[1970-01-01 15:19:43.955198] D [socket.c:4464:socket_init]
0-socket.management: Configued transport.tcp-user-timeout=0
[1970-01-01 15:19:43.955316] D [socket.c:4482:socket_init]
0-socket.management: Reconfigued transport.keepalivecnt=9
[1970-01-01 15:19:43.955415] D
[socket.c:4167:ssl_setup_connection_params]
0-socket.management: SSL support on the I/O path is NOT enabled
[1970-01-01 15:19:43.955504] D
[socket.c:4170:ssl_setup_connection_params]
0-socket.management: SSL support for glusterd is NOT enabled
[1970-01-01 15:19:43.955612] D
[name.c:572:server_fill_address_family] 0-socket.management:
option address-family not specified, defaulting to inet6
[1970-01-01 15:19:43.955928] D
[rpc-transport.c:269:rpc_transport_load] 0-rpc-transport:
attempt to load file
/usr/lib64/glusterfs/5.0/rpc-transport/rdma.so
[1970-01-01 15:19:43.956079] E
[rpc-transport.c:273:rpc_transport_load] 0-rpc-transport:
/usr/lib64/glusterfs/5.0/rpc-transport/rdma.so: cannot open
shared object file: No such file or directory
[1970-01-01 15:19:43.956177] W
[rpc-transport.c:277:rpc_transport_load] 0-rpc-transport:
volume 'rdma.management': transport-type 'rdma' is not valid
or not found on this machine
[1970-01-01 15:19:43.956270] W
[rpcsvc.c:1789:rpcsvc_create_listener] 0-rpc-service: cannot
create listener, initing the transport failed
[1970-01-01 15:19:43.956362] E [MSGID: 106244]
   

Re: [Gluster-users] [Gluster-Maintainers] Release 6: Release date update

[Niels de Vos]

On Wed, Mar 06, 2019 at 02:34:37PM +0900, Guillaume Pavese wrote:
> Ready to test, as soon as a build is made.
> I have been keeping refreshing
> https://cbs.centos.org/koji/packageinfo?packageID=5 since the last one
> 6.0-0.1.rc0.el7 built on 22th feb which did not include important patches
> (event handler fails)  merged for 5.4-1 since...

If you are interested in testing packages before they get released, I
recommend to subscribe to the packaging mailinglist. We normally
announce it there when packages are available. For CentOS there is a
centos-release-gluster6 package that provides the yum repository
configuration so that installing/updating is really easy:

  https://lists.gluster.org/pipermail/packaging/2019-February/000702.html

Niels


> I think a RC1 would have been warranted for those patches already while
> waiting for the upgrade bugs to be fixed in a RC2...
> 
> Guillaume Pavese
> Ingénieur Système et Réseau
> Interactiv-Group
> 
> 
> On Wed, Mar 6, 2019 at 3:17 AM Shyam Ranganathan 
> wrote:
> 
> > Hi,
> >
> > Release-6 was to be an early March release, and due to finding bugs
> > while performing upgrade testing, is now expected in the week of 18th
> > March, 2019.
> >
> > RC1 builds are expected this week, to contain the required fixes, next
> > week would be testing our RC1 for release fitness before the release.
> >
> > As always, request that users test the RC builds and report back issues
> > they encounter, to help make the release a better quality.
> >
> > Shyam
> > ___
> > Gluster-users mailing list
> > Gluster-users@gluster.org
> > https://lists.gluster.org/mailman/listinfo/gluster-users
> >

> ___
> maintainers mailing list
> maintain...@gluster.org
> https://lists.gluster.org/mailman/listinfo/maintainers

___
Gluster-users mailing list
Gluster-users@gluster.org
https://lists.gluster.org/mailman/listinfo/gluster-users

Re: [Gluster-users] Not able to start glusterd

[ABHISHEK PALIWAL]

Hi Sanju,

Thanks for the response.

I have resolved the issue, actually I have updated from 3.7.6 to 5.0, in
new version RPC is coming from libtirpb , but I forgot to enable
"--with-libtirpc" in configuration.

After enabling able to start glusterd.

Regards,
Abhishek

On Wed, Mar 6, 2019 at 12:58 PM Sanju Rakonde  wrote:

> Abhishek,
>
> We need below information on investigate this issue.
> 1. gluster --version
> 2. Please run glusterd in gdb, so that we can capture the backtrace. I see
> some rpc errors in log, but backtrace will be more helpful.
> To run glusterd in gdb, you need start glusterd in gdb (i.e. gdb
> glusterd, and then give the command "run -N"). when you see a segmentation
>  fault, please capture the backtrace and paste it here.
>
> On Wed, Mar 6, 2019 at 10:07 AM ABHISHEK PALIWAL 
> wrote:
>
>> Hi Team,
>>
>> I am facing the issue where at the time of starting the glusterd
>> segmentation fault is reported.
>>
>> Below are the logs
>>
>> root@128:/usr/sbin# ./glusterd  --debug
>> [1970-01-01 15:19:43.940386] I [MSGID: 100030] [glusterfsd.c:2691:main]
>> 0-./glusterd: Started running ./glusterd version 5.0 (args: ./glusterd
>> --debug)
>> [1970-01-01 15:19:43.940855] D
>> [logging.c:1833:__gf_log_inject_timer_event] 0-logging-infra: Starting
>> timer now. Timeout = 120, current buf size = 5
>> [1970-01-01 15:19:43.941736] D [MSGID: 0] [glusterfsd.c:747:get_volfp]
>> 0-glusterfsd: loading volume file /etc/glusterfs/glusterd.vol
>> [1970-01-01 15:19:43.945796] D [MSGID: 101097]
>> [xlator.c:341:xlator_dynload_newway] 0-xlator: dlsym(xlator_api) on
>> /usr/lib64/glusterfs/5.0/xlator/mgmt/glusterd.so: undefined symbol:
>> xlator_api. Fall back to old symbols
>> [1970-01-01 15:19:43.946279] I [MSGID: 106478] [glusterd.c:1435:init]
>> 0-management: Maximum allowed open file descriptors set to 65536
>> [1970-01-01 15:19:43.946419] I [MSGID: 106479] [glusterd.c:1491:init]
>> 0-management: Using /var/lib/glusterd as working directory
>> [1970-01-01 15:19:43.946515] I [MSGID: 106479] [glusterd.c:1497:init]
>> 0-management: Using /var/run/gluster as pid file working directory
>> [1970-01-01 15:19:43.946968] D [MSGID: 0]
>> [glusterd.c:458:glusterd_rpcsvc_options_build] 0-glusterd: listen-backlog
>> value: 10
>> [1970-01-01 15:19:43.947139] D [rpcsvc.c:2607:rpcsvc_init] 0-rpc-service:
>> RPC service inited.
>> [1970-01-01 15:19:43.947241] D [rpcsvc.c:2146:rpcsvc_program_register]
>> 0-rpc-service: New program registered: GF-DUMP, Num: 123451501, Ver: 1,
>> Port: 0
>> [1970-01-01 15:19:43.947379] D [rpc-transport.c:269:rpc_transport_load]
>> 0-rpc-transport: attempt to load file
>> /usr/lib64/glusterfs/5.0/rpc-transport/socket.so
>> [1970-01-01 15:19:43.955198] D [socket.c:4464:socket_init]
>> 0-socket.management: Configued transport.tcp-user-timeout=0
>> [1970-01-01 15:19:43.955316] D [socket.c:4482:socket_init]
>> 0-socket.management: Reconfigued transport.keepalivecnt=9
>> [1970-01-01 15:19:43.955415] D
>> [socket.c:4167:ssl_setup_connection_params] 0-socket.management: SSL
>> support on the I/O path is NOT enabled
>> [1970-01-01 15:19:43.955504] D
>> [socket.c:4170:ssl_setup_connection_params] 0-socket.management: SSL
>> support for glusterd is NOT enabled
>> [1970-01-01 15:19:43.955612] D [name.c:572:server_fill_address_family]
>> 0-socket.management: option address-family not specified, defaulting to
>> inet6
>> [1970-01-01 15:19:43.955928] D [rpc-transport.c:269:rpc_transport_load]
>> 0-rpc-transport: attempt to load file
>> /usr/lib64/glusterfs/5.0/rpc-transport/rdma.so
>> [1970-01-01 15:19:43.956079] E [rpc-transport.c:273:rpc_transport_load]
>> 0-rpc-transport: /usr/lib64/glusterfs/5.0/rpc-transport/rdma.so: cannot
>> open shared object file: No such file or directory
>> [1970-01-01 15:19:43.956177] W [rpc-transport.c:277:rpc_transport_load]
>> 0-rpc-transport: volume 'rdma.management': transport-type 'rdma' is not
>> valid or not found on this machine
>> [1970-01-01 15:19:43.956270] W [rpcsvc.c:1789:rpcsvc_create_listener]
>> 0-rpc-service: cannot create listener, initing the transport failed
>> [1970-01-01 15:19:43.956362] E [MSGID: 106244] [glusterd.c:1798:init]
>> 0-management: creation of 1 listeners failed, continuing with succeeded
>> transport
>> [1970-01-01 15:19:43.956459] D [rpcsvc.c:2146:rpcsvc_program_register]
>> 0-rpc-service: New program registered: GlusterD svc peer, Num: 1238437,
>> Ver: 2, Port: 0
>> [1970-01-01 15:19:43.956561] D [rpcsvc.c:2146:rpcsvc_program_register]
>> 0-rpc-service: New program registered: GlusterD svc cli read-only, Num:
>> 1238463, Ver: 2, Port: 0
>> [1970-01-01 15:19:43.95] D [rpcsvc.c:2146:rpcsvc_program_register]
>> 0-rpc-service: New program registered: GlusterD svc mgmt, Num: 1238433,
>> Ver: 2, Port: 0
>> [1970-01-01 15:19:43.956758] D [rpcsvc.c:2146:rpcsvc_program_register]
>> 0-rpc-service: New program registered: GlusterD svc mgmt v3, Num: 1238433,
>> Ver: 3, Port: 0
>> [1970-01-01 15:19:43.956853] D [rpcsvc.c:2146:rpcsvc_