IndexOutOfBoundError if you don't specify an extension is a bug that should be fixed. It could be fixed by tacking on a default extension if one does not exist.
I'm not sure what should be done about filenames with multiple "." in them (like "foo.log.gz"). Currently I think the code says what comes after the last "." is the extension and everything before that is the base name. It could instead say everything after the first "." is the extension. Since you give special meaning to it ending with ".gz" you could strip it off and then see if you have an extension on what remains and if you don't add a default (i.e. ".log") extension. It would be nice if when you gunzip a log file if it would now end with ".log" and when you gunzip a stat archive it would then end with ".gfs". If the user explicitly configured a log file or stat archive with a different extension I think that should continue to work. For example if they configured their log to be "foo.txt" I don't think we should start turning this into "foo.txt.log" or start giving them an error. On Tue, Feb 28, 2017 at 4:20 PM, Jinmei Liao <jil...@pivotal.io> wrote: > Darrel, it seems if user defines a log file to be simply "serverLog" (a > filename with no "."), when rolling over the log file once file size is > reached, we get a IndexOutOfBoundError when it's trying to figure out > what's the rolled-over filename should be. > > And if user defines a log file name to be "server.log.gz", when rolling > over, the new filename seems to be "server.log_01_01.gz". Does not look > like we handle the ".gz' suffix correctly. For now, we do want to enforce > the log/stats filename ends with appropriate suffix. > > On Tue, Feb 28, 2017 at 3:16 PM, Darrel Schneider <dschnei...@pivotal.io> > wrote: > > > It sounds like you will pick up any file in the working directory that > ends > > with ".log" or ".log.gz". > > But what if the geode server is sharing a directory with something else > > that is also writing files with these extensions? > > Or if multiple geode servers are running in the same directory? > > I think it would be better to use the configured log file name and stat > > archive name and use that to find the logs and stats to gather. The > rolling > > code has already been written that will find all the existing logs and > > stats. In any bugs in that code need to be fixed since it would break the > > code that removes old files based on disk space. So it seems like you > > should be able to use this same code to get a list of the files to copy. > > > > > > On Tue, Feb 28, 2017 at 2:57 PM, Dan Smith <dsm...@pivotal.io> wrote: > > > > > I'm a bit confused by (1). Isn't it actually more complicated for you > to > > > restrict log collection to a relative path? Why not just look for log > > files > > > no matter where they are written to? I also don't really follow the > > > argument about why a user that writes to /var/logs is not going to want > > to > > > use this command. Won't all users want to be able to gather their logs > > > using this command? > > > > > > 2 seems reasonable. It seems like we should restrict the file names if > we > > > are going to have this limitation. > > > > > > -Dan > > > > > > On Tue, Feb 28, 2017 at 2:43 PM, Jinmei Liao <jil...@pivotal.io> > wrote: > > > > > > > Hello community, > > > > > > > > We are currently trying to improve what "export logs" should do. > > > Currently > > > > export logs only export the logs(filtered by logLevel and start and > end > > > > date) to each individual member's file system. We want to make all > the > > > > member's logs exported to a central location and if you are > connecting > > > > using http, it will be exported to your local file system. This is to > > > > facilitate gathering logs in the cloud environment. > > > > > > > > That said, for the first round of implementation, we would like to > > impose > > > > these restrictions to this command: > > > > 1) it will only look for the logs/stats in each members working > > directory > > > > only. > > > > 2) it will only look for files that ends with .log, .log.gz, .gfs or > > > > .gfs.gz. > > > > > > > > Background for 1): if you started your locator/server with "log-file" > > or > > > > "statistics-archive-file" with an absolute path, it will write these > > > files > > > > to that location, but if you simply give it a relative path, the > files > > > will > > > > be written to the member's working directory. The reasoning behind 1) > > is > > > > that this command is mostly for those environment that you can't > easily > > > go > > > > to the member's filesystem to get logs, but if you have started your > > > > server/locator with an absolute path like "/var/logs", we are > assuming > > > you > > > > already know how to get the logs, thus this command to not mean much > to > > > > you. > > > > > > > > For restriction 2), since logs and stats files roll over, it is much > > > easier > > > > to find the target files with extensions rather than file name > > patterns. > > > We > > > > could either do not allow you to start server/locator with other file > > > name > > > > suffix or post a warning. We would need the community's input on > this. > > > > > > > > Any feedback is appreciated. > > > > > > > > -- > > > > Cheers > > > > > > > > Jinmei > > > > > > > > > > > > > -- > Cheers > > Jinmei >
