Jump to content

Program at boot up [solved]


Recommended Posts

I have gotten denyhosts to run for me, and have switched to the daemon mode to reduce the load of running it, it also runs more often that way, and allows to sync my bad guys with a large list of others. The problem I have now is that it refuses to start during boot.

 

First, let me say I have done this all remotely, and cannot see the computer during the boot up for now, not until I get home.

 

(I am running Mandriva 2007, denyhosts 2.5, and python 2.4.)

 

What I have done thus far:

 

I copied the control-daemon file to init.d folder:

 

# cp /usr/share/denyhosts/daemon-control /etc/init.d/denyhosts

 

then ran chkconfig

 

# chkconfig --add denyhosts

 

I can start it, stop it, restart it, and get the status of it using "service"

 

# service denyhosts

 

There have been files written/copied by chkconfig for every runlevel in these directories:

 

/etc/rc.d/init.d/denyhosts

/etc/rc.d/rc0.d/K02denyhosts

/etc/rc.d/rc1.d/K02denyhosts

/etc/rc.d/rc2.d/S98denyhosts

/etc/rc.d/rc3.d/S98denyhosts

/etc/rc.d/rc4.d/S98denyhosts

/etc/rc.d/rc5.d/S98denyhosts

/etc/rc.d/rc6.d/K02denyhosts

 

Yet when I reboot and query the status, it says denyhosts is not running.

 

Looking in Madriva Control Center (MCC), it knows the process exists, and shows it should start on boot, but it also shows stopped.

 

What am I missing?

 

 

[moved from Software by spinynorman]

Link to comment
Share on other sites

Since no one has replied, I'll give you my best guess - some dependency needed by your script has not loaded at the time the system attempts to start the script. If it is a timing problem as I suspect, then try and run the script by editing /etc/rc.d/rc.local. Put whatever command you use to run the script at the end of rc.local and see if it works on reboot. The rc.local hack is commonly used to get around these timing problems since rc.local is the last init script to run.

Link to comment
Share on other sites

...my best guess - some dependency needed by your script has not loaded at the time the system attempts to start the script. If it is a timing problem as I suspect, then try and run the script by editing /etc/rc.d/rc.local. Put whatever command you use to run the script at the end of rc.local and see if it works on reboot. The rc.local hack is commonly used to get around these timing problems since rc.local is the last init script to run.

This timing technique has worked for me with the sound module. I installed Mandriva 2007 in a VM using VMware Player and the sound module always failed to load during boot-up. But after I put the same commands in rc.local, the sound module always loads fine.

 

So hopefully this technique will work for riseringseeker.

Link to comment
Share on other sites

Since no one has replied, I'll give you my best guess - some dependency needed by your script has not loaded at the time the system attempts to start the script. If it is a timing problem as I suspect, then try and run the script by editing /etc/rc.d/rc.local. Put whatever command you use to run the script at the end of rc.local and see if it works on reboot. The rc.local hack is commonly used to get around these timing problems since rc.local is the last init script to run.

 

Sorry I hadn't gotten back to you, I've been rather busy, and not where I could easily do what you suggested.

 

I edited /etc/rc.d/rc.local and put in the following line:

 

/usr/bin/python /usr/bin/denyhosts.py --daemon --config=/usr/share/denyhosts/denyhosts.cfg

 

This works just fine from a command line to start denyhosts in daemon mode, but it did not seem to help when I put it in rc.local. When I reboot (and recall I am doing this all a long way from the desktop at home), it still gives me a status message that denyhosts is not running after a boot.

 

I have tried to play with the above line to no avail. It still refuses to come up on boot. Since it works on a command line, it should work in rc.local, no? rc.local I assume runs the scripts with root priveldges, doesn't it?

Link to comment
Share on other sites

Yes, rc.local is an init script that runs with root privileges. The problem probablly has something to do with the nuances of launching a pyhton script from within an init script. I'm not sure exactly what's going on but here's another suggestion. Try making a simple bash script to launch the program. Create a text file called "dodenyhosts" and put the following text in it:

 

#!/bin/bash
/usr/bin/python /usr/bin/denyhosts.py --daemon --config=/usr/share/denyhosts/denyhosts.cfg

 

Make dodenyhosts executable:

 

# chmod a+x dodenyhosts

 

and see if the script can launch denyhosts:

 

# ./dodenyhosts

 

I'm trying to explore whether there is some problem of launching this from a bash script which is essentially what you are trying to do. If it doesn't work, the error messages may give some indication why.

If you can launch from this script, you need to get more info as to what is happenning when these commands attempt launch from within rc.local. Edit rc.local like you did before but add:

 

/usr/bin/python /usr/bin/denyhosts.py --daemon --config=/usr/share/denyhosts/denyhosts.cfg &>/home/<username>/error.txt

 

Note the formatting here doesn't permit this to go on one line but there should be a space between denyhosts.cfg and "&>/home/<username>/error.txt". The added text will cause any output or error messages that occur when the command runs to be outputted to a textfile, error.text, in your /home/<username> directory. This might give you some idea about what is going on.

Link to comment
Share on other sites

Well I am at last home. I tried modifying rc.local as above, and various variations thereof. Each and every time it rebooted, denyhosts was not running. I also modified "dodenyhosts" and "error.txt" was created, but it was just an empty file (which I assume means there were no errors)

 

Just as an experiment, with denyhosts stopped, I ran rc.local from a command line as a normal script. Lo and behold, denyhosts was running afterward, which leads me to believe that rc.local is not running at boot up.

 

Is there any way I can determine this for certain, and/or change something to make it run at start, assuming it really is not?

 

Oh, just found one more thing.

 

#service -s

 

does not show denyhosts is running, even when it is. Curiouser and curiouser.

Edited by riseringseeker
Link to comment
Share on other sites

I'm sure rc.local is running. To test put this in rc.local:

 

echo "I am running" > /home/<username>/test.txt

 

Anyway, if rc.local wasn't run, error.txt could not have been created. It seems denyhosts may be running but not be picked up from what you say. See if the process is picked up with:

 

$ ps aux | grep denyhost

Edited by pmpatrick
Link to comment
Share on other sites

I would also check you logs for clues (/var/log/messages). I usually use "logger" to write from scripts to the log in order to find how far my PC comes in long scripts before crashing. You can (if you want) pipe loads of output to logger and see it back in messages -- helped me out more often than once in trying to pinpoint where things went wrong exactly.

 

No specific clues for denyhosts though.

Link to comment
Share on other sites

  • 2 weeks later...
I'm sure rc.local is running. To test put this in rc.local:

 

echo "I am running" > /home/<username>/test.txt

 

Anyway, if rc.local wasn't run, error.txt could not have been created. It seems denyhosts may be running but not be picked up from what you say. See if the process is picked up with:

 

$ ps aux | grep denyhost

 

rc.local was indeed running, and after several pleas for help from the denyhosts mailing list, the author told me to modify the configuration script with:

 

os.environ['HOSTNAME'] = "your_HOSTNAME_goes_here"

 

after line #33

 

It now starts on boot. Thanks to all for trying to help! I do appreciate being part of a community so generous with their time and knowledge.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

×
×
  • Create New...