I client of ours has the desire to merge a patch to libosmocore that adds simplistic log rotation functionality.
Our first response was against it: we have the SIGHUP handling that allows logrotate to tell osmocom programs to re-open their log file(s).
However, the system in question is based on BusyBox, which lacks logrotate. I haven't yet investigated why it can't just be installed, but there seems to be some or other issue about that.
The next best idea is to cook up a shell script that does more or less what logrotate does ... and probably run into problems that logrotate already solves better. The script needs to clean old files and invoke SIGHUP...
So I'd like to ask around, maybe it is acceptable to merge a poor-man's log rotation functionality to libosmocore after all?
The patch needs some improvements (VTY configurability for starters), but so far goes something like this:
static void _file_output(struct log_target *target, unsigned int level, const char *log) { - fprintf(target->tgt_file.out, "%s", log); - fflush(target->tgt_file.out); + int n; + + if (target->tgt_file.out) { + + n = fprintf(target->tgt_file.out, "%s", log); + fflush(target->tgt_file.out); +#ifdef stderr + /* don't try try to roll stderr */ + if (target->tgt_file.out != stderr) +#endif + { + if (n > 0) { + target->tgt_file.written_count += n; + + if (target->tgt_file.roll_count != 0 && + target->tgt_file.written_count > target->tgt_file.roll_count) { + + /* Create filename */ + char rotname[strlen(target->tgt_file.fname) + 3]; + + strcpy(rotname, target->tgt_file.fname); + strcat(rotname, ".1"); + + /* Rename the current log, then reopen the log to start new file */ + rename(target->tgt_file.fname, rotname); + log_target_file_reopen(target); + } + } + } + } }
Note, this follows a simplistic approach to removing old log files: there is always exactly one rotated-away file, 'mylogfile.1', which gets overwritten in each rotation.
Any rotation features more elaborate than this should better be solved with logrotate, but would everyone accept this kind of patch merged to libosmocore?
Thanks,
~N
Hi Neels,
I'm not fundamentally opposed, but I still believe it is the wrong thing to merge a patch like this.
Any reasonably advanced embedded Linux system will be running more than just the osmocom daemons/processes, and most if not all of them are going to be writing some logs somewhere. Yes, that one particular user might not need it *now*. But what if they add another standard program later? Does this program then also need to be patched with a custom log-rotate reimplementation?
So whether you use logrotate, or journald, or whatever other mechanism of dealing with logs and related rotation, the task will always be the same.
So I'm actually more in favor of helping to make logrotate work with busybox, or writing a small "micro logrotate" in C that can either become part of libosmocore or be distributed as separate program/project. This way the related functionality is not only limited to Osmocom programs, but potentially any other log-file-writing program out there.
If you reduce configurability to a minimum, that program wouldn't be doing much, after all, right?
btw: This post on the busybox mailing list suggest to log to stderr and pipe that to svlogd, which allegedly has the vcapability yo rotate logs: http://lists.busybox.net/pipermail/busybox/2011-January/074413.html
Regards, Harald
-
Harald Welte -
Neels Hofmeyr