Adding start up script in rcX.d --> Via update-rc SCRIPT defaults .... :-(
I am trying to learn how to add start up scripts and I am not quote getting it. So far -->
1. Wrote a basic functional script ( well it works when invoked in bash) 2. ran update-rc Linkup defaults 3. checked sysv-rc & it is set to run in the correct run levels. -----> No dice. I have done some research on the LSB style headers that are required but I am not sure I am 100% on target. Any & all direction would be appreciated. :hattip: Process commands: Quote:
Script : Quote:
|
LSB headers look good. It is rather that your script lacks start and stop functions.
On a system with SysV init scripts, the init process executes the script given on the sysinit action line, and after the script on the runlevel line. On debian : Code:
si::sysinit:/etc/init.d/rcS Look at /etc/init.d/rc script. You will see that, according to the runlevel parameter, all scripts in /etc/rc$runlevel/S (for start) or /etc/rc$runlevel/K (for stop) will be executed, with start (or stop) as first parameter. So, add your own start and stop functions in your script, and all will be fine |
Thanks for the reply and assistance. Can you offer any suggestions on syntax / code ?
I made an attempt but no dice. :newbie: Quote:
|
Well, after reading myself, what I said is really true only for the stop case... Sorry for the mistake.
Anyway, it is better to write an SysVInit script according to usual standards (managing parameters start, stop, ...) like this one (not tested) : Code:
#! /bin/bash BUT, what could still be a problem is : - sshfs command may not be in the PATH during init (so change the PATH variable or give the full path) - Do you have created a public key with no passphrase between the local root user (which should be the one executing the script during init) and the amy user of 192.168.1.6 ? Otherwise, the script will wait for an interactive user input, which cannot be done at boot time - Same question and remark, this time between the local root user and the media user of 192.168.1.3 Remarks : - If the sshfs command is not intended to be executed by the root user, you will have to use something like su -c, as shown in the script - What miss in this script is a mechanism to forbid to execute several times this script (ans so mounting several times the same filesystems) |
Edit #1 :
umount -a -t fuse.sshfs could be replaced by fusermount -u /media/Little-Tux/ fusermount -u /media/XMBC/ in stop function Edit #2 : Rather than using an init script, you could directly add relevant lines in /etc/fstab For example, with yourlocaluid and yourlocalgid to be replaced : sshfs#amy@192.168.1.6:/ /media/Little-Tux/ fuse user,uid=yourlocaluid,gid=yourlocalgid,exec,idmap=user,noauto,allow_other 0 0 sshfs#media@192.168.1.3:/ /media/XMBC/ fuse user,uid=yourlocaluid,gid=yourlocalgid,exec,idmap=user,noauto,allow_other 0 0 Edit #3 : mmh, the /etc/fstab solution does not work (the network must not be up. I added noauto option, so that it does not automatically mount at boot time |
Thanks for taking the time to help me. I appreciate the effort. I tried your modified version and still no dice.
Quote:
............ I am going to give that a try.....:scratch: |
I tried generating a key (ssh-keygen ) for root then passing to the ".ssh/authorized_keys" of the two machines and :rolleyes: it worked, sort of.
:scratch: But it would only let root access. I could not even change owner or mode as root. So I then took the route of changing the script to your second suggestion ( su to another user to process the commands) and it worked like a charm :D Thanks again for all of your help. :hattip: |
All times are GMT -5. The time now is 02:27 PM. |