[Gluster-devel] RPM spec file and starting glusterd in no daemon mode

Raghavendra Talur rtalur at redhat.com
Mon May 4 14:27:23 UTC 2015


On Thursday 30 April 2015 02:28 PM, Kaushal M wrote:
> The log-level is set by default to
> <prefix>/var/log/etc-glusterfs-glusterd.vol.log, even when running in
> `-N` mode. Only when running in `--debug` the log itself is redirected
> to stdout and stderr.
>
> Redirecting the output as Kaleb suggestes is the easiest and least
> intrusive fix here.

Redirecting to /dev/null may hide some of the valid errors, especially
if it is being run as part of yum, say the binary does not exist or permissions
are wrong etc.

I have sent a patch at http://review.gluster.org/#/c/10529/ to fix it in glusterd
as a alternative. If this feels too obtrusive we can go ahead with redirecting
to /dev/null approach.

>
> On Thu, Apr 30, 2015 at 12:54 PM, Raghavendra Talur <rtalur at redhat.com> wrote:
> > On Thursday 30 April 2015 10:03 AM, Atin Mukherjee wrote:
> >>
> >>
> >>
> >> On 04/30/2015 01:04 AM, Niels de Vos wrote:
> >>>
> >>> On Wed, Apr 29, 2015 at 09:14:37PM +0200, Niels de Vos wrote:
> >>>>
> >>>> On Wed, Apr 29, 2015 at 12:30:20PM -0400, Kaleb S. KEITHLEY wrote:
> >>>>>
> >>>>>
> >>>>> Any reason you don't want to run it as: `glusterd --xlator-option
> >>>>> *.upgrade=on -N > /dev/null 2>&1` ?
> >>>>
> >>>>
> >>>> I think it would be nicer to use --log-level=/dev/null instead, or would
> >>>> that not override the -N option?
> >>>
> >>>
> >>> Of course I meant --log-file=/dev/null, but maybe --log-level=CRITICAL
> >>> would do too ;-)
> >>
> >> If this works, I would prefer not to have the changes which Talur
> >> suggested at this point of time.
> >
> >
> > This would not work as these options are applied only in gluster
> > context, we are looking at log messages from other libraries that
> > are loaded.
> >
> > What Kaleb suggested should work.
> >
> >
> >>
> >> ~Atin
> >>>
> >>>
> >>>>
> >>>> Niels
> >>>>
> >>>>>
> >>>>>
> >>>>> On 04/29/2015 11:56 AM, Kaushal M wrote:
> >>>>>>
> >>>>>> If we were to run without `-N`, in daemon mode, yum wouldn't know when
> >>>>>> glusterd actually finished the upgrade process. Yum would consider the
> >>>>>> parent process returning to be the end.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> On Wed, Apr 29, 2015 at 9:17 PM, Raghavendra Talur <rtalur at redhat.com>
> >>>>>> wrote:
> >>>>>>>
> >>>>>>> Hi,
> >>>>>>>
> >>>>>>> As part of the yum upgrade procedure, when glusterfs-server is
> >>>>>>> updated
> >>>>>>> we run glusterd in no daemon mode along with upgrade option with this
> >>>>>>> command.
> >>>>>>>
> >>>>>>> glusterd --xlator-option *.upgrade=on -N
> >>>>>>>
> >>>>>>> This helps us update our vol files with new defaults along with
> >>>>>>> few other things.(say we added a new xlator which we want as
> >>>>>>> default).
> >>>>>>>
> >>>>>>> Starting in no daemon mode has a problem though, we leave our stdout,
> >>>>>>> stdin and stderr open. This can cause messages to be printed on the
> >>>>>>> console from any of the libs that we load.
> >>>>>>>
> >>>>>>> We have seen this problem with librdmacm, it prints out these
> >>>>>>> messages on screen
> >>>>>>>
> >>>>>>> librdmacm: Warning: couldn't read ABI version.
> >>>>>>> librdmacm: Warning: assuming: 4
> >>>>>>> librdmacm: Fatal: unable to get RDMA device list
> >>>>>>>
> >>>>>>> I looked through the code and did not find any real requirement
> >>>>>>> to use no-daemon option(-N). Anyhow, we init logging very early
> >>>>>>> in our process and don't need the stderr open.
> >>>>>>>
> >>>>>>> I am missing something or can we exclude -N from our spec files
> >>>>>>> while performing upgrade?
> >>>>>>>
> >>>>>>>
> >>>>>>> Thanks,
> >>>>>>> Raghavendra Talur
> >>>>>>> _______________________________________________
> >>>>>>> Gluster-devel mailing list
> >>>>>>> Gluster-devel at gluster.org
> >>>>>>> http://www.gluster.org/mailman/listinfo/gluster-devel
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> Gluster-devel mailing list
> >>>>>> Gluster-devel at gluster.org
> >>>>>> http://www.gluster.org/mailman/listinfo/gluster-devel
> >>>>>>
> >>>>>
> >>>>> --
> >>>>>
> >>>>> Kaleb
> >>>>> _______________________________________________
> >>>>> Gluster-devel mailing list
> >>>>> Gluster-devel at gluster.org
> >>>>> http://www.gluster.org/mailman/listinfo/gluster-devel
> >>>
> >>>
> >>>
> >>>
> >>>> _______________________________________________
> >>>> Gluster-devel mailing list
> >>>> Gluster-devel at gluster.org
> >>>> http://www.gluster.org/mailman/listinfo/gluster-devel
> >>>
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> Gluster-devel mailing list
> >>> Gluster-devel at gluster.org
> >>> http://www.gluster.org/mailman/listinfo/gluster-devel
> >>>
> >>
> >
> > _______________________________________________
> > Gluster-devel mailing list
> > Gluster-devel at gluster.org
> > http://www.gluster.org/mailman/listinfo/gluster-devel



More information about the Gluster-devel mailing list