Find the answer to your Linux question:
Results 1 to 7 of 7
Hey, First post! I have been using Linux for a number of years, but still see my self as a novice. While working with a server, trying to reduce CPU ...
Enjoy an ad free experience by logging in. Not a member yet? Register.
  1. #1
    Just Joined!
    Join Date
    Jan 2013
    Posts
    4

    screen command in startup bash script - why?


    Hey,

    First post!

    I have been using Linux for a number of years, but still see my self as a novice.

    While working with a server, trying to reduce CPU load I stumbled a cross a script executed at boot.

    The bash script starts a program in a detached screen (screen -D -m -S <program command incl. otption>). The program is a key process to the server, but does not need to be run in a detached screen.

    I can see the benefit if I want to see the process running (doing it's stuff) but because I am trying to reduce load I see no reason during "production".

    What other purpose can there be for doing this?

    Cheers,
    Mik
    Last edited by mikulator; 01-04-2013 at 09:12 AM.

  2. #2
    Trusted Penguin
    Join Date
    May 2011
    Posts
    4,353
    Hello and welcome!

    The screen utility is great for running a process "in the background" that does not otherwise like being daemonized. Also/more importantly, it allows user interaction with the program running in the terminal, if that is required. To attach to the session, you just do:
    Code:
    screen -r <SCREEN_NAME|PID>
    but maybe you already know that. I don't think you will buy back much by removing screen from the equation, though.

    If you determine that it is not required, I guess you could just throw it into the background with a "&". Or if you are using a Red Hat based distro, you could try leveraging the work done in /etc/init.d/functions to daemonize your process. Take a look at the scripts in /etc/init.d/ to see what I mean.

  3. #3
    Just Joined!
    Join Date
    Jan 2013
    Posts
    4
    Hey atreyu!

    Thanks for your answer.

    Prior to your answer I tested the difference between running the process under screen or as a daemon - and as you write there is very little/no difference.

    The person who wrote the script uses "screen" and "&" which I guess seems strange - here is the line:

    Code:
    eval "screen -D -m -S view $PRG $OPTIONS $LOG &"
    Cheers
    Mik

  4. #4
    Trusted Penguin
    Join Date
    May 2011
    Posts
    4,353
    Quote Originally Posted by mikulator View Post
    The person who wrote the script uses "screen" and "&" which I guess seems strange - here is the line:

    Code:
    eval "screen -D -m -S view $PRG $OPTIONS $LOG &"
    I agree that that is strange. Why would you throw a command into the background in a screen? Defeats the purpose of screen. I don't see why eval is being used, either.

  5. #5
    Just Joined!
    Join Date
    Jan 2013
    Posts
    4
    I suspect the "eval" is used to pick up the pid or error code...

    My plan is to remove this from the script as well asthe other bits.

  6. #6
    Trusted Penguin
    Join Date
    May 2011
    Posts
    4,353
    Quote Originally Posted by mikulator View Post
    I suspect the "eval" is used to pick up the pid or error code...
    Oh, now that I look at it again, I think it is so that the args to the command will be picked up. another way, w/o eval might be:
    Code:
    screen -D -m -S view "$PRG $OPTIONS $LOG &"
    but that's just a guess.

    My plan is to remove this from the script as well asthe other bits.
    There's one thing you might want to think about: I see that $LOG is passed as an option to the program. I guess this means all command output (that is, STDOUT, or standard output) goes to whatever file is defined by $LOG. The question is: does that include STDERR? If not, then your screen terminal would have that info. If you drop screen, and don't account for STDERR, then you could possibly lose helpful diagnostic info, when things go bad.

    Here is an example in bash of how to capture both STDOUT (file descriptor 1) and STDERR (file descriptor 2) to the same log file:

    Code:
    command > /tmp/logfile.log 2>&1
    or to separate logs:
    Code:
    command 1>/tmp/output.log 2>/tmp/output.err
    try running this command to see what I mean about STDERR:
    Code:
    ls /path/that/does/not/exist 1>/dev/null
    If you ran that in your screen terminal, then in the terminal you'd have:
    Code:
    ls: cannot access /path/that/does/not/exist: No such file or directory
    but if you removed screen and $LOG does not capture STDERR, you'd lose that info.

  7. #7
    Just Joined!
    Join Date
    Jan 2013
    Posts
    4
    good point. It will not pass the STDERR for the eval command. This I would want to be a part of the log for the startup script.

    I will put that in.

    The $LOG simply is a reference to where the log file is to be located for the $PRG.

    Cheers,
    Mik

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •