mirror of
https://github.com/motioneye-project/motioneye.git
synced 2026-03-02 22:57:06 -05:00
Docker install on Buster #2477
Labels
No labels
Android app
Arch Linux
CI/CD
CSS
FreeBSD
HTML/HTTP
Home Assistant addon
JavaScript
Python
Raspberry Pi
Stale No Activity 60 Days
bug
code format
dependencies
dev branch
docker
documentation
duplicate
enhancement
feature
help wanted
i18n/l10n
invalid
legacy motionEye
meta
motion
motionEyeOS
notourproblem
python update
question
question
security
troubleshooting
wontfix
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/motioneye#2477
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @Kobbe1 on GitHub (Dec 29, 2023).
#Hi,
great project!
I thought I give the 0.43 release a try in parallel on my production system (still running buster).
I disabled the old 0.42 motioneye service temporarily, and then tried below command:
I am getting several permission errors, so I assumed I am maybe encountering this. Following the 3 steps at the end did not really fix it, but then again I guess I am not actually running as user "motion" (I ran above command under my standard username, I guess I could try to just run the docker as user "motion"?).
I am pretty sure this is a permission issue/related to my old install of ME, but I am hoping someone can suggest a reasonable path forward, the old 0.42 install works very well so I am not too keen to mess it up completely - never change a running system.
I guess the docker wiki also needs an update but I think this was said before in some other issue.
Best,
-T
@MichaIng commented on GitHub (Dec 30, 2023):
Thanks for reporting. The final actual error that is thrown in a loop is:
Strange about it is that this attribute is requested solely within the
asynciomodule, not by us.The this error looks more like an attempt to log/warn about another one happened before:
As far as I understand the docs about this, it is not even the system clock, but about an internal clock/timer started internally, in this case likely to time the I/O loop iterations: https://docs.python.org/3/library/time.html?highlight=get_clock_info
So no idea how a permissions error can happen in this case.
asyncioandtimeare both Python 3 internal modules, so nothing where 3rd party updates/dependencies should have any effect on.The issue you linked was about a bare metal motionEye instance on RPi executed via systemd unit, not a Docker container, hence entirely different. You do not need to (or better must not) run the container itself as
motionuser, especially since that one should not exist on your host system anyway. The container currently requires root permissions, and internally starts motionEye with its internalmotionuser: https://github.com/motioneye-project/motioneye/blob/dev/docker/entrypoint.shThe RAEDME indeed needs to be updated for the new version. Your
docker runhowever looks fine. The dirs of the volumes on host end exist?Ah, although can you try to ship the volume and port options in your
docker run? These are defined in the Dockerfile already: https://github.com/motioneye-project/motioneye/blob/dev/docker/Dockerfile#L40-L46The two volumes are created in the Docker container's directory. I am currently not sure whether the declarations in the Dockerfile just override those you set via CLI, or whether they indeed can conflict.
@Kobbe1 commented on GitHub (Dec 30, 2023):
Thanks for the help.
Tried as below, no luck. Sorry for spamming this issue with all these logs but I guess better too many than too few.
Strangely there are a few lines more at the start now (INFO). I also saw that the old ME restarts even though I disabled and stopped it:
Service says disabled but it still restarts after a while ?! :)
I did the docker test right after I stopped old ME, and it only restarts after some minutes so probably that is not the issue, but still strange (or more likely my lack of knowledge and that behaviour is normal).
The folders do exist from the old ME instance, and I manually created /var/log/motioneye already before to no avail.
@MichaIng commented on GitHub (Dec 30, 2023):
Hmm, no systemd service should start automatically when you disable (and stop) it. Check
to see when this happens, and try to find out what triggers it. For the container as well, which you explicitly set as
--restart=unless-stopped, i.e. to never restart when it was explicitly stopped once.However, I see you run the container as
piuser. Please try to do this as root. I am not exactly sure which part exactly requires root permissions and why, but the "not permitted" error quite points into this direction.@Kobbe1 commented on GitHub (Dec 30, 2023):
No luck it seems. Maybe will fix it next year ;)
On the stuborn ME 0.42:
and
@MichaIng commented on GitHub (Dec 30, 2023):
😉
I am sure this is an entirely new image, container and volumes, compared to the one you did spin up as
piuser.Strange stubborn motionEye 0.42. So it was (re)started ~9 minutes after it was stopped. There is no systemd timer, cron job or any such which would do this, is it? I am not aware that a systemd service would be able to do such, but just in case, lets check its content
and just in case some strange timer was setup:
And of course the
journalctlcommand (without arguments) can be used to scroll all system logs, to e.g. see cron job executions, timers or other services which might have started the motionEye service.@Kobbe1 commented on GitHub (Dec 30, 2023):
Thanks for your patience, I actually thought about it and then did it wrong anyway :-) Although no difference either it seems? I did successfully docker rm before (without sudo), so not sure the sudo makes a difference, maybe the docker service always runs as root? But worth a try anyway.
@MichaIng commented on GitHub (Dec 30, 2023):
Okay you are probably right. Running non-root containers was not that easy yet IIRC and it seems the
piuser just has the right permissions to control root containers.I won't find the time to test it myself until next year either. So I wish you Happy New Year in advance, despite the motionEye issue, and I will check back and test it on a VM and RPi Zero W and/or RPi 2 next year.