* Add service manager infrastructure
The changes are (This will be a bit long):
- A ServiceManager class that spawns a background thread and deals with
service lifecycle management. The idea is that service lifecycle code
will run in async functions, so a single thread is enough to manage
any (reasonable) amount of services.
- A Service class, that offers start(), stop() and restart() methods
that simply notify the service manager to... well. Start, stop or
restart a service.
(!) Warning: Note that this differs from mp.Process.start/stop in that
the service commands are sent asynchronously and will complete
"eventually". This is good because it means that business logic is
fast when booting up and shutting down, but we need to make sure
that code does not rely on start() and stop() being instant
(Mainly pid assignments).
Subclasses of the Service class should use the on_start and on_stop
methods to monitor for service events. These will be run by the
service manager thread, so we need to be careful not to block
execution here. Standard async stuff.
(!) Note on service names: Service names should be unique within a
ServiceManager. Make sure that you pass the name you want to
super().__init__(name="...") if you plan to spawn multiple instances
of a service.
- A ServiceProcess class: A Service that wraps a multiprocessing.Process
into a Service. It offers a run() method subclasses can override and
can support in-place restarting using the service manager.
And finally, I lied a bit about this whole thing using a single thread.
I can't find any way to run python multiprocessing in async, so there is
a MultiprocessingWaiter thread that waits for multiprocessing events and
notifies any pending futures. This was uhhh... fun? No, not really.
But it works. Using this part of the code just involves calling the
provided wait method. See the implementation of ServiceProcess for more
details.
Mirror util.Process hooks onto service process
Remove Service.__name attribute
Do not serialize process object on ServiceProcess start.
asd
* Update frigate dictionary
* Convert AudioProcessor to service process
* Added stop_event to util.Process
util.Process will take care of receiving signals when the stop_event is
accessed in the subclass. If it never is, SystemExit is raised instead.
This has the effect of still behaving like multiprocessing.Process when
stop_event is not accessed, while still allowing subclasses to not deal
with the hassle of setting it up.
* Give each util.Process their own logger
This will help to reduce boilerplate in subclasses.
* Give explicit types to util.Process.__init__
This gives better type hinting in the editor.
* Use util.Process facilities in AudioProcessor
Boilerplate begone!
* Removed pointless check in util.Process
The log_listener.queue should never be None, unless something has gone
extremely wrong in the log setup code. If we're that far gone, crashing
is better.
* Make sure faulthandler is enabled in all processes
This has no effect currently since we're using the fork start_method.
However, when we inevidably switch to forkserver (either by choice, or
by upgrading to python 3.14+) not having this makes for some really fun
failure modes :D
I just saw this, and I would be very surprised by that behaviour as a
user. Changing the db path would randomly move the database, and
changing it back (or to anything, really) would not. These kinds of
advanced settings are generally expected to do one thing: Change the
path frigate opens the database from. The end.
* Subclass Process for audio_process
* Introduce custom mp.Process subclass
In preparation to switch the multiprocessing startup method away from
"fork", we cannot rely on os.fork cloning the log state at fork time.
Instead, we have to set up logging before we run the business logic of
each process.
* Make camera_metrics into a class
* Make ptz_metrics into a class
* Fixed PtzMotionEstimator.ptz_metrics type annotation
* Removed pointless variables
* Do not start audio processor when no audio cameras are configured
* Moved FrigateApp.init_config() into FrigateConfig.load()
* Move frigate config loading into main
* Store PlusApi in FrigateConfig
* Register SIGTERM handler in main
* Ensure logging is setup during config parsing
* Removed pointless try
* Moved config initialization out of FrigateApp
* Made FrigateApp.shm_frame_count into a function
* Removed log calls from signal handlers
python's logging calls are not re-entrant, which caused at least one of
these to deadlock randomly.
* Reopen stdout/err on process fork
This helps avoid deadlocks (https://github.com/python/cpython/issues/91776).
* Make mypy happy
* Whoops. I might have forgotten to save.
Truly an amateur mistake.
* Always call FrigateApp.stop()
* Ignore entire __pycache__ folder instead of individual *.pyc files
* Ignore .mypy_cache in git
* Rework config YAML parsing to use only ruamel.yaml
PyYAML silently overrides keys when encountering duplicates, but ruamel
raises and exception by default. Since we're already using it elsewhere,
dropping PyYAML is an easy choice to make.
* Added EnvString in config to slim down runtime_config()
* Added gitlens to devcontainer
* Automatically call FrigateConfig.runtime_config()
runtime_config needed to be called manually before. Now, it's been
removed, but the same code is run by a pydantic validator.
* Fix handling of missing -segment_time
* Removed type annotation on FrigateConfig's parse
I'd like to keep them, but then mypy complains about some fundamental
errors with how the pydantic model is structured. I'd like to fix it,
but I'd rather work towards moving some of this config to the database.
* Ignore entire __pycache__ folder instead of individual *.pyc files
* Rewrite the yaml loader to match PyYAML
The old implementation would fail in weird ways with configs that were
incorrect in just the right way. The new implementation just does what
PyYAML would do, only diverging in case of duplicate keys.
* Clarify duplicate yaml key ValueError message
Co-authored-by: Nicolas Mowen <nickmowen213@gmail.com>
---------
Co-authored-by: Nicolas Mowen <nickmowen213@gmail.com>
* Make logging code self-contained.
Rewrite logging code to use python's builting QueueListener, effectively
moving the logging process into a thread of the Frigate app.
Also, wrap this behaviour in a easy-to-use context manager to encourage
some consistency.
* Fixed typing errors
* Remove todo note from log filter
Co-authored-by: Nicolas Mowen <nickmowen213@gmail.com>
* Do not access log record's msg directly
* Clear all root handlers before starting app
---------
Co-authored-by: Nicolas Mowen <nickmowen213@gmail.com>
* Format makefiles
* Handle all errors in rocm makefile
* Remove CURRENT_UID and GID from makefile as they are unused
* Removed unused vite.svg asset
* Sort frigate-dictionary
