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_number
option 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-x11
leads to/usr/lib/deepin-daemon/dde-system-daemon
being 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)