You could also try dm, since display managers usually have this in their name ( gdm, etc). If nothing turns up, try ps -fA | grep X this one involves more clutter.įinally, if there is no process with capital X in its name, try x you may at least find commands used to control it, such as startx or xinit. If this is 0, then the process is running root. This removes the column headers, but the UID is the numerical one on the left. Since it almost certainly at least has capital X in it (e.g., Xorg, X11), an alternative is to filter through grep: ps -o uid,comm -A | grep X This presumes that the executable is called X - if there's no such process, you will have to target something else. Will give you information for all the X servers that are running (there can be more than one). Whether that will be Antix 17 or Debian Stretch with or without systemd stuff or something else entirely remains to be seen.There are a few ways to output the user ID (UID) with ps a simple one is with -f: ps -fC X My Wheezy system is headed for End Of Life May 2018, and I want to get a replacement system installed and ready to go by that time. True, I don't boot to a terminal, but I'm just testing and evaluating now. But for now I installed lightdm, and X and Openbox load and work fine after logging in. I've had similar"problems" happen before. I mentioned in another reply that this startx problem could be a VirtualBox glitch. It's likely that the problem boils down to some of those files having the wrong ownership or permissions. It generates a copious list of all system calls which will show all the files that are being accessed. Another approach is to run Xorg with the strace command. Having similar systems that work may make debugging easier.
My hope is that maybe most of this can be fixed with a well-placed chown -R or chmod -R command. I personally use startx instead of a display manager and what you want is in accord with the antiX"lean and mean" motto. And to be as"light' and fast as possible.
#Startx only runs as root install#
I don't want to install a display manager as I want the system to boot to a standard terminal and not X as many times I only need a terminal. Traditional Desktops which I abandoned about 6 years ago are such leviathans and CPU gluttons, and no more useful than a good window manager and a single panel.
I've tested Stretch in VirtualBox under numerous configurations - systemd init, sysv and runit inits with and without systemd components - installed the same way as I did Antix and never experienced any startx problems. My thinking now is this startx failure is an Antix 17 Beta glitch and not an upstream Debian Stretch or xorg problem. Although, I don't think the bug report applies (and it's a year old), but I'll read it more thoroughly later. Thanks for your quick response, advice and the bug link.
You can probably explore this further but it might be faster/easier to install slim or lightdm or some other display manager that you can start as an init.d service. I think the problem is upstream with Debian and/or X.org and/or. Code: Select all sudo chmod u+x /usr/bin/Xorgīut that didn't change anything.