service restart question

Lennart Poettering mzerqung at
Mon Jun 25 14:13:25 UTC 2012

On Mon, 25.06.12 16:57, Gary Kotton (gkotton at wrote:

> Hi,
> I recently encountered a problem with the Openstack Quantum service. The
> service was installed by doing the following steps:
>     - sudo yum install openstack-quantum
>     - sudo systemctl enable quantum-server.service
>     - sudo systemctl start quantum-server.service
> Due to a bug the service terminated.
> The contents of the file
> /etc/systemd/system/ is below:
> [Unit]
> Description=OpenStack Quantum Server
> [Service]
> Type=simple
> User=quantum
> ExecStart=/usr/bin/quantum-server --config-file
> /etc/quantum/quantum.conf --log-file /var/log/quantum/server.log
> PrivateTmp=true
> [Install]
> My understanding is that if there is a entry in the "Service" section
> "Restart=always", then we can rely on systemd to restart the service if
> it dies.
> Can someone please explain or clarify why this is not the default value?
> I can understand that this should not be set if there is another
> "watcher" process that can restart a failed service.

Well, simply because we have no policy about it. I think it would make a
lot of sense however, to amend the fedora policy to suggest usage of
this by default for normal long running services.

Of course, there are some services where this functionality makes no
sense, for example all those which are of type "oneshot", i.e. are just
quickly started at boot to initialize something but then don't run any

Or Historically on SysV this functionality was not available, and so far
we only did the minimum packaging policy updates for translation of
SysV. We probably should fix that, but be careful to make this a
recommendation but not a requirement, and leave a lot of room for the
individual cases.

Also, we need to think about whether Restart=always or
Restart=on-failure or even Restart=on-abort is the best option to

I think it would be great if somebody would file an FPC ticket about
this, so that the policy gets amended. But for that we'd first have to
make our mind up what the best option to recommend is.


Lennart Poettering - Red Hat, Inc.

More information about the devel mailing list