> > On August 4, 2016 at 10:23 AM Peter Palfrader <wea...@torproject.org> > wrote: > > On Thu, 04 Aug 2016, tor relay wrote: > > > > > > > > > > > > On August 3, 2016 at 11:51 PM Green Dream > > > <greendream...@gmail.com> wrote: > > > > > > Sorry, I didn't understand that your daemon didn't restart > > > after the upgrade. I ran through the upgrade on 2 relays, and apt started > > > the service post-upgrade on both. > > > > > > > > > > Since it is reproducible in my case as well I assume you do _not_ > > have the following constellation: > > > > tor.service is disabled and stopped (I don't use the default > > instance) > > > > > > You should not disable tor.service. > > tor.service is what controls all tor instances. The default service is > tor@default.service. If you don't want it to start, one option is to > move away /etc/tor/torrc. >
It is even more uncomfortable than I thought since logrotate daily reload causes all tor instances to stop if tor.service is disabled, this has certainly not been the case with 0.2.7.6. Why this hack (disable a service by moving away its config) and not the more clean approach like the one take by the RPM maintainer?
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
