Tiny Core Linux

Tiny Core Base => TCB Q&A Forum => Topic started by: jur on October 29, 2010, 09:11:28 PM

Title: [SOLVED] suspend workaround
Post by: jur on October 29, 2010, 09:11:28 PM
I'd like to do a poor man's suspend to ram. The reason is to work around the problem of the Xorg page render error

So the plan is
Code: [Select]
killall Xorg
echo "mem" > /sys/power/state
startx;;
but when coming out of suspend, Xorg starts as root.

How can I execute startx as user tc?

[edit] this scripts is executed by acpid so is root.
Title: Re: suspend workaround
Post by: curaga on October 30, 2010, 04:30:52 AM
su tc -c startx


btw which error? Is a driver update needed?
Title: Re: suspend workaround
Post by: jur on October 30, 2010, 06:27:23 AM
The problem that was discussed in this thread, last page.
http://forum.tinycorelinux.net/index.php?topic=6326.45
Title: Re: suspend workaround
Post by: curaga on October 30, 2010, 07:44:00 AM
Hmm, that was kernel-related. And according to the Fedora bug, still appears.
Title: Re: suspend workaround
Post by: jur on October 30, 2010, 05:03:16 PM
I am closer to a good solution but it's not there yet.

When I do su tc -c startx, it no longer starts as root but is still not the same as manually running startx from the prompt after resuming from suspend. The prompts is not the same, lacking tc@box, and the path excludes  .local/bin and /OnDemand.

Any tips how to resolve this?

I agree that the bug is probably kernel-related, as I sill see the page render error message but it no longer hangs, instead it manages to make it to the terminal screen (is that what it is called?). From there I can type startx and have a perfectly working X as after a boot.

Actually this workaround seems even better as suspend from X as there is less to store and the ram gets cleared etc, so it is like a mega-fast boot.
Title: Re: suspend workaround
Post by: ^thehatsrule^ on October 31, 2010, 01:43:13 AM
You might want a login env, i.e. by passing -l
Title: Re: suspend workaround
Post by: dentonlt on October 31, 2010, 03:32:40 AM
Just an echo - I get the same results as Curaga (http://forum.tinycorelinux.net/index.php?topic=6326.45)

If you do work this out, I'd like to know. I'm using Xvesa for the time being.

DLT
Title: Re: suspend workaround
Post by: jur on October 31, 2010, 07:44:55 AM
Right, using -l helped a bit...
Now there's a new problem: Several of my .X.d stuff is loading several times, conky, tint2 and volumeicon.

Code: [Select]
11252 root     /usr/local/bin/Xorg -nolisten tcp -dpi 86
11269 tc       openbox
11295 tc       conky
11296 tc       tint2
11298 tc       volumeicon
11610 tc       conky
11611 tc       tint2
11615 tc       volumeicon
11650 tc       wbar -bpress -p right -vbar -config /usr/local/tce.icons

I wonder if this is a bug of sorts with the .X.d routines?
Title: Re: suspend workaround
Post by: ^thehatsrule^ on October 31, 2010, 04:08:59 PM
hmm... I think that might be due to the login part which would also try to run x.  Maybe don't startx?

Using sudo could be another alternative.
Title: Re: suspend workaround
Post by: maro on October 31, 2010, 06:00:09 PM
jur: In this kind of situation I find it helpful to establish the full process tree: The interesting question is whether each set of processes started via '~/.X.d' are having a common ancestor.

AFAIK the '~/.X.d' startup happens in '~/.xsession', which gets executed along the way from 'startx' and accounts for the start of the X server, the WM and the (optional) '~/.X.d/' apps. So I was wondering whether it is possible that you ran 'startx' once and when you only kill the X server there might be still other processes left over (even though I could not produce that situation myself with my quick test using a QEMU VM). Anyway the process tree might give an answer to that question.
Title: Re: suspend workaround
Post by: jur on October 31, 2010, 06:31:55 PM
I am none the wiser... should there be two udevd running? There are one or two more items which also seem double.

I can actually see the two startx instances executing - wbar also acts like it is being restarted.
Code: [Select]
19903    96 root     /sbin/udevd --daemon
19904    96 root     /sbin/udevd --daemon
20117     1 root     /usr/local/bin/Xorg -nolisten tcp -dpi 86
20134     1 tc       openbox
20161     1 tc       tint2
20171     1 tc       volumeicon
20409     1 tc       volumeicon
20414     1 tc       conky
20415     1 tc       tint2
20453     1 tc       wbar -bpress -p right -vbar -config /usr/local/tce.icons
Title: Re: suspend workaround
Post by: tinypoodle on October 31, 2010, 06:45:45 PM
I always see 3 udev PIDs running (TC 2.10), 2 of them being child processes of the other one.
That's why I also would recommend the method Maro already mentioned using htop, in order to have the process tree visually represented.
Title: Re: suspend workaround
Post by: maro on October 31, 2010, 07:26:24 PM
I've seen enough situations like this (before killing a process):
Code: [Select]
PID  PPID COMMAND
   1    0 init
 100    1 sh
 101  100 parent
 102  101 child
 103  102 grandchild
And after killing the parent process this changed to:
Code: [Select]
PID  PPID COMMAND
   1    0 init
 100    1 sh
 102    1 child
 103  102 grandchild
So you better start from scratch and produce before and after each significant step a snapshot of the process tree.

I don't think you can easily produce a snapshot of 'htop', so either use the BusyBox method or (better) use 'procps.tcz'
Title: Re: suspend workaround
Post by: jur on October 31, 2010, 07:44:04 PM
Using htop tree, each of those 3 .X.d doubles are not children - each hangs off the trunk.

I think ^thehatsrule^ is onto something - it seems to do with the -l argument in su. I have a vague feeling startx or some part of the process is executed twice. But if I leave out startx, stops at the terminal screen. I need to issue a dummy command:

Code: [Select]
su tc -c -l startx
results in the doubles.
Code: [Select]
su tc -c -l exec .xsession
results in X starting but ending up with black screen, X cursor. Ctrl-alt-bksp to exit X, then it automatically starts x correctly.

So is there a null command I can use instead of startx?

Title: Re: suspend workaround
Post by: jur on October 31, 2010, 07:56:03 PM
Confirmed.

If I do
Code: [Select]
su -c -l ls, then the desktop starts correctly.

So I have to issue some harmless command, I tried ls, but I'd like to do something even more harmless such as a putative null command which takes no execution time.
Title: Re: [SOLVED] suspend workaround
Post by: jur on October 31, 2010, 08:12:25 PM
Right, I have it working to my satisfaction:


Code: [Select]
killall Xorg
echo "mem" > /sys/power/state
su tc -c -l echo

that code is executed by the sleep button routine, in my case acpid.
Title: Re: [SOLVED] suspend workaround
Post by: curaga on November 01, 2010, 08:06:03 AM
We need an extension for psmisc. All the other process tree options were pretty complicated compared to "pstree" ;)
Title: Re: [SOLVED] suspend workaround
Post by: maro on November 01, 2010, 08:16:52 AM
Quote from: curaga on November 01, 2010, 08:06:03 AM
We need an extension for psmisc. All the other process tree options were pretty complicated compared to "pstree" ;)
So very true, if 'pstree' would have been available I would mentioned it probably as the one and only option ... 
Title: Re: [SOLVED] suspend workaround
Post by: tinypoodle on November 01, 2010, 01:16:22 PM
Quote from: maro on November 01, 2010, 08:16:52 AM
Quote from: curaga on November 01, 2010, 08:06:03 AM
We need an extension for psmisc. All the other process tree options were pretty complicated compared to "pstree" ;)
So very true, if 'pstree' would have been available I would mentioned it probably as the one and only option ... 
I had actually done a search in repo for 'pstree' while reading this thread and was slightly surprised to find it does not exist.