xpra recover logs have no timestamps

[stdedos]

While checking why wasn't #3109 solved by your updates, I noticed that the display-:2-$TIMESTAMP logs after xpra upgrade are not prepended with timestamps.

[stdedos]

... or it was the recover 😅

xpra upgrade blew up (#3175)

[totaam]

I noticed that the display-:2-$TIMESTAMP logs after xpra upgrade are not prepended with timestamps.

The default value is:

$ xpra showconfig | grep -i log-file
log-file                       = '$DISPLAY.log'

Are you using --log-file=display-$DISPLAY-$TIMESTAMP ?

In any case, we are talking about the contents of these log files, right?
Works for me:

$ xpra start --start=xterm :20
Entering daemon mode; any further errors will be reported to:
  /run/user/1000/xpra/:20.log
$ sleep 2
$ grep "xpra X11" /run/user/1000/xpra/\:20.log 
2021-07-03 19:57:52,165 xpra X11 seamless version 4.3-r29386 (gadea604c2) 64-bit
$ xpra upgrade
Sent exit command
Entering daemon mode; any further errors will be reported to:
  /run/user/1000/xpra/:20.log.new
Actual log file name is now: /run/user/1000/xpra/:20.log
$ grep "xpra X11" /run/user/1000/xpra/\:20.log 
2021-07-03 19:59:27,188 xpra X11 seamless version 4.3-r29386 (gadea604c2) 64-bit

I've used this particular line from the log file, but all of them look the same.

What am I missing?

[stdedos]

Are you using --log-file=display-$DISPLAY-$TIMESTAMP ?

Yes, so I can keep referencing old logs after the xpra upgrade 😛
I am not sure I need all of the ~200 files that I have right now, but it still beats having only one log per display

What am I missing?

Unfortunately nothing. Most of my interactions are exactly like that - except lengthier (of course).
Of course, we also had #3175. So, if #3175 was directly replicatable with you, maybe try with this one?

xpra start :20, and from another client (maybe even physically separate i.e. via ssh):

1. xpra attach :20, and inside of that:
   1. xpra upgrade :20
2. xpra attach :20 (timeout)
3. xpra attach :20 (timeout)
4. xpra start ssh://host-2/
   1. xpra recover (:20)
5. xpra attach :20

and then check the server logs?

[totaam]

It was all my fault. Really sorry for being thick like that!
My reproduction steps used upgrade but the issue title clearly says recover...
Once I did that, it was easy to see.

Trivial fix in 8e1beee

xpra start :20, and from another client (maybe even physically separate i.e. via ssh):

1. xpra attach :20, and inside of that:

   1. xpra upgrade :20

You will be disconnected at this point.
Now you should be warned about it too (aad821b), assuming that you have time to see it before the session is disconnected.

... and we should auto-reconnect just like the HTML5 client already does, if I get around to it.

[stdedos]

It was all my fault. Really sorry for being thick like that!

Nooooooo, no no no, relax 😀 It's not like my reproduction steps are always crystal-clear 😂
I hope that this is a friendly interaction of two humans trying to improve a software - warts an' all.
(If we are keeping score, however, I won this round 😛)

... and we should auto-reconnect just like the HTML5 client already does, if I get around to it.

You have so much on your plate, I wouldn't be looking so much forward to that.
However, ... a quick beta idea: Can't you just do exec "$0" "${ARGS[@]}" (ala bash) at the end of the xpra client's code, but before xpra client "let's go" of the SSH connection? 😕

Trivial fix in 8e1beee

Interesting code you have there.

"It sounds to me" that you should have two lists (at least in testing): one with the above values, one with the other modes that you are explicitly not doing that. Then, in pytest: assert sorted(XPRA_MODES) == sorted([*fmt_logged_modes, *not_fmt_logged_modes]).

(I know I make it sound easy, and that "maybe" it's not as easy as that, but that might trigger to you a better idea to avoid introducing a regression like that again)

[stdedos]

I'll guess I'll have to verify this sometime next that I'll want to upgrade my server.
What was the way to kill the xpra server, without touching the X11? xpra exit? (#3088 (comment))

[totaam]

What was the way to kill the xpra server, without touching the X11?

Yes. xpra exit.

I am closing as I am very confident this is fixed. Please re-open if not.

[stdedos]

Verified as fixed in r29406 (d03ead0)