| Summary: | Multiple Xorg servers overwrite /var/log/Xorg.0.log if no explicit display number is passed in command line | ||
|---|---|---|---|
| Product: | xorg | Reporter: | Laércio de Sousa <lbsousajr> |
| Component: | Server/DDX/Xorg | Assignee: | Alan Coopersmith <alan.coopersmith> |
| Status: | RESOLVED FIXED | QA Contact: | Xorg Project Team <xorg-team> |
| Severity: | normal | ||
| Priority: | medium | CC: | antoine |
| Version: | unspecified | ||
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
-tell the something: +tell the following: The SocketCreateListener errors are normal - libxtrans wasn't updated when displayfd was added to silence the warnings when we try each display in sequence to find an open one - it assumes any failure is bad news and needs a warning. Similarly the log file name logic wasn't updated to handle the display not being known until after the log was created, and needs updating to handle that. Proposed patch posted to xorg-devel for testing & review: http://patchwork.freedesktop.org/patch/69313/ Fix has been accepted & pushed to git master: http://cgit.freedesktop.org/xorg/xserver/commit/?id=edcb6426f20c3be5dd5f50b76a686754aef2f64e This change breaks existing applications which already provide their own logfile argument and later look for the file, as we do: the server ends up trying to rename the log file without changing its filename, and it fails with: Failed to rename log file "/home/user/.xpra/Xorg.S10814.log" to "/home/user/.xpra/Xorg.S10814.log": No such file or directory It just leaves the logfile renamed as "/home/user/.xpra/Xorg.S10814.log.old", presumably because it goes through LofFilePrep twice with the same filename. It looks to me like this logic should be ignored when a specific log filename is specified on the command line, and that when the new and old filename are identical the rename should not be attempted. This change of behaviour was quite unexpected from a stable update. (1.18.0 was fine) (In reply to Antoine Martin from comment #5) Please file a new report about your problem. The problem this report is about is fixed. The regression caused by this ticket is now tracked here: https://bugs.freedesktop.org/show_bug.cgi?id=95234 |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.
I'm currently testing multi-seat with new Qt-based display manager called SDDM. By default, it launches Xorg with no explicit display number, but with -displayfd option only instead. Example of "ps -FC X" output: UID PID PPID C SZ RSS PSR STIME TTY TIME CMD root 1086 897 0 38544 21520 1 09:28 tty7 00:00:00 /usr/bin/X -nolisten tcp -auth /run/sddm/{8978be12-df6d-4709-8c13-e2da98dc9cee} -background none -noreset -displayfd 17 -seat seat0 vt7 root 1361 897 0 66384 30480 0 09:28 ? 00:00:01 /usr/bin/X -nolisten tcp -auth /run/sddm/{2a76e104-bde5-4c25-86cb-a2a2f1cd855f} -background none -noreset -displayfd 23 -seat seat-other In my example, the X server that's running on seat0 got display number :0, and the other got :1. However, my :1 X server is not writing its log in /var/log/Xorg.1.log. Instead, it's overwriting /var/log/Xorg.0.log, losing log messages from :0 X server. Moreover, the first lines of :1 X server log tell the something: _XSERVTransSocketUNIXCreateListener: ...SocketCreateListener() failed _XSERVTransMakeAllCOTSServerListeners: server already running I don't know whether it's a normal behaviour or another bug.