[mythtv-users] mythbackend.log is buffered?

[Simon Hobson]

Bill Meek <keemllib at gmail.com> wrote:

> On 10/25/2015 03:22 PM, Jerome Yuzyk wrote:
>> mythbackend --logpath /var/log/mythtv
> 
> Hi,
> 
> --logpath should create files named: mythbackend.20151025173138.1838.log etc.
> At least mine always has.
> 
> I recall another user using logrotate with --logpath that kept
> his BE always on (I shut down mine when idle.) His concern was
> that mythbackend didn't restart the logging when logrotate sent a
> signal to it.
> 
> If you restart the BE, I suspect your logs will reappear (with names
> similar to the above.)

If the backend doesn't do it's part, it'll keep writing to the log file it has open. If the logrotate process has "deleted" that file (after gzipping it), then it'll be an invisible inode on the disk, with no directory entry to access it by. Once the last process closes the file descriptor, the inode will be deleted.

That's normal Unix filesystem operation. A file (as we see it) is just a pointer, the "real" file is simply a number (the inode number), and the human readable directory entries merely point to those inode numbers. If a file is open when something deletes it, the directory entry is removed - but the underlying inode is kept around. You can see tis if the file is very large - deleting it doesn't free up disk space until the last process closes it.

This is also how hard links work - they are simply multiple directory entries referring to the same inode.

As an aside, this is also why Unix type systems can do upgrades with so many fewer reboots than certain other OSs. A file (eg a program file) can be deleted while it's open and replaced by a newer version. Once the program exits, the old file disappears, and when the program is relaunched, it'll use the new file.
Microsoft filesystems lack this separation - so you can't delete a file that's open - hence all the reboots in order to close files to allow them to be replaced.