blinkd: Use system python #65
Merged
+1
−2
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This is the second part of the blinkd fix (issue #54). PR #64 prevented the deadlock during service start. However, currently blinkd is not starting at system boot, because it uses `env python3` in the shebang. This will activate our default (big, scientific) python3 which is located in /pkg and depends on the automounter. One solution to this problem would be to add After=automount.service to blinkd.service. This would delay the startup of blinkd to the point, when automounter has finished startup. However, experiments showed, that this doesn't work. It looks like the startup command of automount.service exists after daemon process has been forked but before the automount paths have been mounted. So systemd regards automount.service has started before the automount paths are really available and services with After=automount.service are still started to early to use them. That aside, although /usr/bin/python3 does not to go via NFS under normal circumstances because of the local mechanism of mxpkg, under exceptional circumstances, this can happen (e.g. when the python3 version is updates). We don't want long-running daemons to lock nfs mounts, so this would not be a good solution, even if made to work. A python3 with the blink1 package from PyPi has been added to the system [1] and is available as /usr/local/system/python3/bin/python3. This python3 installation is guaranteed to be on a local disk, so use this path in the shebang. [1] mariux64/pkg-scripts@8e149c1
Sign in
to join this conversation on GitHub.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is the second part of the blinkd fix (issue #54).
PR #64 prevented the deadlock during service start.
However, currently blinkd is not starting at system boot, because
it uses
env python3in the shebang. This will activate our default(big, scientific) python3 which is located in /pkg and depends
on the automounter.
One solution to this problem would be to add After=automount.service
to blinkd.service. This would delay the startup of blinkd to the
point, when automounter has finished startup. However, experiments
showed, that this doesn't work. It looks like the startup
command of automount.service exists after daemon process has been
forked but before the automount paths have been mounted. So
systemd regards automount.service has started before the automount
paths are really available and services with After=automount.service
are still started to early to use them.
That aside, although /usr/bin/python3 does not have to go via NFS under
normal circumstances because of the local mechanism of mxpkg, under
exceptional circumstances, this can happen (e.g. when the python3
version is updated). We don't want long-running daemons to lock
nfs mounts, so this would not be a good solution, even if made to
work.
A python3 with the blink1 package from PyPi has been added
to the system [1] and is available as
/usr/local/system/python3/bin/python3.
This python3 installation is guaranteed to be on a local
disk, so use this path in the shebang.
[1] mariux64/pkg-scripts@8e149c1