Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Various fixes around service startup order #343

Closed

Conversation

fmoessbauer
Copy link
Member

@fmoessbauer fmoessbauer commented Sep 27, 2023

For details, see individual commit messages. Especially have a look at the changes in p4.

cc @bovi

closes: #342

pyzmq 25 is the version shipped in debian bookworm and we did not see
any issues with that version so far. By that, bump the version to also
support a pip install on debian bookworm.

Signed-off-by: Felix Moessbauer <[email protected]>
@fmoessbauer
Copy link
Member Author

fmoessbauer commented Sep 27, 2023

Looks like there was some change in the sd notify module. I'll push a fix.

Update: actually the pypi systemd module shadows the "official" one from systemd (which is also shipped in debian), but this is incompatible. Looking for a solution.

@chombourger chombourger removed the check label Sep 27, 2023
The startup of the mtda service might take quite long on the nanopi-neo
board (~15sec). This is due to the loading of a ton of dependencies,
which cannot really be avoided. To make it possible to depend other
units on a properly running mtda instance, we switch the service type to
signalling and signal when we start the server.

Signed-off-by: Felix Moessbauer <[email protected]>
With the conf.d style support, also the config.d paths needs to be
monitored for changes. In addition, the mtda-config service needs to be
a oneshot service, as the configuration update needs to be completed
before the mtda service unit is triggered.

Signed-off-by: Felix Moessbauer <[email protected]>
Previously, the mtda-config.service and mtda.service were not
synchronized, leading to a restart of the mtda service during the
startup of it. The first part of this patch adds a strict (time)
synchronization between the two.

As the mtda-systemd-helper first needs to finalize the systemd
configuration before the next job can be scheduled, we also need
to switch the service to oneshot (wait for completion before
becoming active). This however creates a deadlock in case we
synchronously wait for the completion of the mtda-config service.
To fix this, we trigger the "try-restart" in async mode (--no-block).
By that, the mtda-config service will complete first and afterwards
the mtda service will be started. This also avoids the double
restart on startup, as the restart is simply merged with the
following startup by systemd.

Signed-off-by: Felix Moessbauer <[email protected]>
The www.conf file is a drop-in to configure the mtda-www component. In
our packaging, we always include that file. By prefixing it with "10-",
other dropins can easily be ordered after it by using a higher number
(e.g. "90-").

Signed-off-by: Felix Moessbauer <[email protected]>
@fmoessbauer fmoessbauer force-pushed the fm/systemd-restart-order branch from fec2bca to 1c0b11e Compare September 27, 2023 09:44
@fmoessbauer
Copy link
Member Author

The package on pypi is called systemd-python. By that it should work with both the debian package, as well as the pypi package. @chombourger please trigger again.

@fmoessbauer
Copy link
Member Author

@chombourger would you mind having a look at the tox errors. It looks like we need some native dependencies on the host which cannot be downloaded with pip. If it is too complicated, we could also make this conditional (by using a try import).

@chombourger
Copy link
Collaborator

@chombourger would you mind having a look at the tox errors. It looks like we need some native dependencies on the host which cannot be downloaded with pip. If it is too complicated, we could also make this conditional (by using a try import).

sure thing. I can take a look this evening

@chombourger
Copy link
Collaborator

@chombourger would you mind having a look at the tox errors. It looks like we need some native dependencies on the host which cannot be downloaded with pip. If it is too complicated, we could also make this conditional (by using a try import).

sure thing. I can take a look this evening

finally got to it. reproduced the issue locally using WSL2+ubuntu-22.04 with systemd enabled (systemd=true in `/etc/wsl.conf'
fixed locally and now checking with #344

if CI tests are now passing, we could then squash my commit into relevant commit(s) from this PR

@chombourger
Copy link
Collaborator

Merged #344 hence closing this one.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

add a prefix (priority) to systemd drops
2 participants