I just spun up a new 12.04 server and have been having a bit of trouble getting the atd daemon to stop auto-launching. There's been a bit of changing around on the management of startup processes, and I've viewed dozens of web pages on upstart, sysv-rc-conf, and other start management systems (not to mention chk-config, which isn't available anymore on Ubuntu anyway)…

I tried using sysv-rc-conf, but with the configuration as follows, I still have atd running on reboot:

# sysv-rc-conf --list atd 
atd          0:off  1:off   2:off   3:off   4:off   5:off   6:off

Even though it's not upstart-compatible, I put "manual" into /etc/init/atd.override

I've also tried a couple of variant invocations of update-rc.d, but despite the promising output, atd still launches on reboot:

# update-rc.d atd disable 0123456
update-rc.d: warning:  start runlevel arguments (none) do not match atd Default-Start values (2 3 4 5)
update-rc.d: warning:  stop runlevel arguments (none) do not match atd Default-Stop values (0 1 6)
 Disabling system startup links for /etc/init.d/atd ...
 Removing any system startup links for /etc/init.d/atd ...
 Adding system startup for /etc/init.d/atd ...
   /etc/rc0.d/K80atd -> ../init.d/atd
   /etc/rc1.d/K80atd -> ../init.d/atd
   /etc/rc6.d/K80atd -> ../init.d/atd
   /etc/rc2.d/K80atd -> ../init.d/atd
   /etc/rc3.d/K80atd -> ../init.d/atd
   /etc/rc4.d/K80atd -> ../init.d/atd
   /etc/rc5.d/K80atd -> ../init.d/atd

I'd prefer not to just brute-force it and whack the scripts, but after all this, that's what I'm tempted to do. Are there any recommended (or just practical and maintainable) ways to deal with startup issues like this in Ubuntu 14.04?

  • 1
    Upstart and its documentation are so ridiculously obtuse this way I can only believe it is 100% intentional, but if you look at the answer here: askubuntu.com/questions/19320/how-to-enable-or-disable-services there is an upstart specific method (echo manual >> /etc/init/whatever_service.override). – goldilocks Apr 19 '14 at 18:03
  • Thanks for the suggestion, but I've already done the echo into *.override, but when I reboot it still comes up. It's because, I believe, that the atd daemon is NOT yet converted over to upstart. That's when I dug up the legacy tools, after installing chkconfig failed (a few days ago I was dealing with the fact that chkconfig is no more on Ubuntu - and had just got myself used to the idea… trying to "like" upstart). – rholmes Apr 19 '14 at 18:09
  • Ok my bad… I was using wrong directory (ugh - how many times to misread something?) – rholmes Apr 19 '14 at 18:11
  • Now when I put the override in the right place…. Was wondering why no .conf files. Thanks. – rholmes Apr 19 '14 at 18:12
  • This is a useful question, but not about atd. atd is a basic system service, expected to be present on every unix system. You shouldn't disable it. – Gilles 'SO- stop being evil' Apr 19 '14 at 23:16

I think you are looking for /etc/init/atd.conf:

➜  ~  cat /etc/init/atd.conf                                                    
# atd - deferred execution scheduler
# at is a standard UNIX program that runs user-specified programs at
# scheduled deferred times

description     "deferred execution scheduler"

start on runlevel [2345]
stop on runlevel [!2345]

expect fork

exec atd

Ubuntu uses still upstart, and their scripts are stored in /etc/init/. You can just remove the whole file or just commenting out the start on stanza.

| improve this answer | |
  • I'm starting to see that I somehow started on the wrong track by cd-ing to /etc/init.d (which I knew was wrong) but didn't go to init/ -- so I asked a silly question. Thanks for the quick response, anyway! – rholmes Apr 19 '14 at 18:26
  • Out of curiosity (I'm not much of a ubuntu user), are you sure changes to these files won't get overwritten later by a package update? Eg., .conf file for atd changes, and so a new .conf is installed and you mysteriously return to the same default start/stop levels. – goldilocks Apr 19 '14 at 18:40
  • @TAFKA'goldilocks' only if the maintainer do some change, in which case debconf will start nagging if you want to overwrite them. – Braiam Apr 19 '14 at 18:43
  • From what I read, .conf file may be updated. Most package upgrades offer to view / diff the changes in that situation, IIRC. I believe the point of the <cmd>.override file is so that these commands will not be overridden. – rholmes Apr 19 '14 at 18:55

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.