multiscreen logging

[Sebastian Kügler]

On dinsdag 26 juli 2016 19:44:11 CEST Martin Klapetek wrote:
> On Tue, Jul 26, 2016 at 8:03 AM, Sebastian Kügler <sebas at kde.org> wrote:
> Hey,
> 
> [Please keep both lists addressed.]
> 
> Debugging multiscreen issues is a nightmare:
> 
> - there are at least 4 different processes involved (kded, kcmshell /
>   systemsettings, kscreen_backend_launcher and plasmashell)
> - some are critical during log in
> - they IPC with each other
> - especially the backend launcher's debug is really hard to get at
> 
> This means that:
> - it's hard (almost impossible) for users to get us good and useful logs
> - it's hard for ourselves to debug and find out what's exactly going on,
> especially when multiple components need to play in tune
> 
> Yesternight, after debugging the so-many-th issue, it occurred to me that we
> need to make this way easier to debug. Q(C)Debug falls short in that we get
> logs of individual components, if we're lucky. If we're really lucky, we
> get timestamps, so we can get a rough idea of what is going down when.
> 
> All of these problems can be solved with a relatively simple, shared log
> file.
> 
> So I'd like to switch most of (lib)kscreen's debug output to logging to a
> file. The files has then logs from multiple processes and will be much
> easier to go through.
> 
> Wouldn't this create a possible concurrency issues when multiple processes
> write to the same file?
>  
> What do you think? If you like the idea, I'll polish up my branch and will
> post it for review, so we can discuss the actual implementation.
> 
> I think a possible better way could be to log each component into each own
> file (in the same dir) with timestamps and function stamps and process
> stamps and everything and then merge those files using some automation and
> sort by timestamp. Unless Qt on Linux actually handles concurrent write
> access just fine and in the correct order (I know it didn't on Windows last
> time I looked).

Potentially, yes. Is it a problem? No.

The log file isn't critical, and *usually* components are able to write in 
order (appending to a file doesn't take long). If the log ends up being 
slightly corrupted, that's bad luck. Instead of implementing complex merging 
tools or file-locking mechanism, having just these processes write to the same 
file and cross fingers works well enough. It's a debugging tool, file 
integrity is just not that important.

-- 
sebas

http://www.kde.org | http://vizZzion.org