mirror of
https://github.com/motioneye-project/motioneye.git
synced 2026-03-02 22:57:06 -05:00
RPi camera modules | libcamerify causes motion sh childs to become zombies #2472
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#2472
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 @kni-bo on GitHub (Dec 27, 2023).
Hello,
Brief description:
with motioneye dev I have the problem that zobie processes remain in the system. From about 700 zobies the memory runs full and the system stops.
Detailed description:
As hardware I have a raspberry Pi 3 B+ with a V1 IR camera (ov5647).
The software I use is Raspberry Pi OS Lite 64-bit with motioneye dev. I had to use libcamerify and python-venv to get this running.
As reported for the Raspberry Pi 4, the codec H.264/OMX does not work with the Pi 3, too. I use H.264.
The camera is detected and I can record images and videos.
One minute after restarting motioneye (systemctl restart motioneye.service), the processes look like this:
After a few hours or a day (depending on the number of motions detected) there are over 700 zombies. Then the zombies stop growing, but the memory fills up and the system stops.
I have written a small watchdog so that I don't always have to pull the power plug.
The watchdog reboots the system before the memory is full and the system stops and collects some data. Then the processes look like this:
I found out that it is enough to restart motioneye (systemctl restart motioneye.service) to kill all zobies and free the memory. So i changed my watchdog to do that instead of rebooting.
The following lines are repeated every 10 seconds in the journal:
What can I do to further narrow down and solve the problem?
Many thanks in advance.
Michael
@MichaIng commented on GitHub (Dec 27, 2023):
How does your service look like? The logs show some issue with motion trying to connect/get the stream from the camera but there are also two concurrent motionEye processes.
The camera is attached via DSI port and you have KMS enabled (default on RPi OS)?
@kni-bo commented on GitHub (Dec 27, 2023):
Hello,
Firstly, thank you very much for your quick reply.
Above I have posted the part from the journal that is always repeated. That's why the journal is huge. Apart from the messages above, I don't see anything conspicuous.
The camera is connected via the flat cable. I think this is the DSI port.
I don't know that I've set anything like KMS. If that is the standard, it should still be like that.
Thanks
Michael
@kni-bo commented on GitHub (Dec 27, 2023):
I found this:
@MichaIng commented on GitHub (Dec 27, 2023):
The 64-bit RPi OS does not ship the OMX driver anymore and it does not work with KMS so generally makes sense that it is the same issue as with RPi 4 on other models. You did add it as V4L2 camera instead of MMAL, right? Out of interest, which /dev/video* device did you select or does libcamerify do some magic to show a unique camera device that works?
For the venv I wonder whether it is not required to load the venv within a shell before you can really run an application through it? Generally it is also possible to bypass the install blocker on modern Debian/Ubuntu and install motionEye natively system-wide. See the updated install instruction in our dev/beta README. But I guess it makes sense to update it again and switch to venv at some point.
From the service log, can you check whether you see some line(s) from the libcamerify/python/meyectl binary, resp. the wrapping systemd handler, whether the main process is in a restart loop (instead of only a motion process)? There is
Restart=on-abort, and probably one of the cascaded binaries is causing an abort signal and hence a service restart in turn, which is not related to motion. The "Device or resource busy" also sounds more that it's concurrent motioneye>motion processes blocking each other, while one does/would work just fine.@kni-bo commented on GitHub (Dec 27, 2023):
Hi,
as far as i understand it correctly, since libcamera there is only the possibility to use the rapberry camera with motioneye with libcamerify and v4l. I found the hint with libcamerify here.
As described i add the first camera in motioneye.
When I did the installation, the instructions were not yet updated and I got the message:
Then I did the following:
As I had struggled from problem to problem until then, I was glad that it worked :-)
I have restarted the system once and searched the journal for user motion. Except the messages every 10 seconds as posted above, I don't see any messages from the motion. However, 200 zombies have been created during this time.
Thamks
Michael
@kni-bo commented on GitHub (Dec 28, 2023):
Good morning,
perhaps also important. The number of zombies only seems to increase when movement is detected and video is recorded.
Thanks
Michael
@kni-bo commented on GitHub (Dec 28, 2023):
Hi,
I went back to the journal from the boot to the Lopp and tried to delete everything that doesn't seem important for this case. Maybe there are a few interesting lines.
@crankyfish commented on GitHub (Jan 3, 2024):
Note that the problem also happens under plain old motion 4.3.2 under bullseye libcamerify.
@hrfried commented on GitHub (Jan 21, 2024):
Phew, this was a whirlwind to track down. Just wanted to add for anyone looking here that
libcamerifyis part of thelibcamera-toolspackage. I didn't see that mentioned anywhere aside except in the link below...and I wasn't about to just go installing every single libcamera package in the repos lol.https://github.com/Motion-Project/motion/issues/1434#issuecomment-1060755121
Then just running/modifying the service to prepend
<path>/libcamerifyto the service command as above seems to work fine.i.e., for me (installed this in a venv to test)
ExecStart=/usr/bin/libcamerify /home/dietpi/motioneye-test/motioneye-venv/bin/meyectl startserver -c /etc/motioneye/motioneye.confWill likely work with motioneye from dietpi-software now, since I think it's pulled from the same version as of v9.0.2, as long as
libcamera-toolsis installed...@MichaIng this might be decent temporary fix on DietPi if it works on your end. Working for me on an Rpi4 8gig, latest patch with a raspberry pi v2.1 camera. Just realized I'm in motioneye repos right now but I know you're around. ;)
@MichaIng commented on GitHub (Jan 23, 2024):
@hrfried
Thanks, valuable information. I think we'll go with something like this: https://github.com/motioneye-project/motioneye/pull/2765
A Raspberry Pi 5 with a camera module 3 just arrived here, so I am now able to test all this. Likely I'll add a prompt to the
motioneye_initcommand to prompt for whether a camera module is used, and in case installlibcamera-toolsand set thelibcamerifyoption, if available, otherwise inform users that it is needed for camera modules to work with the modern interface.@AntiSol commented on GitHub (Apr 11, 2024):
Hello, thanks for motioneye, it's incredibly useful to me and I've been using it for years :)
I'm also experiencing this issue.
I have installed motioneye system-wide as per the instructions in the git repo's readme (using pip --pre) on two almost*-identical raspberry pis running bookworm and see this issue on both of them. They both have raspberry pi camera v3 modules installed (one is wide/noir, the other a standard camera), and I've modified the systemd service to run motioneye using libcameraify and added the camera as a v4l device.
meyectl -vreportsmotionEye 0.43.1b1After some time (as @kni-bo points out, depending on how many times motion is detected) they freeze up because they are out of memory. Sometimes, if I'm very patient, the OOM killer will kick in and kill the process, and then things will be OK for a while. If I do a
ps auxI see a bunch of defunctshprocesses much like the output @kni-bo has posted.Interestingly, I am not seeing the errors in the journal that @kni-bo reports, if I do
journalctl --followordmesg --followI don't see anything particularly interesting, and certainly no repeating messages or messages every ~10s.One of my devices is in a position that sees regular motion, and this one tends to freeze up every couple of hours. The other sees motion quite rarely and frequently runs for days or even weeks before it hangs.
@kni-bo I'd appreciate it a lot if you could share the code for your watchdog script? that would be super helpful as an interim fix :)
Perhaps the fact that I have 2 devices might be useful for helping to track this down?
@AntiSol commented on GitHub (Apr 12, 2024):
I've made a little bit of progress in tracking down what's going on here: I did some investigating and the zombie shells are running commands like these:
I now think that the number of zombies and the time to memory exhaustion is only coincidentally related to the number of motion events - as you can see this is a scheduled picture_save event, and it not related to motion being detected.
But I think there must be something about motion events that makes them more likely to cause a problem somewhere, because when the system freezes, it is almost always showing motion in the picture (I stream the video via http from port 9081 and in most cases when the system hangs there is motion in some part of the image, indicated by a red square)
I find it very strange that this relayevent.sh script is getting into the zombie state, because under the hood it's not doing much except hitting the python server with a curl request. This curl request specifies a 5 second timeout and silent failure, so I would expect it to exit gracefully if the endpoint is hanging or crashing for some reason. I can only guess that the response coming from the python http server is very strange and that this might be triggering a bug somewhere in curl or maybe in motion (which is what is calling these events, I can see them configured in /etc/motioneye/camera-1.conf
I looked at the invocation for a bunch of defunct sh processes and all the ones I looked at were for a
picture_saveevent, but I expect the same thing is happening for motion events, too, and that picture_save simply outnumbersstartandstopevents.I also wrote my own watchdog which restarts motioneye if the number of zombies gets above 150, I thought it might be helpful as a temporary measure if anybody else is having the same problem:
@AntiSol commented on GitHub (Apr 12, 2024):
I've confirmed that you still get zombie processes even if you modify the relayevent.sh script so that the second line is a simple
exit 0I now think that this issue is actually a problem somewhere in either motion or libcameraify and probably not an issue with motioneye, see: https://github.com/Motion-Project/motion/issues/1522
@kbingham commented on GitHub (Apr 24, 2024):
Also referencing here in case anyone wants to investigate.
Setting the FPS (i.e. the call that fails "Error setting fps" above) was started but doesn't look like it's been completed.
If anyone wants to continue that work - the patch is at https://patchwork.libcamera.org/patch/15392/
@AntiSol commented on GitHub (Apr 24, 2024):
Just a note to take into account before anybody does choose to donate their time to looking into this libcamera patch, @kbingham has made no attempt to replicate or investigate the zombie issue, is simply guessing that this error message may be related, and has made no attempt to provide a serious rationale as to why this inability to set fps in libcamera would cause zombies. I can't say for sure that they're not related, but @kbingham certainly can't say that they are.
@kbingham commented on GitHub (Apr 24, 2024):
I completely agree. I have not investigated this, nor do I have time to do so.
I'm trying to provide what information I'm aware of from the libcamera project and previous attempts to use libcamerify that were not completed for anyone who /does/ want to investigate this.
@AntiSol commented on GitHub (Apr 24, 2024):
@kbingham it's interesting that raspberry pi are selling devices which seem to exclusively rely on this library (without any mention of that on the packaging) but don't seem to have the resources/will to bother investigating issues caused by said library.
@kbingham commented on GitHub (Apr 24, 2024):
I do not work for Raspberry Pi.
@AntiSol commented on GitHub (Apr 24, 2024):
wow so their response is even more lacklustre than I thought!
@MichaIng commented on GitHub (Apr 24, 2024):
It is the opposite: libcamera is an open source cross OS and device compatible library to access camera devices. Previously, the closed source firmware camera stack and libraries were used, which were RPi specific. Every computer with such DSI camera requires some additional driver/library to access it, like your laptop requires an additional driver to access its internal camera. USB cameras do more processing internally, so they do not require this, also not on RPi. So you can say that RPis have an additional hardware feature to attach cost effective small camera modules, which always require additional drivers/libraries, but RPi Ltd. moved from a closed source camera stack to an open approach with generic KMS + libcamera.
The problem is that many software have adapted to the RPi specific firmware driver/API to access RPi camera modules, and with Bullseye, this stack was deprecated, with Bookworm is was removed, and the camera module 3 never supported it. So libcamerify tries to address this, wrapping the new API into the old one.
I see you found out that it is a
motion+libcamerifyissue. Nasty indeed, as this is currently the only way to make the RPi camera module 3 work with motionEye, and supports RPi OS Bookworm. I do have an RPi 5 and camera module 3 to play around now, but I am also no C programmer and have no experience with neither the camera module, nor libcamera. But if I can help to test or verify something, let me know.@AntiSol commented on GitHub (Apr 24, 2024):
Fair enough, but I'm actually more concerned about how they moved from something that did v4l compatibility well (and was thus usable with most camera software written in the last 2 decades) to something new / obscure / not well supported by most software, which also has buggy v4l compatibility, and don't seem to have anybody attached to their libcamera repo who can even be bothered trying to replicate the problem.
I'll keep at it. The response on the motion issue tracker has been much better.
@MichaIng commented on GitHub (Apr 24, 2024):
The old stack did not support V4L2, but required those closed source (obscure)
raspivid/raspistillblobs, or do I misunderstand what you mean? But at least it did provide a usable MJPEG stream via/dev/video0. Now these device nodes provide other functionality that is indeed weird/non-intuitive, as usually one expects one node per camera: https://www.raspberrypi.com/documentation/computers/camera_software.html#device-nodes-when-using-libcameraSo a good question is why there as not one
/dev/video*node left that can be used just like the old one, as direct full camera stream input, but instead requiring a complex library to process those multiple nodes correctly.@AntiSol commented on GitHub (Apr 24, 2024):
My understanding is that /dev/video0 is a standard v4l device.
if the
bcm2835_v4l2kernel module gives you v4l compatibility for the older camera modules:And I for one can attest that it works great.
The answer to this question is known as the CADT model of software development. You wouldn't bother being compatible with every piece of camera software written over the span of 2 decades, instead you just expect those hundreds and hundreds of projects to adjust to your shiny new library that you can't even be bothered supporting properly. What could possibly go wrong?
@MichaIng commented on GitHub (Apr 24, 2024):
Ah yes, you are right. I somehow thought that e.g.
v4l2-ctlis not able to control the camera modules (with the old driver), but at least it lists them properly. Makes sense. I wonder whether this means that we could drop mmalctl.py as the camera modules are listed (and properly labelled) within the V4L2 camera list as well, or whether there is other special handling for those, or functions in v4l2ctl.py which do not work with MMAL devices.Not exactly the same, as this is about closed bug reports after a rewrite, while here it is about missing (or non reliable/not drop-in
libcamerify) backwards compatibility after a "rewrite". However, a little similar, though at least generally moving from the closed source Broadcom driver and tools to open (source) ones was generally needed at some point, and not done "for fun". I am just not sure about the reason that e.g./dev/video0could not be left as identically usable device node.@AntiSol commented on GitHub (Apr 24, 2024):
I would strongly discourage this, at least until the MMAL interface is obscure or broken somehow. More compatibility is always better.
That's what happens when there is no incentive for people to do the parts of programming that aren't fun. Fixing bugs isn't fun; going through the bug list isn't fun; but rewriting everything from scratch is fun (because "this time it will be done right", ha ha) and so that's what happens, over and over again.You're missing the subtext. It is the same.
In a couple of years there will be a shiny new camera module using some other shiny new library. And when that happens (if not before) the bugs I've filed against libcamera will be closed, never having been investigated.
@MichaIng commented on GitHub (Apr 24, 2024):
But as far as I can see, it is really just the
vcgencmddetection, which got already broken 2 times due to some changes of the output, after I joined the project. So ifv4l2-ctl --list-devicesdoes exactly the same, i.e. either showing the camera module or not, but in a generic reliable way, then I see no point to additionally have another camera type which checks with a less stable and deprecated tool whether one is available or not. But as said, probably there are other places where those camera types are handled differently, I did not further go through the code.Yeah similar. But as said, the rewrite was not done for fun, but as part of a consistent long term project to move from all those closed sources RPi-only Broadcom drivers/libs/APIs to open (source) drivers and standards, which are or can be the same on every hardware. Similarly the switch from legacy GPU framebuffer driver to KMS/DRM, which also broke some legacy RPi-only tools well known, but ultimately means that you can e.g. configure console display resolution and orientation via native Linux
video=command-line parameter, instead of having to use some RPi-only setting in RPi-onlyconfig.txt, which so often caused RPi users to wonder why this does not work on their Odroid/NanoPi/PC whatever other system. The old drivers surely were also a burden for the RPi developer staff, needing to maintain everything on their own, or relying on Broadcom, while now it is just done in upstream Linux development. And this switch basically implied the camera stack switch, being part of the same whole GPU driver stack.However, there is no point to overly discuss this here, as we need to live with what we have now. While I agree with some of your points, I just think it is unfair to throw their work on KMS and libcamera into the same box as this CADT rand, as, while we can discuss particular implementation details, it is overall a huge benefit and the absolutely correct thing to do, addressing the one major criticism point from major parts of Linux and open source community, the Raspberry Pi was always suffering from, and still is when it comes to the bootloader, all being fully of closed source binary blobs, no one else has and can have insights.
However, stopping this topic here. Let's hope the
motionguys have some idea how the zombies issue is caused in combination withlibcamerify. I hope to find some time soon to generally play around with my camera module 3 and motionEye. Maybe I can find a workaround for the issue. Sadly even that there are Python bindings for libcamera, support is most importantly missing inmotionitself. Implementing support for MotionPlus is probably the only sane solution, which natively supports libcamera sources: https://github.com/Motion-Project/motionplusBut this is certainly much more work than wrapping either motionEye itself (optionally) or the particular
motionprocesses for MMAL cameras intolibcamerify.@AntiSol commented on GitHub (Apr 25, 2024):
Perhaps there is a good case for deprecating it after all, as long as there's not a userbase being left out in the cold.
The thing is, those horrible closed-source drivers actually work.
The correct solution is to use/write a driver that has support for the well-established and widely-adopted standard that is video4linux, and not some new, immature, buggy thing that:
As I've said elsewhere, I'll grant that responsibility for the issue does not stem from the libcamera team as such - responsibility lies with raspberry pi for switching to using a nonstandard, immature, buggy library which is clearly not ready for the primetime, and in particular for not providing resources to support said library and help it mature to the point where it is ready.
Maybe I'm wrong and it's not CADT. I hope I am. I guess time will tell as to whether this library sticks around or falls into obscurity and a pile of unread bug reports.
So far, magic 8-ball says, "outlook does not look good".
@AntiSol commented on GitHub (Apr 25, 2024):
@MichaIng also, back on topic, you mentioned a workaround: one nasty-ass workaround is a watchdog script similar to what I posted here. This does at least give you a system that doesn't lock up every few hours. Motioneye should be able to just restart motion rather than needing to restart motioneye (I guess I could do this, too, if I replaced the motion executable with a script)
However this workaround has some pretty significant downsides, e.g when motion is restarted, any motion event / video recording will be interrupted, mjpeg streams disappear temporarily, etc etc. But it does at least stop the whole system from becoming unresponsive.
A possible improvement to this would be to check whether there's a motion event currently in progress before doing the zombie check, and if so deferring the check until that motion event has finished. Note that I say "deferring", not "skipping" - you want the check to run immediately after the timeout as the motion event ends, not "at the next 10min interval", because that could cause restarts to never happen.
Another possible improvement would be to do some fine-tuning to maybe raise the number of allowed zombies to resude the number of restarts without compromising system stability, but I supect that might be difficult as I expect that's going to be very dependant on the hardware you're running on (e.g more ram probably means more zombies are tolerable)
@kbingham commented on GitHub (Apr 25, 2024):
"For the cameras you have so far". They do not work for the camera V3 - nor any other third party camera you may wish to buy or connect to the Raspberry Pi ecosystem.
@AntiSol commented on GitHub (Apr 25, 2024):
And as I have been pointing out for some time now, that (and the decision to use libcamera rather than something mature) was a choice made by the raspberry pi people, not some inherent property of the universe.
This is very true - the vast majority of cameras that I might want to plug into a raspberry pi (i.e just about any usb camera made in the last 20 years, or pretty much anything other than a camera module 3) will just work with the mature / stable / well-supported video4linux.
But anyway, @kbingham, as MichaIng pointed out, we're actually not here to argue, we're trying to resolve this issue, so I'd suggest that if you have the time to read and respond to this off-topic discussion further, then perhaps your time might be better spent making a basic attempt to replicate the issue and actually contributing to the solution, rather than continuing an argument which has already run its course :)
@kbingham commented on GitHub (Apr 25, 2024):
I would love to see this issue resolved. And I'm here to help (with my spare time) anyone who is willing to put the effort in. But you didn't seem to want to do that, just have someone else do it for you. I don't run motion, so replicating this isn't something I can do.
Meanwhile everything you say sounds like an attack on a project I and others work very hard to support and you continue to slander due to the lack of understanding of the technical issues that cause us to do the work in the first place (your replies above makes that clear).
But you're absolutely right. it's off topic here, and it sounds like you can resolve this by fixing the issue in the motion project.
I'll happily help Mr-Dave from Motion at great lengths if he needs any support on the libcamera side. Good luck!
@AntiSol commented on GitHub (Apr 25, 2024):
You could have set up the software and made an attempt to replicate the problem in far far less time than you've already spent responding to this issue. I'd have been more than happy to assist with that if you were struggling. I'd have happily supplied you with an sd card image that you could have flashed in a matter of minutes, had you bothered to ask.
Instead you decided to try to conscript me to test out an unrelated patch in the vain hope that it might solve the problem, based on nothing more than a hunch and a totally unrelated error message, and without taking any time at all to even come up with a justification as to why you think said patch is related, and then refused to provide any assistance at all with doing so or to answer any of my questions about the flimsiness of said hunch.
You'll note that the so-called "attacks" and "slander" about your immature, unstable, unnecessary, unsupported project didn't start until after you admitted that you couldn't be bothered looking into the problem, and had already spent more time trolling than it would have taken to actually look into the issue.
Perhaps in future when you can't be bothered assisting, you'll choose to spend your time on something more constructive than trolling, and then you won't have to hear the awful "slanderous" opinions of the people that you can't be bothered to help (due to your participation in the CADT development methodology).
@kbingham commented on GitHub (Apr 25, 2024):
i think at this stage lets just ask the @motioneye-project maintainers to lock this issue for further comments.
@AntiSol commented on GitHub (Apr 25, 2024):
The issue remains outstanding, largely because you can't be bothered to look into it, and has only been derailed because you chose (twice) to derail it. a more appropriate course of action would be for you to refrain from further unconstructive comments.
@AntiSol commented on GitHub (Apr 26, 2024):
just a note pointing at the fix:
github.com/Motion-Project/motion@629b3babf0For anybody trying to solve this, currently you'll need to build motion from source to get the fix, but it is fixed - I've been running it on 2x pis for more than a day now. 0 zombies, no side-effects that I've noticed,
and 0 totally unrelated random patches applied to libcamera based on the wild guesses of someone too lazy to bother looking.All praise and glory to motion's MrDave for tracking it down! 😁
@MichaIng commented on GitHub (Apr 26, 2024):
I still wonder why this is no issue without
libcamerify. I do not understand the code well enough, but probably it changes the context in which this SIGCHLD "ignore handler" applied. The positive side about it is that it seems to have been legacy cruft anyway, not needed in current motion anymore. So aside of fixing this particular issue, it was a little cleanup as well, and probably this caused some other issues in certain rare circumstances as well 🙂.@AntiSol commented on GitHub (Apr 26, 2024):
Yeah this would be nice to know, but since it seems the libcamera people aren't interested in the quality of their code, and I can't be bothered to do their work for them, I guess we never will 🤷
@MichaIng commented on GitHub (Apr 26, 2024):
As far as I understand, it is/was indeed a motion issue. While libcamerify did have an effect on it, to me it does not look like something that is easy to diagnose from their end, without investing immense time to understand motion code, and how/why it intentionally ignored SIGCHLD in the HTTP thread. And now that it has been fixed, I am not sure whether it is worth it to invest this time to understand why it caused this different motion behaviour.
So be careful blaming anyone here. It doesn't help anyone, and most of us are volunteers, where such is doubled destructive and demotivating: when you donate your spare time in a project, to be used by other for free, and do not get real compensation but blames instead.
@AntiSol commented on GitHub (Apr 26, 2024):
The issue could still be in libcamera. The problem only occurred when libcamerify is being used. The way motion was doing things might be perfectly valid. We don't know and can't be sure without investing even more time than a libcamera person would have needed to, to fully understand what is going on in both motion and libcamera.
This is not going to happen because, as we've established, nobody from libcamera is interested in looking or discussing it. Which is exactly equivalent to not being interested in the quality of their code, which is the core issue Jamie Zawinski so poetically pointed out decades ago when he called out their CADT model. If it's "demotivating" to hear these truths, then frankly the FOSS world is better off without that type of contributor.
Anyway, speaking of demotivating, the dismissive way I have been treated (by others, not you @MichaIng, you've been great) during this whole saga has actually been quite demotivating and depressing, and I don't have the energy to argue about it anymore. I just wanted to contribute my time to getting the problem fixed, it's fixed, yay me. And libcamera might still be buggy, but nobody cares 🤷 . I say close the issue.
@MichaIng commented on GitHub (Apr 27, 2024):
And again, you are using free (of cost) software, which is by its license (typical short copyright notice for (L)GPL)"
from people who spend their spare time to make this available to you for free. You could blame RPi Ltd. for requiring the library too early for their camera modules on RPi, or for not investing enough of their own developer's time to make it a better in-place replacement for the previous API. But even then, strictly/contract-wise seen you paid for hardware, not for software, especially not for every piece of hardware addons and software to work with every other piece of software (which is impossible).
And another "again": motion contained code to explicitly ignore SIGCHLD, which, as far as I understand, implies zombies. I do not understand why this was not the case without libcamerify, but wrapping one piece of software into another, which mounts stuff around to put one API over another, might simply imply a certain change which caused this, without being a bug.
Whichever way you see it, each individual point is IMO enough to make your blames absolutely inappropriate, non-productive/destructive anyway the way you phrase them. Still, I am thankful that you took the time make all sides aware of it, investigating and testing it, which lead to the solution. It would however have happened the same way without blaming libcamera devs or libcamera in general.
@AntiSol commented on GitHub (Apr 29, 2024):
You could blame RPi Ltd. for requiring the library too early for their camera modules on RPi, or for not investing enough of their own developer's time to make it a better in-place replacement for the previous API. Yep, I did that, before the "inappropriate behaviour" started. I was happy to leave it there. If you bother to re-read the entire horror show, you'll note that I was very polite for a long time: even after, for example, the libcamera maintainers demonstrated that they didn't understand how their own mailing list they insisted I join worked, and even after one of them tried to hijack this issue and my time to have his unrelated patch tested. I didn't start the inappropriate behaviour here, all I did was call out inappropriate behaviour.But even then, strictly/contract-wise seen you paid for hardware, not for softwareIt would seem you're not familiar with my country's consumer protection laws.@zagrim commented on GitHub (Apr 29, 2024):
@AntiSol With all kindness ❤️ and respect 🙏 , you really need to cool down now. Neither you or anyone else can demand anything from some other person on the Internet just on the basis that they have shared some of their work to others for free, or decided to donate some of their time for a project they like. Seems like you have a number of your own OSS projects so you should already know this. Yes, one can argue about ethical or moral obligations, but you have no idea what else is going on in that maintainer's life at the moment, and you certainly are not in any contract with them other than the license of that piece of software which certainly tells you the provider of that software has zero obligations to you (and yes, it the grand scale of software industry, that thing does suck badly).
If you don't like off-the-cuff quick suggestions for the possible avenues to inspect the issue, would you like total silence any better?
I do understand your frustration, though, but I do not understand your behaviour now. All respect to you for actually being part of hunting the (assumed) root cause down, but isn't this a bit too much already? 😞
@AntiSol commented on GitHub (Apr 29, 2024):
Absolutely yes.
Yep. I was over it days ago, and said as much.
@AntiSol commented on GitHub (Aug 19, 2024):
hmmm, I'm dubious that your problem is related @LaurentChemla. I've got 2 pis running the fixed motion build and I don't think either of them has restarted more than a couple of times since april, and i think 100% of those were due to power failure.
When you say "After some time", how long are you talking? hours? days? weeks? My devices currently have an uptime of 18 days and are going strong.
The zombie issue will lock up your entire machine, not just motion. I think you probably have a different issue.
@AntiSol commented on GitHub (Aug 19, 2024):
I think you're probably better off filing a new bug report with as much detail as you can, I don't think your symptoms sound the same. I've never seen this "Fix the cause of camera/system locking and restart Motion" message you mention, and my pis are currently enjoying weeks to months of uptime with no issues.
do you see 'defunct' motion processes when you do a
sudo ps aux | grep motion? If not, it's not the same issue.