1

I'm currently setting up a raspberry pi running Debian wheezy as an IRC server. It runs two programs as a regular user on boot - ngircd and atheme.

ngircd and atheme both log to /var/log/syslog

ngircd is started from the executable(/usr/local/sbin/ngircd ) itself, as is Atheme (/home/user/atheme/bin/atheme-services). Manually starting the programs as the user from a terminal works with no issues.

When I try to start ngircd (using the location its installed in) from cron, it simply doesn't start - /var/log/syslog says that the cron job ran, but nothing happens, there are no error messages, or any ngirc related logs at all. Atheme starts fine.

However if i create a script that does nothing but run ngird (using the same path i used earlier), and add that to cron, it works fine (as does running it directly). Why isn't ngircd starting from cron?

Its not a big issue, but it does make the system slightly messier than I'd like. Its also strange that the two programs behave differently

2 Answers 2

1

I don't have the privilege to comment, so I can't ask for clarification, but I would suggest running the daemon either from an initscript or from rc.local, and not from cron. Cron is usually used to execute things at a certain time, regularly. The handling of daemons and services is usually a job for your init system.

To run something as a regular user on boot:

Add this to /etc/rc.local :

/bin/su -c '/path/to/your/executable args &' -s /bin/bash username >/dev/null 2>&1
2
  • for 'why' - I usually run IRC as a seperate user, with utterly restricted privileges, and assuming I have no access to the rest of the system. The irc setup I use is sort of to test, and to help folk who want an IRC setup of their own. I don't normally run ngircd, but the use of crontab is carried over from my old unreal/anope setup. @ reboot is a perfectly acceptable way of starting user level applications. While my setup is failing when run @ reboot, the same program would probably fail identically if it was a timed start. I got it 'working'. I want to know why it fails.
    – Journeyman Geek
    Commented Nov 8, 2012 at 1:16
  • Not sure, obviously you hit this bug: unix.stackexchange.com/questions/109804/… Commented Oct 17, 2015 at 18:39
0

Cron runs something that behaves exactly like

sudo - user /path/to/command

or

su user
/path/to/command

If you want to check if your command executes, you have to test it in this way.

You could either edit the user-crontab with

crontab -e

or the system-wide crontab as root with

nano /etc/crontab

or your favourite editor other than nano (prepend with sudo if necessary). Note that these two crontabs differ in syntax in that the system-wide crontab has an extra column between execution time and command which specifies the user to run the command as. You want your execution time to be set to @reboot:

@reboot user /usr/local/sbin/ngircd
@reboot user /home/user/atheme/bin/atheme-services

Just drop the word user if you are editing the user crontab with crontab -e.

As alternative, you could use System V's initscripts or systemd's service control files, depending on the system you have.

2
  • Oh, I was familiar with that when I posted it. The issue was one of the apps not running at all, and if I recall correctly, it was run as a user called "ircuser" and a crontab for that.
    – Journeyman Geek
    Commented Oct 15, 2015 at 7:14
  • I edited my post to reflect the exact command you have to test, just because I stumbled upon this alot, too. Replace "user" with "ircuser" where needed. Commented Oct 15, 2015 at 8:22

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .