Created attachment 222190 [details] Patch against the ports tree Several fixes: 1. Create a lock file in the case of an explicitly requested display even if "-displayfd" was specified. This is because, in this case, the server creation process is essentially the same as when "-displayfd" is not specified. The only difference with the latter case should be that Xorg outputs the passed display to the display FD (only the display selection logic is bypassed). 2. Properly indicate an unexpected problem with link(2), instead of assuming that a failure always means that the file indeed exists. 3. Workaround for what appears to be a FreeBSD bug (link returns EPERM when hard linking a file whose permissions are the result of creating a file in a directory with sticky bit, although creating a separate copy is perfectly possible). Additional benefit: Simplifies the cumbersome logic, which on POSIX systems is unnecessary IMHO (initial lock file creation with O_EXCL is enough to ensure mutual exclusion). Again I'm submitting this here, since upstream seems inactive.
I am quite skeptical of pulling this in without it first being submitted and accepted upstream. Can you explain exactly what problem you are trying to solve?
Hi, sorry for not having stated the high-level use case here: - Launch X with "startx", specifying '/usr/local/bin/Xorg' as the server. E.g.: "startx -- /usr/local/bin/Xorg :1" You'll get an immediate crash saying "Can't read lock file /tmp/.X1-lock". Although no lock file exists at all under '/tmp'. The error comes from the fact that some lock file is prepared under another name (e.g., for display :1, under name '/tmp/.tX1-lock'), and this file is then hardlink to the final lock name using link(2), which improperly fails. The point of fixes 2 and 3 is to respectively better report on this problem and solve it. 3 is a simplification of the existing code (no functional change intended), which has the effect of working around a FreeBSD bug in link(2) that I'm going to submit as a separate bug with patch. Fix 1 is unrelated, done while I was looking at this code, and its usefulness is debatable, especially once bug #253277 is fixed. Even with this patch, pursuing with: "startx -- /usr/local/bin/Xorg :1" still doesn't work, because Xorg must be run as root. Substitution with: "startx -- /usr/local/bin/X :1" or "startx -- /usr/local/bin/Xorg.wrap :1" makes it work, but then the fixes are not needed, since link(2) works. Given all that, here is a path I find reasonable: 1. Focus should be #253277, this one is secondary. 2. I'll submit these fixes upstream. Maybe should we keep this PR open and I'll link the upstream bug here. Or I/you can close it. Don't know what's the policy in such cases. Thanks.
Reported upstream as: - https://gitlab.freedesktop.org/xorg/xserver/-/issues/1131 - https://gitlab.freedesktop.org/xorg/xserver/-/issues/1138 - https://gitlab.freedesktop.org/xorg/xserver/-/issues/1139
^Triage: note that the upstream reports are still open as of 20240119.