I try to add a script for init.d to start “dropboxd” for 2 users.
The script works if it is started as user, MANUAL.
Now, I want to auto-start it after boot in runlevel 3 and 5 as a user, NOT as a root!
The system is used as a server.
How to proceed? “startproc -u USER” does not seem to start the deamon when I run the script as root.
server:/etc/rc.d # /sbin/startproc -u fire /home/fire/.dropbox-dist/dropboxd
server:/etc/rc.d # ./dropbox status
Checking for Dropbox daemon > PID...
dead
server:/etc/rc.d # su fire
fire@server:/etc/rc.d> ./dropbox status
Checking for Dropbox daemon > PID...
dead
fire@server:/etc/rc.d> /sbin/startproc -u fire /home/fire/.dropbox-dist/dropboxd
fire@server:/etc/rc.d> ./dropbox status
Checking for Dropbox daemon > PID... 4756
running
firen@server:/etc/rc.d>
There are two variables being tested here: 1. whether startproc -u fire is starting the process as fire, and 2. whether dropbox status is reporting the right information. Don’t try to test two things at once. If you want to see if dropbox is running as fire, do:
ps aux | grep dropboxd
and you will see if it is running and as the right user.
pidof dropboxd
can also tell you if there is a dropboxd process active.
If the daemon is started correctly, then figure out why the status command doesn’t work. Probably because it’s expecting to see a pid file somewhere and that file isn’t created when the process is running as fire.
Not being able to create a pid file could also be a reason why dropboxd didn’t start. Then you have to fix the permissions of the location of the pid file.
Thanks, it is obvious I do not have enough programming experience to figure out the proper work breakdown.
Today (for me unknown why) the output is a bit different. I automagically do get an traceback message
** start as user **
fire@server:/etc/init.d> /sbin/startproc -u fire /home/fire/.dropbox-dist/dropboxd
fire@server:/etc/init.d> ps aux | grep dropbox
fire 4044 4.3 2.3 151148 24480 pts/0 Sl 19:54 0:01 /home/fire/.dropbox-dist/dropbox
fire 4096 0.0 0.0 3320 772 pts/0 R+ 19:54 0:00 grep dropbox
fire@server:/etc/init.d> pidof dropbox
4044
fire@server:/etc/init.d>
** start as root **
server:/etc/init.d # /sbin/startproc -u fire /home/fire/.dropbox-dist/dropboxd
server:/etc/init.d # Traceback (most recent call last):
File "__main__dropbox__.py", line 29, in <module>
File "arch/__init__.py", line 29, in <module>
File "core/preferences.py", line 237, in <module>
File "core/preferences.py", line 141, in read
File "core/client_model.py", line 142, in wrapped
File "common_util/achub.py", line 30, in __enter__
File "common_util/achub.py", line 105, in begin
File "sqlobject/dbconnection.py", line 383, in transaction
File "sqlobject/dbconnection.py", line 771, in __init__
File "sqlobject/sqlite/sqliteconnection.py", line 117, in getConnection
File "sqlobject/sqlite/sqliteconnection.py", line 161, in makeConnection
OperationalError: unable to open database file
server:/etc/init.d # ps aux | grep dropboxd
root 4334 0.0 0.0 3320 776 pts/0 R+ 20:11 0:00 grep dropboxd
server:/etc/init.d # pidof dropboxd
server:/etc/init.d #
There seems to be an permission issue for the deamon when it is started with “startproc -u”.
I fail to understand that, because the same command does work when logged on as user.
Well that “unable to open database file” is telling you something.
When you use startproc how does the daemon know where the database file is? Is its path mentioned in a configuration file? Is it assumed to be the in the current directory? If so maybe you need to cd to the correct directory before running startproc.
Similarly for any other files the daemon might need.
There may be some hidden assumptions when you are running it as a user that are false when you are running it from startproc.
It seems that dropboxd is sensitive to which directory it’s run from. If dropboxd reads a config file, where does it get it from? Can you specify it on the command line? What about any files that dropboxd, where are the pathnames specified, in the config file?
That bash script just sets PAR to the directory containing the script and adds it to LD_LIBRARY_PATH, then runs the script.
I don’t think there is any problem running the script, since you did get a traceback from the Python program but it fails to open the database for whatever reason. That traceback isn’t very informative about whether it was the wrong filename or there were no permissions to open it. Perhaps it relies on the setting of $HOME or some other variable which is different if started from root.