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@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
