[Gluster-devel] RPM spec file and starting glusterd in no daemon mode
Raghavendra Talur
rtalur at redhat.com
Mon May 4 15:20:36 UTC 2015
On May 4, 2015 20:17, Niels de Vos <ndevos at redhat.com> wrote:
>
> On Mon, May 04, 2015 at 07:57:23PM +0530, Raghavendra Talur wrote:
> > 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.
>
> I think that is a nice solution, but there is still the need for writing
> the log to the log-file and not to stdout/stderr. I do not see how this
> solves that problem (on update of glusterfs-rdma).
>
We do log to log file, we have always done.
This fix just stops librdmacm from logging on to stderr simultaneously when we are logging to log file.
> It is indeed important to have critical errors visible when doing an
> update. Maybe the RDMA detection should log the unavailability of
> devices with INFO instead of something more alerting?
Rafi has a patch to fix the log level of errors.
Also, I will be sending a patch to remove rdma from default set of glusterd transport.
>
> Niels
>
> >
> > >
> > >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