Bug 93212 - Multiple Xorg servers overwrite /var/log/Xorg.0.log if no explicit display number is passed in command line
Summary: Multiple Xorg servers overwrite /var/log/Xorg.0.log if no explicit display nu...
Status: RESOLVED FIXED
Alias: None
Product: xorg
Classification: Unclassified
Component: Server/DDX/Xorg (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: Alan Coopersmith
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-12-02 12:02 UTC by Laércio de Sousa
Modified: 2016-05-02 06:11 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:

Attachments

Description Laércio de Sousa 2015-12-02 12:02:54 UTC 
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.
Comment 1 Laércio de Sousa 2015-12-02 12:04:58 UTC 
-tell the something:
+tell the following:
Comment 2 Alan Coopersmith 2016-01-02 02:05:19 UTC 
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.
Comment 3 Alan Coopersmith 2016-01-02 02:12:10 UTC 
Proposed patch posted to xorg-devel for testing & review:
http://patchwork.freedesktop.org/patch/69313/
Comment 4 Alan Coopersmith 2016-01-05 21:27:07 UTC 
Fix has been accepted & pushed to git master:
http://cgit.freedesktop.org/xorg/xserver/commit/?id=edcb6426f20c3be5dd5f50b76a686754aef2f64e
Comment 5 Antoine Martin 2016-05-02 04:09:19 UTC 
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)
Comment 6 Michel Dänzer 2016-05-02 05:53:53 UTC 
(In reply to Antoine Martin from comment #5)

Please file a new report about your problem. The problem this report is about is fixed.
Comment 7 Antoine Martin 2016-05-02 06:11:48 UTC 
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.