-
Notifications
You must be signed in to change notification settings - Fork 25
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
Conversation
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]>
f92d0ae
to
fec2bca
Compare
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. |
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]>
fec2bca
to
1c0b11e
Compare
The package on pypi is called |
@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 ( if CI tests are now passing, we could then squash my commit into relevant commit(s) from this PR |
Merged #344 hence closing this one. |
For details, see individual commit messages. Especially have a look at the changes in p4.
cc @bovi
closes: #342