34

Ubuntu 10.04

I have created this upstart script (/etc/init/pure-ftpd.conf):

# pure-ftpd - FTP server

description "Pure-FTPd server"

start on filesystem
stop on runlevel S

respawn
respawn limit 10 5
pid file /var/run/pure-ftpd.pid
console output

pre-start script
    test -x /usr/local/sbin/pure-ftpd || { stop; exit 0; }
end script

exec /usr/local/sbin/pure-ftpd --maxclientsnumber 2 --maxclientsperip 10 --prohibitdotfileswrite --prohibitdotfilesread --noanonymous --chrooteveryone --dontresolve --nochmod --pidfile /var/run/pure-ftpd.pid

But...

# start pure-ftpd
start: Unknown job: pure-ftpd

and

# service pure-ftpd start
start: Unknown job: pure-ftpd


What's the problem?
Is it necessary to do something more?
Is it necessary to create one script in /etc/init.d too?

1
  • I met same trouble. Please try initctl command at console. To enter console session, press Ctrl + ALT + F1 and login. (I can't understand why, but I successed this way)
    – user268442
    Apr 13, 2014 at 9:54

6 Answers 6

46

You can also run init-checkconf to check syntax

init-checkconf /etc/init/job.conf
File /etc/init/job.conf: syntax ok
3
  • 1
    The command does not exist in 10.04, but it does exist in 12.04. May 6, 2013 at 16:52
  • 6
    But it does not work on on a headless Ubuntu 12.04 server (yet). See bugs.launchpad.net/upstart/+bug/881885
    – FvD
    Jul 13, 2013 at 21:44
  • 1
    Found the issue straightaway! - Should be built into the start command so it gives you a more informative error message...
    – A T
    Feb 22, 2015 at 10:55
27

It usually means you have an error in the .conf file - for instance I'm not sure the pid stanza is supported in 10.04, stop can't be used in the script etc.

I'd try starting the file from scratch (with only start, stop etc), and then slowly building it up by adding more and more lines and testing it via start pure-ftpd.

For example:

# cat pure-ftpd.conf 
start on filesystem
stop on runlevel S

respawn
respawn limit 10 5

# start pure-ftpd
pure-ftpd start/running

# cat pure-ftpd.conf 
start on filesystem
stop on runlevel S

respawn
respawn limit 10 5
pid file /var/run/pure-ftpd.pid

# start pure-ftpd
start: Unknown job: pure-ftpd
3
  • The information in the wiki is very outdated (upstart.ubuntu.com/wiki). By other side, the upstart version in Lucid is 0.6.5-8 and the pid file should be supported: upstart.ubuntu.com/wiki/… Mar 17, 2011 at 20:12
  • 1
    AFAIK the pid stanza have been removed since the version 0.5.0 2008-08-12 "One of those deaf-mutes". Don't use it.
    – arrange
    Mar 17, 2011 at 20:39
  • Someone knows where is the updated documentation? Mar 17, 2011 at 22:50
26

First, you can check that your job is actually known to upstart:

sudo initctl list | grep your_job_name

...where your_job_name is the name of your upstart script minus the .conf extension.

If it's not found, you can try reloading the configuration and then re-checking:

sudo initctl reload-configuration

# re-check
sudo initctl list | grep your_job_name

Then try again to start your job:

sudo start your_job_name

If you weren't getting any logging in /var/log/daemon.log or /var/log/syslog before, you might have some now.

7
  • 1
    And what if this shows that the job is not known to upstart, even though the syntax is correct and it resides in /etc/init?
    – FvD
    Jul 13, 2013 at 20:30
  • 1
    Did you try "sudo initctl reload-configuration" as suggested? Did you check permissions, logs, docs? Jul 15, 2013 at 12:26
  • I did, and did again after reading your comment. Even made sure that the user was a system-user (useradd -r). Perhaps there may be something else wrong -unrelated to upstart - so I posted an issue to the developers of the service I'm trying to start (it is shiny-server I'm trying to start on boot).
    – FvD
    Jul 15, 2013 at 15:56
  • 1
    And it was permissions after all! even though everything looked peachy when listing the dir, only after a chmod 644 did initctl pick up the script. Thanks again.
    – FvD
    Jul 15, 2013 at 18:10
  • 1
    Remember, the your_job_name is without the .conf ending of the file. Took me an hour to find out.
    – Marcel
    Dec 30, 2016 at 18:57
6

The most relevant reference for job file syntax will be available when you run the command:

man 5 init

on your system. For Ubuntu 10.04, as you found in the previous answer, the pid file syntax is incorrect.

Any time you get that 'unknown job" error back, its a good idea to check the logs (pre 11.04, /var/log/daemon.log, 11.04 and greater everything goes in /var/log/syslog)

You may see an error like this:

init: /etc/init/test.conf:2: Unknown stanza
3

Anyway I'am here because i had the same problem, but my syntax was 100% correct.

After some debugging I discovered another issue that can cause this "Unknown job" error:

upstarts uses inotify to monitor .conf file changes and auto install jobs, this is very cool (for this you don't need something like update.rc with upstart!) but can be not perfect if you (like me in that case) use some FTP/SCP GUI program to upload and edit configurations on remote servers, the job can be silently uninstalled by upstart when you edit file in that manner.

to fix simply do that (that saved me)

touch /etc/init/*

it will generate inotify events to refresh all upstart confs.

2

I had the same problem in my Ubuntu 14.04 Docker containers. As it turns out, the Ubuntu 14.04 image (if not others) for Docker does not support Upstart in the same way that a full virtual machine would.

To answer this question, why the service does not start, it is because initctl is not an actual Upstart program: it is mapped to /bin/true.

To verify run the following on a Ubuntu 14.04 Docker container vs. Vagrant, and vs. a DigitalOcean droplet

$ ls -al /sbin/initctl

You'll see initctl is not the same in Docker vs. the others.

A link that may further your understanding.. https://github.com/docker/docker/issues/1024

2
  • 2
    Ran into the same problem with docker: in short and to summarize, docker only runs one process at a time so it cannot run upstart and something else. To make sure to restart the service if/when it dies, i ended up using supervisord. PS: you should not run multiple services in a container: the whole point of using containers is to build micro services, so build the pieces in separate containers and bring them together with Docker-Compose
    – MrE
    Jun 14, 2015 at 20:12
  • 1
    I just ran into this article and that gives very good advice about how to separate concerns: blog.docker.com/2014/06/why-you-dont-need-to-run-sshd-in-docker which is probably the even better strategy to use than to use supervisor
    – MrE
    Jun 15, 2015 at 19:23

You must log in to answer this question.

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