[SOLVED] Moved Topic - 'startx' continual (for years) intermittent failure

jr_bob_dobbs · 12-07-2019, 05:56 PM

Crazy thought: an innocous setting in an old config file causing problems now? Something in your home directory?

Here is a thing to try that should be safe:

Make a new user. Add him[1] to the audio and video groups.

Log out, then log in to this new user. Then type startx. If xorg starts fine, that tells you something.

--
1. Everyone is a him

jrch · 12-08-2019, 01:44 PM

Tried the modification to .xinitrc suggested by Gazl. Then, startx worked first time for several launches; however next day (today) startx is back to the 2-3 step, on at least two machines running Slackware64 14.2 / multilib.
I then modified the system .xinitrc file in /etc/X11/xinit (a link to xinitrc.xfce, which file is the one I modified). Worked once or twice, then back to same behavior.
Darn - had hopes.

So Question - Gazl: When you say 'boot to init 1' are you suggesting runlevel 1? Or using something else?

thx, jrc

upnort · 12-08-2019, 02:18 PM

One constant seems to be Xfce. While the problem has affected you for several years and has affected me for only some weeks and only intermittently, I could have changed something in Xfce that now matches your Xfce configurations.

Quote:

Everyone is a him

Hazel probably would disagree. Pronouns are easy to avoid:

Make a new user. Add the user to the audio and video groups.

GazL · 12-08-2019, 07:33 PM

Quote:

Originally Posted by jrch

So Question - Gazl: When you say 'boot to init 1' are you suggesting runlevel 1? Or using something else?

thx, jrc

I think you're misattributing that quote. I never mentioned init. And no, runlevel 1 does'nt sound very useful to me.

jrch · 12-09-2019, 11:56 AM

Gazl - my apology. It was 'upnort' who suggested that,

[upnort] quote (another user): I notice that a socket exists in /tmp/.ICE-unix

"I configure /tmp to tmpfs, so on my system the socket file is always deleted on reboot/halt. Yet I intermittently see the reported problem on my laptop. Perhaps the OP might want to look at that -- boot to init 1 and delete everything in /tmp if not using tmpfs."

---
upnort:

Have to admit I'm confused about doing this. I'm not sure what 'deleting everything in /tmp' will do to my system.... that's where all the finished SlackBuilds go, before installpkg ..
and what else ... (?)

I've not heard of '/tmpfs', but found a discussion on wikipedia, so will try to learn what all that is..

ok, I find using 'df', three instances of tmpfs...

Filesystem Mounted on

devtmpfs ..... /dev
tmpfs ......... /run
tmpfs ....... /dev/shm

Not sure how I configure it to do something else...

jrc

upnort · 12-09-2019, 02:02 PM

Here is the related /etc/fstab snippet needed for using tmpfs:

tmpfs /tmp tmpfs defaults,noatime 0 0

Add that to /etc/fstab. Do not yet reboot. Instead drop to runlevel 1 (init 1). Delete all files and subdirectories in /tmp, but keep the parent /tmp.

Reboot.

Because your system boots to runlevel 3, do not immediately start X with startx. Verify /tmp is using tmpfs using mount or df. With each fresh boot notice the time stamps change on all /tmp files and subdirectories, confirming everything goes to the bit bucket on reboot/halt.

Regarding SBO packages, the default in SBo scripts is OUTPUT=${OUTPUT:-/tmp}. If desiring to retain build files then change $OUTPUT environment variable to something other than /tmp. Perhaps /var/tmp. Do this in an appropriate bash startup file (/etc/bashrc, ~/.bashrc, etc.)

If you do not want to use tmpfs and still want to clean /tmp, drop to runlevel 1, delete the files, reboot. Or use a live ISO to clean the directory.

Or throw something like this is rc.local_shutdown:

Code:

# Delete files older than 9 days.
find /tmp -type f -mtime +9 -exec rm -f {} \;
# Delete directories older than 9 days.
find /tmp -type d ! -name lost+found -mtime +9 -exec rm -rf {} \;

I hope that helps.

jrch · 12-11-2019, 06:18 AM

upnort,

thanks for the explanation. -jrc

upnort · 12-11-2019, 08:10 AM

I restored my xinitrc files but thus far no repeat of the described problem. Curiouser and curiouser.

upnort · 12-11-2019, 01:16 PM

Perhaps a clue. I was able to produce the error. Fresh cold boot.

In the user's .xsession-errors log:

Code:

(wrapper-1.0:3796): Gtk-WARNING **: cannot open display: :0.0

(nm-applet:3523): Gdk-WARNING **: nm-applet: Fatal IO error 0 (Success) on X server :0.0.

xfwm4: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.0.
parcellite: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.0.
mate-typing-monitor: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.0.
XIO:  fatal IO error 11 (Resource temporarily unavailable) on X server ":0.0"
      after 25 requests (25 known processed) with 0 events remaining.
xfce4-panel: Fatal IO error 4 (Interrupted system call) on X server :0.0.
xfce4-session: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.
Thunar: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.0.
The application 'xfsettingsd' lost its connection to the display :0.0;
most likely the X server was shut down or you killed/destroyed
the application.

OK, X failed to start.

Looking in /var/log/Xorg.0.log:

Code:

[    25.585] (EE) Failed to load module "fbdev" (module does not exist, 0)
[    27.538] (EE) 
[    27.538] (EE) Backtrace:
[    27.544] (EE) 0: /usr/libexec/Xorg (xorg_backtrace+0x41) [0x580701]
[    27.544] (EE) 1: /usr/libexec/Xorg (0x400000+0x184629) [0x584629]
[    27.544] (EE) 2: /lib64/libpthread.so.0 (0x7fd3826e0000+0x113b0) [0x7fd3826f13b0]
[    27.544] (EE) 3: /usr/lib64/libpixman-1.so.0 (pixman_region_fini+0x9) [0x7fd383142ac9]
[    27.544] (EE) 4: /usr/lib64/xorg/modules/drivers/intel_drv.so (0x7fd37dc9c000+0x5f396) [0x7fd37dcfb396]
[    27.544] (EE) 5: /usr/lib64/xorg/modules/drivers/intel_drv.so (0x7fd37dc9c000+0x5d041) [0x7fd37dcf9041]
[    27.544] (EE) 6: /usr/libexec/Xorg (0x400000+0x10bf9d) [0x50bf9d]
[    27.544] (EE) 7: /usr/libexec/Xorg (0x400000+0x102661) [0x502661]
[    27.544] (EE) 8: /usr/libexec/Xorg (0x400000+0x34d5f) [0x434d5f]
[    27.544] (EE) 9: /usr/libexec/Xorg (0x400000+0x38c43) [0x438c43]
[    27.544] (EE) 10: /lib64/libc.so.6 (__libc_start_main+0xf0) [0x7fd380d227d0]
[    27.544] (EE) 11: /usr/libexec/Xorg (_start+0x29) [0x4242a9]
[    27.544] (EE) 
[    27.544] (EE) Segmentation fault at address 0x0
[    27.544] (EE) 
[    27.544] (EE) Caught signal 11 (Segmentation fault). Server aborting
[    27.544] (EE) 
[    27.544] (EE) 
[    27.544] (EE) Please also check the log file at "/var/log/Xorg.0.log" for additional information.
[    27.544] (EE) 
[    27.620] (EE) Server terminated with error (1). Closing log file.

Of course, running startx immediately after the failure launches X just fine.

As I mentioned previously, if I wait a couple of seconds before logging in and running startx I have yet to duplicate the error. My guess is if I am fast enough during boot, I am able to attempt starting X before some kind of boot or login dependency has launched or terminated.

Ideas? Speculations?

jrch · 12-12-2019, 10:59 AM

upnort, quick question: Sorry for my ignorance.

I'm a bit paranoid sometimes, because I have proved I can break almost any software quickly by screwing around.

So I'm not sure what exactly is meant by 'drop to init 1'. Looking in the 'Slackware Essentials' book, I find that '/etc/rc.d/rc.K' initiates runlevel 1. So am I correct in going to root, then executing 'rc.K' ?

Thanks for education...

jrc

TheRealGrogan · 12-12-2019, 12:22 PM

If you want to "drop" down to init 1 (runlevel 1), simply type "init 1" as root. If you want to boot to runlevel 1, append 1 to your kernel command line.

For example, if I'm using Lilo and my Slackware boot entry is titled "Slackware" instead of just hitting enter to boot I'd type

Slackware 1

If using Grub, you'd have to press e to edit command line and simply append a 1 to your kernel line and boot with it.

upnort · 12-12-2019, 01:59 PM

Quote:

I'm not sure what exactly is meant by 'drop to init 1'.

What TheRealGrogan said.

Quote:

I'm a bit paranoid sometimes, because I have proved I can break almost any software quickly by screwing around.

I've been using desktop computers since 1982. I break things almost every day. I'm just not paranoid about that.

jrch · 12-13-2019, 10:51 AM

Thanks. I learn a lot on here.
jrc

jrch · 12-13-2019, 01:43 PM

OK, my /etc/fstab on all Slackware 14.2 machines already has a (last) line for tmpfs:

tmpfs /dev/shm tmpfs defaults 0 0

so do I add a 2nd line below for tmpfs (more) ? Or somehow meld it into this line?

I tried to read the manpage, unsuccessfully.

The reason I get concerned about making mistakes is because I really hate reinstalling the whole system and backups. It takes a good bit of time and effort.

Thanks for help,

jrc

upnort · 12-13-2019, 06:55 PM

Quote:

The reason I get concerned about making mistakes is because I really hate reinstalling the whole system and backups. It takes a good bit of time and effort.

Rarely is reinstalling necessary. Even a big fat finger mistake in /etc/fstab that prevents booting is quickly remedied using a live ISO. The Slackware install DVD can be used as a live ISO.