Hi all, Please see the updates from attached file.
If you have any other comments, please let me know. Thanks. Regards, Vu > -----Original Message----- > From: Vu Minh Nguyen [mailto:vu.m.ngu...@dektech.com.au] > Sent: Tuesday, June 7, 2016 2:50 PM > To: 'Lennart Lund' <lennart.l...@ericsson.com>; 'A V Mahesh' > <mahesh.va...@oracle.com> > Cc: 'opensaf-devel@lists.sourceforge.net' <opensaf- > de...@lists.sourceforge.net>; 'Jorge Pacheco Garcia' > <jorge.pacheco.gar...@ericsson.com> > Subject: RE: [PATCH 1 of 1] log: fix fail to recovery well-known streams [#1847] > > Hi Lennart, > > Please see my comments inline [Vu]. > > Regards, Vu > > > -----Original Message----- > > From: Lennart Lund [mailto:lennart.l...@ericsson.com] > > Sent: Monday, May 30, 2016 9:34 PM > > To: Vu Minh Nguyen <vu.m.ngu...@dektech.com.au>; A V Mahesh > > <mahesh.va...@oracle.com> > > Cc: opensaf-devel@lists.sourceforge.net; Lennart Lund > > <lennart.l...@ericsson.com>; Jorge Pacheco Garcia > > <jorge.pacheco.gar...@ericsson.com> > > Subject: RE: [PATCH 1 of 1] log: fix fail to recovery well-known > > streams [#1847] > > > > Hi Vu > > > > The problem described in the ticket is actually only that the > > following messages are printed in the syslog: > > > > May 23 14:28:34 REG-S1 osaflogd[8850]: NO lgs_imm_init_configStreams: > > log_stream_open_file_restore Fail May 23 14:28:34 REG-S1 osaflogd[8850]: > > NO lgs_imm_init_configStreams: log_stream_open_file_restore Fail May > > 23 > > 14:28:34 REG-S1 osaflogd[8850]: NO lgs_imm_init_configStreams: > > log_stream_open_file_restore Fail > > > > This is not error messages. It only means that > > log_stream_open_file_restore() fail to restore log files. This may > > happen if the file system is not available (scandir fail) or if more > > than one found file is empty (some corruption of the file system). If > > this happen new files will be created using > > log_stream_open_fileinit(). If this also fail the log service will try to create the > files when a client request to write a log record. > > This patch does not really solve the issue that triggered printing of > > these notifications. > > The title of this ticket is also not correct since these messages does > > not say that the log service has failed to recover the streams. The > > streams are recovered but the information in the log file (record id > > and name of current log file) could not be recovered. As a result a > > new current log file will be created and record id numbering will be restarted > from 0. > > > > I have added a note to the ticket with this information. > [Vu] I have modified the ticket's subject and description. > > > > > See comments inline [Lennart] > > > > Also I found the following comment in lgs_get_file_params_hdl() @ > > lgs_filehdl.cc: > > " // This memory will be deleted in > > log_stream_open_file_restore() > > // who wants to get the info from this memory - par_out- > > >curFileName " > > This comment is not ok since it refers to log_stream_open_file_restore(). > > The lgs_get_file_params_hdl() has no knowledge of this function also > > lgs_get_file_params_hdl() is called from other functions. However it > > is true that the calling function has to free this memory and a > > comment about that could/should be added to the header of the > > corresponding > > lgs_get_file_params_h() function. > [Vu] Thanks. I updated the comment and added a note to the function's header.. > > > > > > -----Original Message----- > > > From: Vu Minh Nguyen [mailto:vu.m.ngu...@dektech.com.au] > > > Sent: den 28 maj 2016 07:59 > > > To: Lennart Lund <lennart.l...@ericsson.com>; A V Mahesh > > > <mahesh.va...@oracle.com> > > > Cc: opensaf-devel@lists.sourceforge.net > > > Subject: [PATCH 1 of 1] log: fix fail to recovery well-known streams > > > [#1847] > > > > > > osaf/services/saf/logsv/lgs/lgs_filehdl.cc | 3 +++ > > > osaf/services/saf/logsv/lgs/lgs_recov.cc | 16 ++++++---------- > > > 2 files changed, 9 insertions(+), 10 deletions(-) > > > > > > > > > Return value of `lgs_get_file_params_h()` could be: > > > 1) Return (-1) if there is problem with I/O handling or memory allocation. > > > 2) Return (0) if not above, including cases: no log file found & log file found. > > > > > > (2.1) In case of getting return value (0) and no file found > > > (`curFileName == NULL`), logsv should consider this case as starting > > > from scratch: Doing initialization for streams, create cfg/log > > > files, etc. > > > > > > (2.2) In case of getting return value (0) and log file found > > > (`curFileName != NULL`), then re-using the previous log file as well > > > as record Id. > > > > > > This bug came because logsv not handle case (2.2). > > > > > > diff --git a/osaf/services/saf/logsv/lgs/lgs_filehdl.cc > > > b/osaf/services/saf/logsv/lgs/lgs_filehdl.cc > > > --- a/osaf/services/saf/logsv/lgs/lgs_filehdl.cc > > > +++ b/osaf/services/saf/logsv/lgs/lgs_filehdl.cc > > > @@ -1142,7 +1142,10 @@ int lgs_get_file_params_hdl(void *indata > > > ptr_str = strstr(par_out->curFileName, ".log"); > > > if (ptr_str == NULL) { > > > > [Lennart] In practice this can never happen since filename_get() can > > only return a filename with extension .log or an empty file name. > > See filter_logfile_name() used with scandir(). But this code does not hurt. > > > > > TRACE("%s: Could not find .log extension Fail", > > __FUNCTION__); > > > + free(par_out->curFileName); > > > + par_out->curFileName = NULL; > > > rc = -1; > > > + goto done; > > > } > > > *ptr_str = '\0'; > > > } > > > diff --git a/osaf/services/saf/logsv/lgs/lgs_recov.cc > > > b/osaf/services/saf/logsv/lgs/lgs_recov.cc > > > --- a/osaf/services/saf/logsv/lgs/lgs_recov.cc > > > +++ b/osaf/services/saf/logsv/lgs/lgs_recov.cc > > > @@ -716,24 +716,20 @@ int log_stream_open_file_restore(log_str > > > */ > > > > > > if (int_rc == -1) { > > > - /* No relevant file info found. Recovery fail */ > > > + /* Recovery fail. Has problem with I/O handling or memory > > > allocation */ > > > TRACE("%s: lgs_get_file_params_h Fail", __FUNCTION__); > > > rc_out = -1; > > > goto done; > > > } > > > > > > - if (int_rc == 0) { > > > - /* Cluster is probably installed from scratch */ > > > - rc_out = -1; > > > - goto done; > > > - } > > > - > > > /* If no current log file create a file name > > > */ > > > if (par_out.curFileName == NULL) { > > > - /* There is no current log file. Create a file name */ > > > - stream->logFileCurrent = stream->fileName + "_" + > > > lgs_get_time(NULL); > > > - TRACE("\t A new file name for current log file is created"); > > > + /* There is no current log file. Consider as logsv starts from > > > scratch */ > > > + TRACE("\t Create new cfg/logfile for stream (%s)", stream- > > > >name); > > > + log_stream_open_fileinit(stream); > > > + stream->creationTimeStamp = lgs_get_SaTime(); > > > + goto done; > > > } else { > > > stream->logFileCurrent = par_out.curFileName; > > > } > > [Lennart] In the original code only the nae of the current log file was created. > > The actual file was created when trying to write a log record. This is > > done by calling function log_stream_open_fileinit(stream) in > > log_stream_write_h() that is called in the evt function serving a > > write request. The > > log_stream_open_fileinit(stream) is called if *stream->p_fd == -1 > > which is the initial value for this variable. So instead of calling > > log_stream_open_fileinit(stream) p_fd should be set to -1 just to be > > sure (should not be needed). > [Vu] In `log_stream_open_fileinit(stream)`, there is code line to set `*stream- > >p_fd == -1`. > Means that, if logsv gets failed to open log file at this step, > `log_stream_open_fileinit(stream)` will be called when getting write request to > that stream. > And in original code (headless is disabled), for well-known streams, log files are > created at start-up. > > So, I think it is good to keep the same behavior (create log files for well-known > stream at start up) as legacy one.
lgsv_fail_to_recover_well_known_stream_r3.patch
Description: Binary data
------------------------------------------------------------------------------ What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
_______________________________________________ Opensaf-devel mailing list Opensaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-devel
