log-file of bootproces


Forum: Other Help Topics
Topic: log-file of bootproces
started by: Ruthje

Posted by Ruthje on Sep. 19 2005,13:01
I'm using a fugal install of dsl for a mp3box. Problem is that is doesn't haven a monitor because I control it using ssh. Now I'm playing around with some options in bootlocal.sh to let it autostart playing. But because of the misssing monitor i cannot see a error when it isn't working. So I thougt maybe there is a logfile somewhere?
Posted by SaidinUnleashed on Sep. 19 2005,13:51
dmesg|less

Yarr, ye need to be learnin' the search function, matey.

-Dread Pirate J.P.

Posted by Ruthje on Sep. 19 2005,13:58
I tried the searchfunction and most times i find my answer there. But this log doesn't show what is happenning with the commands in bootlocal.sh?
Posted by SaidinUnleashed on Sep. 19 2005,14:32
Narr. The bootlocal script is run after the bootin' be done.

Try commentin' out the stuff you be havin' errors with, and run the commands from an Xterm, so you can be seein' yer errors.

-Dread Pirate J.P.

Posted by mikshaw on Sep. 19 2005,14:36
One thing you could do, if you are concerned only with what is happening from bootlocal.sh:
Rename bootlocal.sh to something_else.sh
Create a new empty bootlocal.sh
Add the command "something_else.sh &>/home/dsl/bootlocal.log"

Another thing is to boot with the "syslog" option.  I don't know how much will be logged, but whatever it is would be written to /var/log/messages

Posted by clivesay on Sep. 19 2005,14:55
bookmark
Posted by Ruthje on Sep. 19 2005,15:02
Quote (mikshaw @ Sep. 19 2005,10:36)
One thing you could do, if you are concerned only with what is happening from bootlocal.sh:
Rename bootlocal.sh to something_else.sh
Create a new empty bootlocal.sh
Add the command "something_else.sh &>/home/dsl/bootlocal.log"

Just tried, but the opt folder isn't backed up so goodbye old bootlocal.sh So I am writing new bootlocal now, wil rename it and back it up this time and give it an other shot.

Posted by mikshaw on Sep. 19 2005,19:34
Ah, yes...I should have added "back up both files".
Also, I should mention that bootlocal should have "#!/bin/sh" as its first line, so the new bootlocal would be:
Code Sample
#!/bin/sh
/opt/something_else.sh &>/home/dsl/bootlocal.log

...and it should be executable, too.

So....maybe a more simple explaination would be:
1) make a copy of /opt/bootlocal.sh
2) edit the original bootlocal so the only command is
/opt/new_bootlocal.sh &>/home/dsl/bootlocal.log
3) back up both files

This basically just sends all output from your script to a log file.  It's a roundabout way, but I figured it would be simpler than redirecting every individual bootlocal command to a file.

Posted by Ruthje on Sep. 20 2005,14:01
ok the logfile is working and simple commands give a output, but not the command I want to perform.
I'm using screen in my command and I think that is the reason.
Anyway it seems I just made a simple type error somewhere, because it is autoplaying in a screen at the moment.
Waiting for the computer to reboot everytime takes a long time :(
For the people who a interrested this is the command I was debugging.
screen -S mp3 mp3blaster -a /home/dsl/3voor12.lst
Thanx for the help

Posted by mikshaw on Sep. 20 2005,15:25
Since screen is a whole other system of shells, it's possible that the output is being controlled by screen rather than being sent to stdout/stderr.  Just guessing as usual =o)

Just out of curiosity...if it's just a headless jukebox, why use screen?

Posted by Ruthje on Sep. 20 2005,17:48
Quote (mikshaw @ Sep. 20 2005,11:25)
Since screen is a whole other system of shells, it's possible that the output is being controlled by screen rather than being sent to stdout/stderr.  Just guessing as usual =o)

Just out of curiosity...if it's just a headless jukebox, why use screen?

I control the box from a windows pc with putty over ssh and with screen I don't have to keep putty open all the time. I thought it was working now but the commands in bootlocal are being executed bij root so to return to the screen I also have to be root. This is not a big problem, but not the way I want it so I'll keep trying  :D
Posted by mikshaw on Sep. 20 2005,18:12
I think you can execute it from bootlocal with "su dsl -c screen ...".  

Another option might be to return /.bash_profile to it's original state of automatically logging in as dsl (if you are running in runlevel 5), and start screen from /home/dsl/.bash_profile (in place of startx). From my experience with screen in DSL, you'll need to make sure that /dev/tty1 has write permission by either user 'dsl' or group 'staff', if you haven't already done this.

Posted by Ruthje on Sep. 21 2005,10:51
Quote (mikshaw @ Sep. 20 2005,14:12)
I think you can execute it from bootlocal with "su dsl -c screen ...".
 
I tried that but get this error:
Cannot open your terminal '/dev/console' - please check.^M
Quote (mikshaw @ Sep. 20 2005,14:12)
Another option might be to return /.bash_profile to it's original state of automatically logging in as dsl (if you are running in runlevel 5), and start screen from /home/dsl/.bash_profile (in place of startx).

I'm to much linux-newbie to understand what you are saying here. But I'll find out
Quote (mikshaw @ Sep. 20 2005,14:12)
From my experience with screen in DSL, you'll need to make sure that /dev/tty1 has write permission by either user 'dsl' or group 'staff', if you haven't already done this.

I have read this earlier but never had problems with that, but maybe I'm having them now. ???

Posted by mikshaw on Sep. 21 2005,16:41
I think the /.bash_profile thing would be a non-issue for you if you didn't change it yourself (or are you running a multi-user setup?).  I'm guessing you have been running screen as root?

The permission problem is likely due to root being automatically logged in on tty1, so root takes ownership of it.  The only ways i know how to deal with it is to force the ownership of the tty to dsl or staff, or use screen as root, or set up your system with a login prompt instead of auto-login.

Powered by Ikonboard 3.1.2a
Ikonboard © 2001 Jarvis Entertainment Group, Inc.