| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
This will be the basis for configuration _inspection_.
|
| | |
|
| |
|
|
| |
(But before the watcher task is launched.)
|
| | |
|
| |
|
|
|
|
| |
We want to be able to create the CfgMgr early so that we can give it
to the RPC code, then add a bunch of reconfigurable modules to it,
and only then launch the file-watcher task.
|
| |
|
| |
Co-authored-by: gabi-250 <[email protected]>
|
| | |
|
| |
|
|
| |
Code movement only.
|
| |
|
|
|
|
|
|
|
| |
Right now this just helps us keep the parts of the
configuration-reloading logic in one place, and clarifies what needs
to be owned by the watcher thread and what doesn't.
Moving forward, this will help make the configuration something
that RPC can inspect and change.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This commit executes maint/add_warning with the just added change to
deny string slices except in tests.
I recommend auditing this by checking out the previous commit followed
by running the script yourself and then verifying that the diff is
identical to this commit.
This commit makes cargo clippy fail. We will add exceptions in the next
commit.
|
| | |
|
| |
|
|
|
|
| |
This option will primarily be used by integrators who want to modify
the configuration, either directly or via RPC, before launching Arti
completely.
|
| | |
|
| |
|
|
|
|
|
|
| |
This is _just_ the results of a rustfmt invocation on this file.
Due to #2532, these modules were getting overlooked by our regular
rustfmt checks. I'm planning to circle back later on and fix #2532,
but for now, reformatting these files will make future edits cleaner.
|
| |
|
|
|
| |
These are all aimed at figuring out in more detail what's going on
in #2079 and related issues.
|
| |
|
|
| |
Run maint/add_warning
|
| | |
|
| |
|
|
| |
This is flaky, ignoring until #1607 is fixed.
|
| |
|
|
| |
Thanks to gabi for the suggestion.
|
| |
|
|
| |
Fixes: #1607
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Apparently clippy nightly is better (or worse?) about detecting
complex functions than before, so I'm suppressing these warnings
where they occur.
I have mixed feelings about these warnings: On the plus side,
they really do help to detect functions that are twistier than they
need to be. On the minus side, they get confused by tracing macros,
and the "allows" do pile up. But on the plus side, those "allows"
do provide a way to find functions that need to be refactored,
and they are never uglier than the functions they decorate.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
This effectively reverts 71e3d52f5aeb34ca7bca80053079a8c7505b99ac,
which was itself a revert of disabling this test the first time.
Sadly it still doesn't seem to be reliable. We have agreed on IRC to
disable it for now.
|
| |\
| |
| |
| |
| |
| |
| | |
arti: Make the config watcher debounce interval configurable.
Closes #1589
See merge request tpo/core/arti!2387
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Previously, the `reload_cfg::test::watch_multiple` test would take about
3s to run. This test modifies 3 files and waits for the corresponding
`reconfigure()` events to fire. Because of the
`sleep(DEBOUNCE_INTERVAL)` in `run_watcher`, it would wind up waiting
for about 1s for each of them.
This makes the event debouncing optional, and disables it in the tests.
Closes #1589
|
| | |
| |
| |
| | |
This reverts commit ececf6be2eaffc201666cd3413dc19c025be66de.
|
| |/
|
|
|
|
|
|
|
|
|
|
| |
The flakiness from the `watch_single_file` test was caused by the race
between the config write, and the fake SIGHUP "signal" sent on
`sighup_tx`: sometimes, the sighup would get handled between creating
the config file and writing its contents. In those cases, the config
received in `TestModule::reconfigure` would be `Default::default()`,
which caused an assertion to fail (because the test is expecting to
receive the `ArtiConfig` it wrote to disk).
Closes #1549
|
| |
|
|
| |
`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.
|