Number of logfile entries reducable in any way?

[Torsten Kupke]

Hi,

is there any possiblity (e.g. an option on the command line) to reduce
the number of lines in ~/.vnc/[LOGFILENAME] on the machine running the
TurboVNC server?

BR

tkansgar

[DRC]

What is the specific problem you are having? The log file should not be written to except during the startup of the X server and window manager and whenever clients connect or disconnect. If it is growing to a large size, then that is not normal.

> On Feb 4, 2024, at 8:28 AM, Torsten Kupke <tkan...@t-online.de> wrote:
>
> Hi,

>
> is there any possiblity (e.g. an option on the command line) to reduce the number of lines in ~/.vnc/[LOGFILENAME] on the machine running the TurboVNC server?
>
> BR
>
> tkansgar
>

> --
> You received this message because you are subscribed to the Google Groups "TurboVNC User Discussion/Support" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to turbovnc-user...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/turbovnc-users/e55355fd-9a61-414f-ae67-16be17e8a63b%40t-online.de.

[Torsten Kupke]

That has a very specific reason. I use the times of my client
connections and disconnections to determine my working times I have to
propagate to my employer. And when I have connected and disconneted
mutiple times at a day, I have to scroll a long way through that
logfile. It's not so bad, but I saw, that the number of log entries per
connection has increased, since I have installed TurboVNC 3.1. So now I
have to scroll even more than before. Tomorrow I can copy & paste a
snippet of subsequent entries for one connection/disconnection. Maybe
there are some entries, which should not be there or are avoidable in
any way.

[DRC]

That is what grep and other Un*x parsing tools are for.

> On Feb 4, 2024, at 10:09 AM, Torsten Kupke <tkan...@t-online.de> wrote:
>
> That has a very specific reason. I use the times of my client connections and disconnections to determine my working times I have to propagate to my employer. And when I have connected and disconneted mutiple times at a day, I have to scroll a long way through that logfile. It's not so bad, but I saw, that the number of log entries per connection has increased, since I have installed TurboVNC 3.1. So now I have to scroll even more than before. Tomorrow I can copy & paste a snippet of subsequent entries for one connection/disconnection. Maybe there are some entries, which should not be there or are avoidable in any way.

> To view this discussion on the web visit https://groups.google.com/d/msgid/turbovnc-users/fcf6354e-3c53-4aeb-a1a4-cca4fba497e8%40t-online.de.

[Torsten Kupke]

Hi DRC,

these are the logfile entries of last friday:

02/02/2024 08:25:20 Got connection from client 10.128.195.10
02/02/2024 08:25:20 Normal socket connection
02/02/2024 08:25:20 Using protocol version 3.8
02/02/2024 08:25:20 Enabling TightVNC protocol extensions
02/02/2024 08:25:20 Advertising Tight auth cap 'VENCRYPT'
02/02/2024 08:25:20 Advertising Tight auth cap 'VNCAUTH_'
02/02/2024 08:25:20 Advertising Tight auth cap 'ULGNAUTH'
02/02/2024 08:25:20 Client requested VeNCrypt sub-type 259
02/02/2024 08:25:20 Anonymous TLS key length: 2048 bits
02/02/2024 08:25:20 Available cipher suites:
TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:ADH-AES256-GCM-SHA384:ADH-AES128-GCM-SHA256:ADH-AES256-SHA256:ADH-CAMELLIA256-SHA256:ADH-AES128-SHA256:ADH-CAMELLIA128-SHA256:AECDH-AES256-SHA:ADH-AES256-SHA:ADH-CAMELLIA256-SHA:AECDH-AES128-SHA:ADH-AES128-SHA:ADH-CAMELLIA128-SHA:AECDH-NULL-SHA
02/02/2024 08:25:20 Deferring TLS handshake
02/02/2024 08:25:21 Negotiated cipher suite: AECDH-AES256-SHA
02/02/2024 08:25:29 PAM authentication succeeded for user 'torsten'
02/02/2024 08:25:29 Pixel format for client 10.128.195.10:
02/02/2024 08:25:29   32 bpp, depth 24, little endian
02/02/2024 08:25:29   true colour: max r 255 g 255 b 255, shift r 16 g 8 b 0
02/02/2024 08:25:29   no translation needed
02/02/2024 08:25:29 Enabling full-color cursor updates for client
10.128.195.10
02/02/2024 08:25:29 Enabling Desktop Size protocol extension for client
10.128.195.10
02/02/2024 08:25:29 Enabling Extended Desktop Size protocol extension
for client 10.128.195.10
02/02/2024 08:25:29 rfbProcessClientNormalMessage: ignoring unknown
encoding -307 (fffffecd)
02/02/2024 08:25:29 Enabling LastRect protocol extension for client
10.128.195.10
02/02/2024 08:25:29 Enabling Continuous Updates protocol extension for
client 10.128.195.10
02/02/2024 08:25:29 Enabling Fence protocol extension for client
10.128.195.10
02/02/2024 08:25:29 Enabling Extended Clipboard protocol extension for
client 10.128.195.10
02/02/2024 08:25:29 Enabling GII protocol extension for client 10.128.195.10
02/02/2024 08:25:29 Enabling QEMU Extended Key Event protocol extension
for client 10.128.195.10
02/02/2024 08:25:29 Enabling QEMU LED State protocol extension for
client 10.128.195.10
02/02/2024 08:25:29 Enabling VMware LED State protocol extension for
client 10.128.195.10
02/02/2024 08:25:29 Using tight encoding for client 10.128.195.10
02/02/2024 08:25:29 Interframe comparison enabled
02/02/2024 08:25:29 Using JPEG subsampling 0, Q92 for client 10.128.195.10
02/02/2024 08:25:29 Using JPEG quality 80 for client 10.128.195.10
02/02/2024 08:25:29 Using JPEG subsampling 2 for client 10.128.195.10
02/02/2024 08:25:29 Using Tight compression level 1 for client 10.128.195.10
02/02/2024 08:25:29 Using 4 threads for Tight encoding
02/02/2024 08:25:29 Client clipboard capabilities:
02/02/2024 08:25:29 - Plain text (limit = 0 bytes)
02/02/2024 08:25:29 Client supports GII version 1
02/02/2024 08:25:29 New screen layout:
02/02/2024 08:25:29   0x00000040 (output 0x00000040): 3840x1200+0+0
02/02/2024 08:25:29 Continuous updates enabled
02/02/2024 08:25:29 Continuous updates enabled
02/02/2024 08:25:29 Continuous updates enabled
02/02/2024 17:13:54 Client 10.128.195.10 gone
02/02/2024 17:13:54 Statistics:
02/02/2024 17:13:54   key events received 0, pointer events 1014479
02/02/2024 17:13:54   framebuffer updates 474504, rectangles 2167962,
bytes -1543200145
02/02/2024 17:13:54     LastRect markers 74527, bytes 894324
02/02/2024 17:13:54     cursor shape updates 13488, bytes 32007285
02/02/2024 17:13:54     CopyRect rectangles 1, bytes 16
02/02/2024 17:13:54     Tight rectangles 2079946, bytes -1576101770
02/02/2024 17:13:54   raw equivalent 67585.343924 Mbytes, compression
ratio 24.857921
02/02/2024 17:13:54 Interframe comparison disabled

Is there something looking erroneous in your eyes? Or is there something
I could avoid to be logged without loosing any functionality?

Of course, I could write a kind of script to filter for my useful
entries. But currently I don't want to put in that work. I only wanted
to know, whether there is an easy way to reduce the number of lines in
this logfile (maybe through a kind of verbosity adjustment option). If
not, I can live with it.

BR

tkansgar

[DRC]

You don't need a script.  You probably just need to do

    grep -E 'Got connection|gone' ~/.vnc/{hostname}-{display}.log

Only some of the TurboVNC features can be disabled, and I have no idea
which features you may or may not need.  The log file has a typical
level of verbosity compared to other Linux remote desktop solutions, and
no, there is not a way to reduce it.  There is only a way to make it
more verbose, by passing -debug to vncserver to enable all Xorg messages
in addition to TurboVNC messages.  grep is the best solution, because it
frees you from having to scroll through the log at all.