| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |/ |
|
| |\
| |
| |
| |
| | |
Clear away some misc todos in tor-hsservice.
See merge request tpo/core/arti!1819
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| |\ \
| | |
| | |
| | |
| | | |
hsservice: Log hsid whether we just generated it or not.
See merge request tpo/core/arti!1830
|
| | | | |
|
| | |/
| |
| |
| |
| |
| | |
With this change you can find your hsid in your logs
(if safe logging is off) even if you forgot to notice it the first
time around.
|
| |\ \
| | |
| | |
| | |
| | | |
tor-hsservice: If the error is fatal, do not retry the desc upload.
See merge request tpo/core/arti!1821
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The errors returned by `upload_all` are now all fatal, so we there is no
point in retrying `upload_all` on failure.
Note this will exacerbate #1155, as it will cause the seemingly
transient time skew issues to become fatal (the corresponding error type
is `Bug`, so in principle they ought to be fatal)
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | | |
We're going to reuse this for other kinds of storage error.
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This is needed for the replay logs.
It's a shame that CheckedDir is (i) a bit unergonomic (ii) has an
extra bool in it, or we could pass one of those instead of these two
arguments.
Since HS's might be created after startup, TorClient must have these
fields.
|
| | | |
| | |
| | |
| | | |
create_storage_handles_from_state_mgr (fmt)
|
| | | |
| | |
| | |
| | |
| | | |
This will allow us to more faithfully model the actual Arti state
directory layout.
|
| | | |
| | |
| | |
| | |
| | | |
This is to prevent current use of the same directory of replay logs by
different instances.
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This ought to have the hash algorithm name in it or we'll have trouble
if we want to change the hash algorithm in the future. (Strictly, we
could just choose a different magic but the string was rather short.)
Add a newline, which is often convenient in file headers.
And "onion" to mean "onion swervice" is improper.
|
| |/ /
| |
| |
| | |
Make `#[cfg(target_family = "unix")]` appear only once.
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| | |
The publisher now returns `FatalError`s, so we don't need `ReactorError`
anymore. Addresses a TODO HSS in publish/reactor.rs
Part of #1129
|
| | | |
|
| | | |
|
| | |
| |
| |
| | |
This is another type of fatal error.
|
| | |
| |
| |
| | |
We're about to use this (in the publisher reactor).
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| | |
The publisher logs a nice `info!` message when it receives the shutdown
signal. The publisher can infer that the service is shutting down from
the errors received on its various receiver channels (i.e. from the
errors that suggest the sender was dropped), but listening for the
shutdown signal is nicer.
|
| | |
| |
| |
| |
| |
| |
| | |
This will be used by the descriptor publisher soon (we want to abolish
its `ReactorError` altogether, and to do that, we need to get rid of
`ReactorError::ShuttingDown`. `ShuttingDown::Terminate` happens to be a
suitable replacement).
|
| | |
| |
| |
| |
| | |
This moves us one step closer to removing ReactorError in favour of
FatalError (see the TODO HSS above ReactorError for more details).
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Previously, this would return `ReactorError::PublishFailure` if the
upload failed. However, that error wasn't used for anything other than
logging.
Instead of returning the error, we now log it inside
`upload_descriptor_with_retries` and return an `UploadStatus` describing
the upload outcome. This will enable us to abolish
`ReactorError::PublishFailure` (and eventually replace `ReactorError`
with `FatalError`).
|
| |/
|
|
|
| |
The failure to build a descriptor out of seemingly valid parts is an
internal (irrecoverable) error.
|
| | |
|
| | |
|
| |
|
|
| |
This line is too long.
|
| |
|
|
|
| |
We already log the outcome of the HsDir upload in the function that
calls this code.
|
| |
|
|
| |
This also wraps the line.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, it was possible for the `IptPublishSet` used to generate the
descriptor and the `IptPublishSet` `note_publication_attempt` to
differ. Now, the publisher generates the descriptor using the same
`IptPublishSet` it calls `note_publication_attempt` on.
Note that as a consequence, the publisher generates a new descriptor
just before _each_ HsDir upload. This means each HsDir could, in theory,
receive a different descriptor (not just in terms of revision-counters,
but also with a different set of IPTs). It may seem like this could lead
to some HsDirs being left with an outdated descriptor, but that's not
the case: after the upload completes, the publisher will be notified by
the ipt_watcher of the IPT change event (if there was one to begin
with), which will trigger another upload job.
Previously, the publisher would only generate a single descriptor for
each time period (all HsDirs in a given time period would receive the
same descriptor).
Closes #1097
|