[SOLVED] suspend workaround

[jur]

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.

[curaga]

su tc -c startx


btw which error? Is a driver update needed?

[jur]

The problem that was discussed in this thread, last page.
http://forum.tinycorelinux.net/index.php?topic=6326.45

[curaga]

Hmm, that was kernel-related. And according to the Fedora bug, still appears.

[jur]

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.

[^thehatsrule^]

You might want a login env, i.e. by passing -l

[dentonlt]

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

[jur]

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?

[^thehatsrule^]

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.

[maro]

jur: In this kind of situation I find it helpful to establish the full process tree:

• either via the 'F5' option of 'htop' (available via the 'htop.tcz' extension), or
• running ps -efH with the 'procps.tcz' extensions installed, or
• by using ps -o 'pid,ppid,user,args' with the BusyBox applet and working out the relationships of the processes in question.

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.

[jur]

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


[tinypoodle]

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.

[maro]

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'

[jur]

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?

[jur]

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.