Talk:Xinit
propose to add to automatic startx
When combine automatic startx + automatic login to console, it may come to infinite loop/crash if (a) ~/.xinitrc goes wrong somewhere, after editing; or (b) after pacman -Syyu and Xorg crash. I propose to check if the last GUI session (startx session) really last long before start a new one.
if [[ -z $DISPLAY && $XDG_VTNR -eq 1 ]]; then if [[ -f /tmp/login-check-startx.flag ]]; then rm /tmp/login-check-startx.flag echo -e "\nFile '/tmp/login-check-startx.flag' found, maybe the last GUI session did not last long!\n" ## do nothing, start automatic console login else touch /tmp/login-check-startx.flag ( sleep 120; rm /tmp/login-check-startx.flag ) & exec startx fi fi ## Change '/tmp/login-check-startx.flag' to '$HOME/login-check-startx.flag' if you want that check also valid after reboot.
Triplc (talk) 20:42, 20 April 2016 (UTC)
- You might do that without the temporary file by simply looking at the age of the log file:
if [[ -z $DISPLAY && $XDG_VTNR -eq 1 ]]; then if [[ ! -e ~/.local/share/xorg/Xorg.0.log || $(find ~/.local/share/xorg/Xorg.0.log -mmin +2) != "" ]]; then exec startx fi fi
- Or even more simply, don't
exec startx, check its return code and drop to interactive shell on errors:if [[ -z $DISPLAY && $XDG_VTNR -eq 1 ]]; then startx && exit fi
-- Lahwaacz (talk) 21:10, 20 April 2016 (UTC)
- Thanks Lahwaacz. But (a) so the age of a file is based on it's creation time, not update time. OK, i did not know that. (b) about the startx exit code, i am not sure that it will correctly set if i edit something wrong in ~/.xinitrc which make GUI session crash
- Xinit#Autostart_X_at_login should be sufficient for most intents and purposes. Closing -- Alad (talk) 10:10, 10 March 2023 (UTC)
examples
there are 2 xinit examples which by themselves do not work as laid out, imo they should be removed and instead an optional note could be put (somewhere) that says something like:
- xinit can be executed instead of startx if you know what options to use
otherwise it seems frustrating to recommend examples which will obviously fail --Ubone (talk) 02:29, 12 November 2018 (UTC)
- xinit would not obviously fail if you specified the options in xserverrc. If you already have an X server started, you should also pass the
:display_numberoption mentioned in the note after the first example. -- Lahwaacz (talk) 07:35, 12 November 2018 (UTC)
- then replace or in #Usage with or if #xserverrc is configured: ? --Ubone (talk) 08:10, 12 November 2018 (UTC)
Add `export DESKTOP_SESSION=something` to ~/.xinitrc
I have had issues previously described here:
https://bbs.archlinux.org/viewtopic.php?pid=1904173
https://www.reddit.com/r/archlinux/comments/hhl3s9/how_do_you_trace_dbus_automatic_activation/
In summary, and how to reproduce:
sudo pacman -S xorg-xinit plasma deepin- follow the wiki's instructions to set up
~/.xinitrc, e.g. below
~/.xinitrc
#!/bin/sh
userresources=$HOME/.Xresources
usermodmap=$HOME/.Xmodmap
sysresources=/etc/X11/xinit/.Xresources
sysmodmap=/etc/X11/xinit/.Xmodmap
# merge in defaults and keymaps
if [ -f $sysresources ]; then
xrdb -merge $sysresources
fi
if [ -f $sysmodmap ]; then
xmodmap $sysmodmap
fi
if [ -f "$userresources" ]; then
xrdb -merge "$userresources"
fi
if [ -f "$usermodmap" ]; then
xmodmap "$usermodmap"
fi
# start some nice programs
if [ -d /etc/X11/xinit/xinitrc.d ] ; then
for f in /etc/X11/xinit/xinitrc.d/?*.sh ; do
[ -x "$f" ] && . "$f"
done
unset f
fi
exec startplasma-x11
I observed the following glitches:
- the command
startplasma-x11leads to/usr/lib/deepin-daemon/dde-system-daemonbeing forked off of systemdbus.service - less important but, kvantum themes do not apply to autostarted X apps.
However these problems do not occur when starting KDE Plasma from gdm. I used printenv to track differences.
If you add the line export DESKTOP_SESSION=plasma before exec startplasma-x11 in ~/.xinitrc, KDE loads correctly (without deepin processes in the background and themes correctly applied to autostarted applications).
Maybe we should add export DESKTOP_SESSION=desktop_environment to the wiki instructions?
Jennydaman (talk) 18:47, 29 June 2020 (UTC)
- I don't think it's an issue with other desktop environments, so add it to KDE#From the console instead. -- Lahwaacz (talk) 08:38, 30 June 2020 (UTC)
- Apart from KDE, most desktop environments set the correct environment variables they require. Closing -- Alad (talk) 10:09, 10 March 2023 (UTC)
xinitrc.d scripts tip
Hmm as @Alad pointed out by the consideration of removal, I haven't thought about the .xinitrc actually being user content. I kind of thought about the way scripts are sourced as somewhat standard, even though there should really not be such expectation (even if it were kind of nice).
However I think it may be useful to somehow explain that the 'default implementation (on Arch?)' does source only executable files. Or I'm not sure. It just confused me that the x permission would be required, since the source command in bash does not require the file to be executable. Maybe there's a bigger reason behind this behaviour in the default .xinitrc - or maybe it shouldn't be like this, I'm not sure how other programs implement .d/ folders.
Feel free to delete this or improve on this, it was just a quick idea how to maybe save someone a while - but maybe it's too big of a headache and not that important.
I don't know how to rewrite what I added, again, feel free to moderate this.
Jsmetana (talk) 21:39, 7 December 2021 (UTC)
- I am confused as to why it's giving you trouble with non-executable files. It should be using the
.builtin, which does not require the file to be executable. As for the shebang, that is useful information but I'm not sure if it belongs here - there are surely other places in the wiki that have the user write scripts, without mentioning it. :) - CodingKoopa (talk) 02:13, 9 December 2021 (UTC)
Should the article explicitly mention more security considerations?
Quoting an answer to Xephyr -ac dangerously?
- This also applies to any X server, not just Xephyr
Which is why I find it relevant for this talk page.
I haven't looked at how different display managers are starting X. Since a display manager is not mandatory, and some users can manage a multi user machine, I wonder if the xinit article should not have more pointers to security considerations. Regid (talk) 07:28, 6 April 2022 (UTC)
Dbus session not created "properly" in examples
After troubleshooting for hours on end, I finally found the reason why Firefox took 25+ seconds to start on modern hardware, without any noticeable resource usage. When starting window managers with `exec wm`, some dbus-specific envars don't get set. Instead, starting the window manager with `dbus-launch --exit-with-session wm` sets the envars. This should be noted in the Article.
Threads:
https://bbs.archlinux.org/viewtopic.php?pid=1737005#p1737005 (includes solution)
https://bbs.archlinux.org/viewtopic.php?id=275523 (points here, solution: not found)
Lyrics5135 (talk) 22:58, 9 March 2023 (UTC)
CORRECTION: The note in section 2.1 solves this issue, maybe include the code block in the page for better readability. Lyrics5135 (talk) 23:02, 9 March 2023 (UTC)