No way to gracefully rotate the libgfapi vfs_glusterfs logfile. There is no way to gracefully rotate the libgfapi Samba vfs_glusterfs glusterfs:logfile=<my_log_file>. Nothing works other than a full restart of the 'smbd' service, which negatively affects all shares, which is not ideal. This is the case with the latest available versions, GlusterFS 3.6.2, and Samba 4.1.16.
We have to think about providing something like an API to enable rotating the logs in a usable way. I agree that stopping/starting an application that uses libgfapi (like samba) is not acceptable. When we have defined and implemented an API for this, we need to inform the Samba community about this new functionality. Shyam, are you interested in looking into this, or shall I do that?
Let me take a stab at it. Assigned to myself.
Current situation: The regular gluster deamons, use SIGHUP to get notified on log rotations, so when the logrotate cron job runs, it notifies glusterfs(d), glusterd, et. al. via a HUP to close the old fd/FILE and open a new one. logrotate in the background has already renamed the file to its backup name etc. gfapi cannot override HUP as it is being used by another service and is not a deamon buy itself. As a result, there is no way currently to notify gfapi that a log rotation has been performed. Here are the options for gfapi consumers: 1) Add a logrotate entry for the log file that is configured via SAMBA (or any other service that uses gfapi) with the copytruncate flag in the rotate command. copytruncate, will let the deamon operate on the same fd/FILE whereas copy the old contents and truncate the original file, as a result we achieve rotation. @Jeff, possibly even academic, but could you try this option? If not, just remove the NEEDINFO flag against yourself. 2) Provide an API that the consumer of gfapi can call, to gracefully rotate logs, and consumer would need to handle when this API is called (say in their HUP signal handler). This requires changes (as stated by Niels) in gfapi and its consumers.
(In reply to Shyamsundar from comment #3) > Current situation: > The regular gluster deamons, use SIGHUP to get notified on log rotations, so > when the logrotate cron job runs, it notifies glusterfs(d), glusterd, et. > al. via a HUP to close the old fd/FILE and open a new one. logrotate in the > background has already renamed the file to its backup name etc. > > gfapi cannot override HUP as it is being used by another service and is not > a deamon buy itself. As a result, there is no way currently to notify gfapi > that a log rotation has been performed. > > Here are the options for gfapi consumers: > > 1) Add a logrotate entry for the log file that is configured via SAMBA (or > any other service that uses gfapi) with the copytruncate flag in the rotate > command. > > copytruncate, will let the deamon operate on the same fd/FILE whereas copy > the old contents and truncate the original file, as a result we achieve > rotation. > > @Jeff, possibly even academic, but could you try this option? If not, just > remove the NEEDINFO flag against yourself. > > 2) Provide an API that the consumer of gfapi can call, to gracefully rotate > logs, and consumer would need to handle when this API is called (say in > their HUP signal handler). > > This requires changes (as stated by Niels) in gfapi and its consumers. I did not use logrotate, but performed the test manually by hand. The logrodate copytruncate option (or the functional equivalent) should work fine. This implies that there is no logfile offset knowledge, or seeking within the logfile, other than to the EOF, which seems likely. Thanks.
comment#3 talks about the issue where glusterfs can't handle SIGHUP of the process which uses gfapi. GFAPI changes are not happening now, and hence marking it as DEFERRED.