| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
`FileWatcher::watch_file` can be used with arbitrary paths.
|
| |
|
|
| |
Disabling until #1549 is fixed to unblock CI.
|
| |
|
|
|
|
|
|
| |
The watch channel should help prevent flakiness in the tests
(`TestModule` uses `maybe_send` to only send the received config if it's
different from the previously received value. This is supposed to
prevent the tests from failing when duplicate update events are
received).
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This also fixes a couple of issues with the previous implementation:
* it enables you to watch for more than just one file/extension per
directory (each directory now has a list of filters. If any of the
filters apply to the path contained in the notify::Event, the
`FilterWatcher` notifies the listeners
* it removes the list watched files from `FileWatcher`. This makes
things a lot simpler to grok: essentially, the file watcher only
ever watches directories, notifying if an "interesting" file was
changed (in our case, the interesting files are files that have a
relevant extension, such as `.auth`, or specific configuration
files, as specified by `ConfigurationSources`).
|
| |
|
|
| |
The `FileWatcher` now uses a `postage::watch` channel under the hood.
|
| |
|
|
|
| |
The event handler will soon be made async, so we need a handle to the
runtime.
|
| |
|
|
|
|
|
|
|
| |
For the most part, this is just code motion.
The only change here is that `prepare` is no longer a method on
`FileWatcher`. This decouples `FileWatcher` from `ConfigurationSources`,
enabling us to use it to watch files and directories that aren't
configuration.
|
| |
|
|
|
| |
The `FileWatcher` doesn't contain the channel for receiving events
anymore, and `FileWatcher::event_matched` was removed at some point.
|
| |
|
|
|
| |
This will let us test our configuration logic without having
to use the `config` crate directly.
|
| |
|
|
| |
That seems often how we do things elsewhere.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
I found this confusing in !2009, where the variable is unused on
Windows: I wondered if this meant our config-reloading only worked on
Unix, since "obviously it would need the TorClient".
But actually the TorClient was only used *in this argument* for its
runtime. The actual reconfiguration of the TorClient is doen by it
being in one of the ReconfigurableModule's.
Change the type of the argument for clarity.
|
| |
|
|
|
| |
Do not complain on non-unix systems that variable client is not used.
It is only accessed within the function on unix systems.
|
| |
|
|
| |
Prompted by https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1917#note_2988815
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, the `ProxySet` (and all the other `reconfigurable_modules`)
were kept alive by the `watch_for_config_changes` background thread,
which was preventing them from being dropped when `run()` exited. IOW,
onion services never received the shutdown signal.
Now `watch_for_config_changes` takes `Weak` references, and the only
strong references to the modules are kept in the
`reconfigurable_modules` local variable in `run()`, which is dropped
when `run()` exits (e.g. on SIGINT). This allows onion services to
execute their shutdown logic on CTRL-C.
Part of #1244
|
| |
|
|
|
|
| |
It's correct that we'd like someday for the `arti` crate APIs to
allow all the different modes supported by `Reconfigure` enum;
this is #1156, and it does not block an HSS release.
|
| |
|
|
|
|
|
|
|
|
| |
Now instead of having a hardwired list of of things to reconfigure,
the watch_cfg module now has a vector of ReconfigurableModule.
As noted in the documentation, I don't intend that this should be
our final API here: It is deliberately not exposed. When we revisit
the structure of `arti` more, we should probably do this
differently.
|
| |
|
|
| |
I have no idea why these became necessary.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I identified the cases to replace by searching for the string
`.report()`. There are a few that I didn't change:
* A couple of cases that used anyhow::Error,
* One case that reported two Errors.
* Two cases in `tor_hsclient::err` that just did
`error!("Bug: {}")`.
I have also not audited the cases in `tor-hsclient` where we're using
`tor_error::Report` manually.
Nonetheless, closes #949.
|
| |
|
|
| |
complete successfully.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
