Improve systemd boot semantics of tails-wait-until-tor-has-bootstrapped.service
In the current state of
feature/jessie, anything that wants to start after
multi-user.target won't start unless the network is up and Tor is configured correctly. Besides, as seen on #8262, systemd won't consider the system to have fully started unless that's the case. Is this what we want? Do we need to introduce another target instead?
Introduce a dedicated systemd target for "Tor has bootstrapped" state.
... and move tails-wait-until-tor-has-bootstrapped.service from
default.target to it. The main effect is that anything that wants to
start after graphical.target or multi-user.target does not have to wait
for Tor to have bootstrapped (which could very well never happen, e.g.
when working offline) anymore.
#3 Updated by intrigeri almost 3 years ago
- Subject changed from Check systemd boot semantics of tails-wait-until-tor-has-bootstrapped.service to Improve systemd boot semantics of tails-wait-until-tor-has-bootstrapped.service
- Status changed from In Progress to Resolved
- Assignee deleted (
- % Done changed from 0 to 100
- Type of work changed from Research to Code