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


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
  • 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 Nov 8 '12 at 1:16
  • Not sure, obviously you hit this bug: unix.stackexchange.com/questions/109804/… – rexkogitans Oct 17 '15 at 18:39

Cron runs something that behaves exactly like

sudo - user /path/to/command


su user

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.

  • 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 Oct 15 '15 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. – rexkogitans Oct 15 '15 at 8:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.