autostart fails if service has already started

[sed-i]

This happens when pebble_ready is deferred, but another event (re)starts the service. When pebble_ready re-enters, I get this error:

Traceback (most recent call last):
  File "./src/charm.py", line 443, in <module>
    main(AlertmanagerCharm)
  File "/var/lib/juju/agents/unit-alertmanager-0/charm/venv/ops/main.py", line 406, in main
    _emit_charm_event(charm, dispatcher.event_name)
  File "/var/lib/juju/agents/unit-alertmanager-0/charm/venv/ops/main.py", line 140, in _emit_charm_event
    event_to_emit.emit(*args, **kwargs)
  File "/var/lib/juju/agents/unit-alertmanager-0/charm/venv/ops/framework.py", line 278, in emit
    framework._emit(event)
  File "/var/lib/juju/agents/unit-alertmanager-0/charm/venv/ops/framework.py", line 722, in _emit
    self._reemit(event_path)
  File "/var/lib/juju/agents/unit-alertmanager-0/charm/venv/ops/framework.py", line 767, in _reemit
    custom_handler(event)
  File "./src/charm.py", line 67, in wrapped
    func(self, event, *args, **kwargs)
  File "./src/charm.py", line 213, in _on_alertmanager_pebble_ready
    container.autostart()
  File "/var/lib/juju/agents/unit-alertmanager-0/charm/venv/ops/model.py", line 1042, in autostart
    self._pebble.autostart_services()
  File "/var/lib/juju/agents/unit-alertmanager-0/charm/venv/ops/pebble.py", line 791, in autostart_services
    return self._services_action('autostart', [], timeout, delay)
  File "/var/lib/juju/agents/unit-alertmanager-0/charm/venv/ops/pebble.py", line 831, in _services_action
    raise ChangeError(change.err, change)
ops.pebble.ChangeError: cannot perform the following tasks:
- Start service "alertmanager" (service "alertmanager" was previously started)

This is expected when trying to start the same service twice, but with autostart I expected this to work. Is this a bug or by design?

[jameinel]

I would have thought that autostart for services which are declared as startup: enabled would be a no-op if the service was already started.

[jnsgruk]

Yep, I've also observed this a bunch of times. Would be nice to handle this case a bit more elegantly, a no-op seems most sensible (and perhaps a log message to indicate that is the case)

[guoqiao]

+1, this will trigger an error every time when you do charm upgrade, since service is already running.

[hpidcock]

#58 resolves this