Add Comment

You are not currently logged in. If you do not have a user account then please consider creating one and logging in before you post your comment. This will allow you to track replies to your comment, and take part in the site much more freely.

To add your comment, fill in all the boxes below and then preview it to make sure you're happy with the way that it looks.

This is the comment you were replying to, attached to the article Running scripts after a reboot for non-root users:


fetchmail
Posted by bdf (134.184.xx.xx) on Wed 15 Mar 2006 at 09:07
It's an interesting topic wether regular users should have daemons and how they should be started. I think fetchmail is a good example: you run it as a user to pull mail from a remote account to the local mail system.

The first option is to run it as a regular program from cron, every 5 minutes or so. This is what I do now, but in this setup fetchmail does not know about other runs: if the previous run didn't finish before the next one is started, I get an error like "fetchmail: another foreground fetchmail is running at ...". It seems like fetchmail could be better informed if it were running as a daemon (the second option), but there is so much overhead to this: who is going to start it at bootup? do we need to stop it when switching runlevels? can the user easily manage the daemon through some init.d/fetchmail start|stop|restart|...? where does the daemon send log output? if the fetchmail daemon dies because of some unexpected error, how will I know, or will it be restarted? (who isn't paranoid about missing mail?)

Because of all of this concerns, solutions like your @reboot or this fetchmail-init haven't been able to convince me that it is manageable for users to have daemons.

Username:Anonymous
Title:
Your Comment:

Posting Format:

 

Inappropriate comments will be removed.

Some help on entry formatting is available

User Login

Username:

Password:

[ Advanced Login ]

Register Account

Quick Site Search