rc.local not start at the boot

[Bill Davidsen]

Angelo Moreschini wrote:
> I would say that this thread is the continuation of a my preceding thread :
>
> “selecting some kind of files using the resync command”
>
>
> There I got help in order to make the backup of some my critical files.
>
> Now I am able to backing up these files using a shell script from the line command.
>
> But I would like also that this backup runs automatically when the computer boots.
>
>
> I know that this task is performed by the rc.local file, in Linux.
>
> Ed Greshko gave me a link about an announcement of Fedora concerning rc.local ....
>
> there is wrote :
>
> - - - - - - - - - -
>
> The |/etc/rc.d/rc.local| local customization script is no longer included by
> default. Administrators who need this functionality merely have to create this
> file, make it executable, and it will run on boot.
>
> - - - - - - - - - -
>
>
> After I read this announcement, I create the the file rc.local and I made it
> executable:
>
> [angelo_dev at zorro rc.d]$ ls -l /etc/rc.d/rc.local
>
> -rwxr-xr-x. 1 root root 1262 Oct 27 12:18 /etc/rc.d/rc.local
>
>
> But, doing some tests, I saw that the scripts stored inside rc.local not run at
> boot, ...on my computer.
>
>
> I would like to have some advice concerning the way to manage tests, in order to
> understand because the content of rc.local is not executed at the start... and
> toobtain thatscripts run atthe boot
>
Having followed the thread as of the time of this message, a few comments about 
scripts and such.

1 - redirection
   You don't need to do separate redirects to put everything in the same place,
   exec &>/tmp/rc.local.log
   will do it, and make it clear what your doing. Interestingly, if you are
   running from a terminal, you can "echo foo >&0" and still write the terminal
   as long as STDIN is the terminal.
2 - directories
   When you run a command, script or not, you may not be in the directory you
   expect, or have the right PATH. When running from rc.local, you will be
   starting as root (unless you use su) in /root, using the root PATH.
   The trick is to force a login as yourself:
     su -c 'My cmd1; My cmd2' >My_log_optional - My-username
   This will get you in your usual login directory, PATH, and UID.
3 - more on directories and PATH
   when you run a command with the 'batch' or 'at' commands, they
   start in the current directory, and in most cases the current
   PATH and UID.

   Sometimes when I create working files, logs, command output, I want
   to save for a few days. I use the 'at' command to delete them in a few days
   so I leave less clutter if I don't use them. Starting in the current
   directory is a benefit if you remember it will happen.
4 - logging
   For crying out loud use the damn logger command to log stuff like
   rc.local:
     logger -t rc.local Started
     # or on commands, use || to log fails:
     My_cmd1 || logger -t rc.local "My_cmd1 exit with $! status"
     # and when done:
     logger -t rc.local "Complete, reached end"
   Then you have a trail in the system log which you can find:
     grep rc.local /var/log/messages
   You can still put errors from a command in a file of its own, if
   that provides documentation, but the note in the log remains you
   it failed.

Hope this is going to help the original problem and some others as well.


-- 
Bill Davidsen <davidsen at tmr.com>
   "We have more to fear from the bungling of the incompetent than from
the machinations of the wicked."  - from Slashdot