WelcomeWelcome | FAQFAQ | DownloadsDownloads | WikiWiki

Author Topic: [SOLVED] suspend workaround  (Read 5588 times)

Offline jur

  • Hero Member
  • *****
  • Posts: 863
    • cycling photo essays
[SOLVED] suspend workaround
« 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.
« Last Edit: October 31, 2010, 08:10:18 PM by jur »

Offline curaga

  • Administrator
  • Hero Member
  • *****
  • Posts: 11044
Re: suspend workaround
« Reply #1 on: October 30, 2010, 04:30:52 AM »
su tc -c startx


btw which error? Is a driver update needed?
The only barriers that can stop you are the ones you create yourself.

Offline jur

  • Hero Member
  • *****
  • Posts: 863
    • cycling photo essays
Re: suspend workaround
« Reply #2 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

Offline curaga

  • Administrator
  • Hero Member
  • *****
  • Posts: 11044
Re: suspend workaround
« Reply #3 on: October 30, 2010, 07:44:00 AM »
Hmm, that was kernel-related. And according to the Fedora bug, still appears.
The only barriers that can stop you are the ones you create yourself.

Offline jur

  • Hero Member
  • *****
  • Posts: 863
    • cycling photo essays
Re: suspend workaround
« Reply #4 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.

Offline ^thehatsrule^

  • Retired Admins
  • Hero Member
  • *****
  • Posts: 1726
Re: suspend workaround
« Reply #5 on: October 31, 2010, 01:43:13 AM »
You might want a login env, i.e. by passing -l

Offline dentonlt

  • Sr. Member
  • ****
  • Posts: 318
    • the trombone analog
Re: suspend workaround
« Reply #6 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

Offline jur

  • Hero Member
  • *****
  • Posts: 863
    • cycling photo essays
Re: suspend workaround
« Reply #7 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?

Offline ^thehatsrule^

  • Retired Admins
  • Hero Member
  • *****
  • Posts: 1726
Re: suspend workaround
« Reply #8 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.

Offline maro

  • Hero Member
  • *****
  • Posts: 1228
Re: suspend workaround
« Reply #9 on: October 31, 2010, 06:00:09 PM »
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.

Offline jur

  • Hero Member
  • *****
  • Posts: 863
    • cycling photo essays
Re: suspend workaround
« Reply #10 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

Offline tinypoodle

  • Hero Member
  • *****
  • Posts: 3857
Re: suspend workaround
« Reply #11 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.
"Software gets slower faster than hardware gets faster." Niklaus Wirth - A Plea for Lean Software (1995)

Offline maro

  • Hero Member
  • *****
  • Posts: 1228
Re: suspend workaround
« Reply #12 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'

Offline jur

  • Hero Member
  • *****
  • Posts: 863
    • cycling photo essays
Re: suspend workaround
« Reply #13 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?


Offline jur

  • Hero Member
  • *****
  • Posts: 863
    • cycling photo essays
Re: suspend workaround
« Reply #14 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.