X server restart scripts--where do I put them?
-
Bernard's Cask
- Posts: 11
- Joined: Tue 20 Nov 2012, 10:48
X server restart scripts--where do I put them?
My Startup directory contains a 'xrandr --output LVDS --brightness 0.3' script. Brightness is reset to 1.0 on menu 'Restart X server'. How can I make brightness sticky? Where/what is the proper X profile for user/local use and I presume other (xrandr) directives?
-
Bernard's Cask
- Posts: 11
- Joined: Tue 20 Nov 2012, 10:48
Thank you mike for getting me back on track. This lappy is so sluggish in PUPMODE=12 that I had neglected to wait the minutes required for ~/Startup scripts to run--they do run on X restarts, I knew that! I deleted the modified .xinitrc and its .wh. and I've regained a sense of sanity. However, the backlight does remain default/bright for an annoying length of time. The .xinitrc AND rc.sysinit scripts are, I think, responsible for each taking a full 3-minutes longer in PUPMODE=12 over that of PUPMODE=5 (X restarts are fine in 5). Do you have any idea how I might trace/debug this annoyance? How do I output to a console from within these scripts? I thought there was a way to load personal save file and everything in RAM-drive with periodic writes to nvm? I know how to expand RAM-drive.
Hmm the last time I hacked puppy scripts was in Lucid but I assume recent ones are not that different.
Well there are certain areas that can be slow... the fairly useless rc.update, waiting for usb , wireless (but that backgrounded) and so on but in your case it sounds like its stuck on something thats been configured from the first run eg sound. The pupmode would not affect things so dramatically apart from anything saved (if that makes sense). Ie having a save triggers the problem rather than the save mode itself.
As for logging all you get is an echo of what you see already. Looking at dmesg (run in console) might give some clues (the kernel output)
One way might be to add your own logging ... eg echo 01 `date` >log.txt echo 02 `date` >> log ... strategically scattered and observe more precisely the slowdown point to narrow down the cause. In this example you would have a list of indexes and time stamps.
Another approach might be to boot pfix=ram, mount the save file and try deleting a setting and retest...see if you can eliminate the cause that way.
Plan C might be to test another puppy or if a recent one a later release as there have been some naughty bugs floating around.
mike
Well there are certain areas that can be slow... the fairly useless rc.update, waiting for usb , wireless (but that backgrounded) and so on but in your case it sounds like its stuck on something thats been configured from the first run eg sound. The pupmode would not affect things so dramatically apart from anything saved (if that makes sense). Ie having a save triggers the problem rather than the save mode itself.
As for logging all you get is an echo of what you see already. Looking at dmesg (run in console) might give some clues (the kernel output)
One way might be to add your own logging ... eg echo 01 `date` >log.txt echo 02 `date` >> log ... strategically scattered and observe more precisely the slowdown point to narrow down the cause. In this example you would have a list of indexes and time stamps.
Another approach might be to boot pfix=ram, mount the save file and try deleting a setting and retest...see if you can eliminate the cause that way.
Plan C might be to test another puppy or if a recent one a later release as there have been some naughty bugs floating around.
mike
-
Bernard's Cask
- Posts: 11
- Joined: Tue 20 Nov 2012, 10:48
I've traced my hang to /etc/profile line 50:
FIREFOX=$(find /usr/lib -type d -name firefox-*|tail -1) #slacko
This assignment, I presume the 'find' directive is the culprit, consumes 2min:44sec or more when executed after setup for PUPMODE=12. Is profile run twice, I didn't trap for repeats? Is there any significance to such a hang? Is perhaps a module for keyboard poll/interrupt setup different from PUPMODE=5 (I have a slightly failing keyboard)? I fruitlessly tried lhpup503 and I may have I had this trouble with Kanotix-live as well.
FIREFOX=$(find /usr/lib -type d -name firefox-*|tail -1) #slacko
This assignment, I presume the 'find' directive is the culprit, consumes 2min:44sec or more when executed after setup for PUPMODE=12. Is profile run twice, I didn't trap for repeats? Is there any significance to such a hang? Is perhaps a module for keyboard poll/interrupt setup different from PUPMODE=5 (I have a slightly failing keyboard)? I fruitlessly tried lhpup503 and I may have I had this trouble with Kanotix-live as well.
Hmm puppy does suffer from an overuse of find... a cause of initrd slowdowns is searching sub sub directories... all a bit silly really ... no other operating system seems to need to bury itself in such a way... what is wrong with the root of a drive?
Ok so if you don't have firefox then its is searching the whole of /usr/lib for nothing. That in itself should not be as slow as you describe though... perhaps test the command yourself in the terminal. In this case its trying to determine is presence to add its path so that some software can find its libraries. In the past its usually set as a one line statement and assumes firefox is in /usr/lib/firefox. A more consistant package arrangement would certainly avoid such hacky boot scripts. If you dont use firefox comment it out.
Profile is run once.
Is it a usb keyboard...if so there are some newer kernel messes to contend with since they chopped up the drivers.
Once a save is present scripts set the layout and time in files in /etc ... but that would not cause the problem you are having. You could check by running dmesg and see if there are any keyboard related messages.
mike
Ok so if you don't have firefox then its is searching the whole of /usr/lib for nothing. That in itself should not be as slow as you describe though... perhaps test the command yourself in the terminal. In this case its trying to determine is presence to add its path so that some software can find its libraries. In the past its usually set as a one line statement and assumes firefox is in /usr/lib/firefox. A more consistant package arrangement would certainly avoid such hacky boot scripts. If you dont use firefox comment it out.
Profile is run once.
Is it a usb keyboard...if so there are some newer kernel messes to contend with since they chopped up the drivers.
Once a save is present scripts set the layout and time in files in /etc ... but that would not cause the problem you are having. You could check by running dmesg and see if there are any keyboard related messages.
mike
-
Bernard's Cask
- Posts: 11
- Joined: Tue 20 Nov 2012, 10:48
I explicitly set FF dir in /etc/profile and seem to have reduced delay by 2min:44sec or greater while processing it. Odd that on one occasion of 'find' I didn't get any delay. Console FF 'find' works fine. Before (and now) upon boot there was (is) no apparent delay between jwm icons display and processing of /~/Startup, however upon restart of X from the menu, I have a few minutes of delay before /~/Startup is processed. I've noticed, and it must be a kludge, that /etc/profile runs twice upon restarting X from the menu. I know /etc/profile runs with console (something should). I haven't spent time reading kernel messages, yet, but the times seem to be in order. The /initrd/pup_rw/usr/lib has a couple dozen files and a few directories. Upon boot I'm getting minutes of delay prior to /etc/profile running and again after the notice of 'Starting X,... xorg.conf, ... startup apps .xinitrc...'. The rc.sysinit and .xinitrc were not problematic. This is all in PUPMODE=12. I think I'll compare dmesg with PUPMODE=5 boot.
-
Bernard's Cask
- Posts: 11
- Joined: Tue 20 Nov 2012, 10:48
Ah ok built in keyboard... would be ps/2 then... and sorry no clues on that one.
Profile should be run once when a terminal is launched...in this case the one X dangles off (which is inself is a bad hack). Only thought is you might be seeing the second terminal (ctrl-alt-f2) Only other time would be access by ssh for example.
X is supposed to be restarted on the original autologged in terminal but perhaps there have been some recent changes in that respect.
The delay for firefox hunting ...weird...only theory I had was that the union had not settled by then and causing a problem....
Otherwise there do seem to be hardware driver issues going on here which may even be the cause of all the slowdowns.... I heard that Sony can be awkward generally ... dmesg lists everything the kernel is doing or trying to do so might be the one to examine most closely.
And yes on that theory why do the delays occur AFTER a save is made??!!
More questions than answers..... perhaps there are others here with some insight....
mike
other suggestion...try another puppy eg lucid.
other idea...might need some boot parameter something like noacpi or similar..... hardware conflicts with kernel workarounds in other words.
Profile should be run once when a terminal is launched...in this case the one X dangles off (which is inself is a bad hack). Only thought is you might be seeing the second terminal (ctrl-alt-f2) Only other time would be access by ssh for example.
X is supposed to be restarted on the original autologged in terminal but perhaps there have been some recent changes in that respect.
The delay for firefox hunting ...weird...only theory I had was that the union had not settled by then and causing a problem....
Otherwise there do seem to be hardware driver issues going on here which may even be the cause of all the slowdowns.... I heard that Sony can be awkward generally ... dmesg lists everything the kernel is doing or trying to do so might be the one to examine most closely.
And yes on that theory why do the delays occur AFTER a save is made??!!
More questions than answers..... perhaps there are others here with some insight....
mike
other suggestion...try another puppy eg lucid.
other idea...might need some boot parameter something like noacpi or similar..... hardware conflicts with kernel workarounds in other words.