On May 4, 2015 20:17, Niels de Vos <ndevos@xxxxxxxxxx> 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@xxxxxxxxxx> 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@xxxxxxxxxx> > > >>>>>>> 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@xxxxxxxxxxx > > >>>>>>>> http://www.gluster.org/mailman/listinfo/gluster-devel > > >>>>>>> > > >>>>>>> _______________________________________________ > > >>>>>>> Gluster-devel mailing list > > >>>>>>> Gluster-devel@xxxxxxxxxxx > > >>>>>>> http://www.gluster.org/mailman/listinfo/gluster-devel > > >>>>>>> > > >>>>>> > > >>>>>> -- > > >>>>>> > > >>>>>> Kaleb > > >>>>>> _______________________________________________ > > >>>>>> Gluster-devel mailing list > > >>>>>> Gluster-devel@xxxxxxxxxxx > > >>>>>> http://www.gluster.org/mailman/listinfo/gluster-devel > > >>>> > > >>>> > > >>>> > > >>>> > > >>>>> _______________________________________________ > > >>>>> Gluster-devel mailing list > > >>>>> Gluster-devel@xxxxxxxxxxx > > >>>>> http://www.gluster.org/mailman/listinfo/gluster-devel > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> _______________________________________________ > > >>>> Gluster-devel mailing list > > >>>> Gluster-devel@xxxxxxxxxxx > > >>>> http://www.gluster.org/mailman/listinfo/gluster-devel > > >>>> > > >>> > > >> > > >> _______________________________________________ > > >> Gluster-devel mailing list > > >> Gluster-devel@xxxxxxxxxxx > > >> http://www.gluster.org/mailman/listinfo/gluster-devel > > _______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-devel
