6

I have a service which insists on keeping it's log files in terrible locations. After all efforts to change where it keeps them failed, my next idea was to create hardlinks to those files somewhere cleaner. This led me to a concern:

If I configure logrotate to manage these log files, will it work as intended (rotate logs, keep my links working)? Or will logrotate accidentally break the links, and leave the logs accumulating in their native locations but not in my central one?

I believe I can configure logrotate to re-create the hard links after a rotation if necessary. But, is it necessary?

Scivitri
  • 171
  • 1
  • 4

3 Answers3

4

Do not link to the files: link to the directory. If you link to the file, you may have a problem when the application creates a new log file, either as part of log rotation (depending how that is done) or when you stop and later restart the application.

ln -s /path/to/where/application/creates/logs/ /var/log/application
ramruma
  • 2,730
  • 1
  • 14
  • 8
  • The initial problem is that the application keeps ALL its files in one folder. Executable, config, log, libraries... Adding rotation files for logs just make an incomprehensible jumble that much less useful. I was hoping to cherry-pick the log files and link to them in another location, for easy noticing. – Scivitri Jul 15 '13 at 22:17
3

I think you can use symlinks to your desired new location and tell logrotate to rotate the logs in whatever folder they actually reside in; ln -s /path/file /path/to/newlink

user16081-JoeT
  • 1,950
  • 11
  • 18
  • Upon reflection, I kinda like this approach. I can tell logrotate to keep the rotated logs in my new location, and link to the current logs from my new location. All problems solved. Thank you! – Scivitri Jul 15 '13 at 22:18
  • did it work the way you need it? if you used this solution and it's working, please note it as the answer - thanks – user16081-JoeT Jul 16 '13 at 04:10
  • The answers were in a different order when I came back, so I read your answer before sysadmin1138's. Adding "copytruncate" to my config stanza make's sysadmin's first solution work, which was basically how I already had things set up. And, ultimately, that answer verified for me that the default behavior was copy-and-create, which would have broken things. – Scivitri Jul 17 '13 at 00:37
  • On Ubuntu 18.04, logrotate won't rotate symbolic links `log /var/log/my.log is symbolic link. Rotation of symbolic links is not allowed to avoid security issues -- skipping.` – Jason Harrison Nov 28 '19 at 18:47
3

To answer your question, it kind of depends on what kind of rotating you do. For instance, the following progression will happen:

Copy-and-truncate method:

  1. Logrotate copies the logfile to a new logfile.
    • The new logfile only shows up in the old location yet.
  2. Logrotate truncates the old file.
    • This turns the old file to zero bytes in both locations.
  3. Logfile continues to fill from the application.

This leaves the logfile backups in the old location.

The fix to this is fairly simple: configure logrotate to rotate the logs in the new location. The old one will still have the growing file, but it'll only be the one.

Copy-and-create method:

  1. Logrotate copies the file to a new logfile.
    • This logfile is not hardlinked, and only shows up in the new location.
  2. Logrotate removes the old log-file.
    • Due to hardlinking, this just removes the hardlink in the directory logrotate runs against. The other directory will still have a complete copy of the file.
  3. Logrotate creates a new logfile.
    • This will not be hardlinked to the other location.

This method is most problematic, and you'll need some post-rotate magic to clean up after it.

sysadmin1138
  • 131,083
  • 18
  • 173
  • 296
  • 1
    Your copy-and-create is exactly what I was afraid logrotate would do, and why I thought my scheme would break. I must have missed a setting to control how logrotate handles the old file; I'll read up more. Thank you! – Scivitri Jul 15 '13 at 22:22