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
Am 04.02.2024 um 16:24 schrieb 'DRC' via TurboVNC User Discussion/Support:
That is what grep and other Un*x parsing tools are for.
On Feb 4, 2024, at 10:09 AM, Torsten Kupke <tkans...@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.
Am 04.02.2024 um 15:41 schrieb 'DRC' via TurboVNC User Discussion/Support:
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 <tkans...@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-users+unsubscr...@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.
--
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-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/turbovnc-users/fcf6354e-3c53-4aeb-a1a4-cca4fba497e8%40t-online.de.
--
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-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/turbovnc-users/6bf4c177-4f49-448e-8afe-fbad4e64e789%40t-online.de.
