Is it possible to rotate the vncserver log while running?

[Frank Dana (FeRD)]

I have a headless system that uses a tigervnc-server display (launched via the systemd vncserver@.service unit at startup), and it runs some programs with fairly verbose output that ends up in $HOME/.vnc/$HOST:$DISPLAY.log.

That's all well and good, but there's enough output produced by the processes running on that display that I'd like to be able to rotate the logs, and that's where I'm running into troubles.

I can configure logrotate to rotate the logfile, that's not a problem. But even when it does, vncserver just keeps logging to the original file (now named $HOST:$DISPLAY.log-$DATE) instead of switching to the new, empty log. And if I have logrotate compress the rotated file and delete the original (vncserver's current log destination),  then the vncserver logs don't get stored anywhere until it's restarted.

Is there some way I can tell it to close its handle to the original log file and re-open the new one? Ideally, without restarting the server itself and disrupting the session running on it. Will it take a HUP signal? (I feel like I tried that, and it either ignored it or terminated, though I don't remember which.)

[Pierre Ossman]

On 05/05/2023 15:46, Frank Dana (FeRD) wrote:
>
> Is there some way I can tell it to close its handle to the original log
> file and re-open the new one? Ideally, without restarting the server itself
> and disrupting the session running on it. Will it take a HUP signal? (I
> feel like I tried that, and it either ignored it or terminated, though I
> don't remember which.)
>

No, I'm afraid not. And it would unfortunately be rather pointless to
add it to TigerVNC as it generally writes very little to that log file.
Every application writes independently to that file, so everything would
need to have support for switching over to a new file.

This is not a new problem, nor a VNC-specific one. TigerVNC's mechanism
mirrors that of a local login with ~/.xsession-errors. So there might be
some suggestions out there for how to deal with the issue.

One option might simply be to truncate the existing file. If you want to
emulate rotation, then you could make a copy of the existing copy before
truncating it.

Regards
--
Pierre Ossman Software Development
Cendio AB https://cendio.com
Teknikringen 8 https://twitter.com/ThinLinc
583 30 Linköping https://facebook.com/ThinLinc
Phone: +46-13-214600

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[Henrique Martins]

> I can configure logrotate to rotate the logfile, that's
> not a problem. But even when it does, vncserver just keeps

> logging to the *original* file

Isn't this what the copytruncate option of logrotate is for?

copytruncate
Truncate the original log file to zero size in place after cre‐
ating a copy, instead of moving the old log file and optionally
creating a new one. It can be used when some program cannot be
told to close its logfile and thus might continue writing (ap‐
pending) to the previous log file forever. Note that there is a
very small time slice between copying the file and truncating
it, so some logging data might be lost. When this option is
used, the create option will have no effect, as the old log file
stays in place. The copytruncate option allows storing rotated
log files on the different devices using olddir directive. The
copytruncate option implies norenamecopy.

-- Henrique

[Frank Dana (FeRD)]

On Friday, May 5, 2023 at 10:35:57 AM UTC-4 HASM wrote:

> I can configure logrotate to rotate the logfile, that's
> not a problem. But even when it does, vncserver just keeps
> logging to the *original* file

Isn't this what the copytruncate option of logrotate is for?

Indeed, it seems like copytruncate might serve my purposes. I'll give it a try, thanks! 

[Frank Dana (FeRD)]

Update: Works perfectly!

I didn't think it had, at first, because the truncated file (ostensibly) remains at its original size — but it's zeroed out into a sparse file, so the actual disk size is minimal until it begins filling back up. (Which it did, immediately, whereas the rotated file no longer receives any writes.)

Well, that's that sorted. Thanks.

[Frank Dana (FeRD)]

On Friday, May 5, 2023 at 10:45:35 AM UTC-4 Frank Dana wrote:

On Friday, May 5, 2023 at 10:35:57 AM UTC-4 HASM wrote:

Isn't this what the copytruncate option of logrotate is for?

Update: Works perfectly!

I didn't think it had, at first, because the truncated file (ostensibly) remains at its original size — but it's zeroed out into a sparse file, so the actual disk size is minimal until it begins filling back up. (Which it did, immediately, whereas the rotated file no longer receives any writes.)

Heh.This is getting kind of tangential at this point, but I thought I'd just drop a final note for anyone who might be in the same situation:

The reason the original log retains its size (in my case) is that one of the processes writing to it is a Java service, and apparently the JRE is extremely pig-headed about writing its console output. The process just keeps writing to whatever offset into the file it thinks is correct, even after the underlying file's been truncated and all of the preceding data is gone. So, after rotation you have an empty N-byte file (size of the original), which then gets logs appended to it... despite there no longer being any data to append to.

I even tried to get clever, and used fallocate --collapse-range to eliminate the sparse hole at the front of the log. That worked, technically — the zero bytes were dropped out, and the log data was moved to the start of the file... which lasted until the next write by the Java process. Which (predictably) went to the offset immediately after its last write, same as before. So instead of a huge file with a giant, sparse hole at the front, now I have an equally-huge file with a giant, sparse hole in the middle. ¯\_(ツ)_/¯