>
> On August 4, 2016 at 10:23 AM Peter Palfrader
> wrote:
>
> On Thu, 04 Aug 2016, tor relay wrote:
>
> > >
> > > > >
> > > On August 3, 2016 at 11:51 PM Green Dream
> > > wrote:
> > >
> > > Sorry, I didn't understand that your daemon
>
> 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?
>
..that allows one to manage (start/stop/enable/disable) each service
separately using standard tools and methodologies (and not service specific
wa
On Fri, 05 Aug 2016, tor relay wrote:
> Also: you can not start/stop/restart tor.service separately without leaving
> all other tor instances untouched.
tor.service is *not* the default service. tor.service is the collection
of all service instances.
HAND.
--
| .'
On Fri, 05 Aug 2016, tor relay wrote:
> this has certainly not been the case with 0.2.7.6.
You are mistaken. Nothing in that regard has changed for 0.2.8.x
--
| .''`. ** Debian **
Peter Palfrader | : :' : The universal
https://www.palfrader
> On August 5, 2016 at 1:24 PM Peter Palfrader wrote:
>
>
> On Fri, 05 Aug 2016, tor relay wrote:
>
> > Also: you can not start/stop/restart tor.service separately without leaving
> > all other tor instances untouched.
>
> tor.service is *not* the default service. tor.service is the collect
On Fri, 05 Aug 2016, tor relay wrote:
>
> > On August 5, 2016 at 1:24 PM Peter Palfrader wrote:
> >
> >
> > On Fri, 05 Aug 2016, tor relay wrote:
> >
> > > Also: you can not start/stop/restart tor.service separately without
> > > leaving all other tor instances untouched.
> >
> > tor.servic
I would recommend port knocking if u run ssh
tor-relays-requ...@lists.torproject.org skrev: (4 augusti 2016 19:30:11 CEST)
>Send tor-relays mailing list submissions to
> tor-relays@lists.torproject.org
>
>To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.torproj
The exit relay we (Digitalcourage) run gets this warning a lot, but it started
only recently. I guess it is related to the DDoS attacks (syn flood) we get
lately.
Debian seems to set /proc/sys/net/ipv4/tcp_max_orphans automatically so that up
to a quarter of the installed amount of RAM is used
Well, since changing the setting from 2048 to 200,000, my exit is still
running fine, and I'm not seeing a drastic increase in RAM usage.
You said each orphan can use up to 64K of memory. Maybe "up to" is the
magic phrase?
On Aug 5, 2016 10:42 AM, "Christian Pietsch" <
christian.piet...@digitalco
2016-08-01 8:15 GMT+02:00 stig atle steffensen :
> I decided today to turn the node into a non-exit node this morning.
> The stress of not knowing if something will happen again is too much for me
> to go around thinking about.
>
> I will rather donate some to torproject or other exit operators.
2
> > > > Also: you can not start/stop/restart tor.service separately without
> > > > leaving all other tor instances untouched.
> > >
> > > tor.service is *not* the default service. tor.service is the collection
> > > of all service instances.
> >
> >
> > Gosh, you are right there is tor@defaul
Am 05.08.2016 um 18:27 schrieb tor relay:
> Also: you can not start/stop/restart tor.service separately without
> leaving all other tor instances untouched.
tor.service is *not* the default service. tor.service is the collection
of all service instances.
>>>
>>>
>>> Gosh, y
> So there is no way to disable the default instance using systemctl after all?
To answer my own question:
systemctl mask tor@default
disables the default instance for real.
..but I'm still curious why tor@default is a static unit (without [Install]
section)
https://bbs.archlinux.org/viewtopic.p
made a ticket:
https://trac.torproject.org/projects/tor/ticket/19847
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
When upgrading the tor package on debian I get the following syslog messages:
systemd[1]: Failed to reset devices.list on /system.slice: Invalid argument
systemd[1]: Failed to reset devices.list on /system.slice/system-tor.slice:
Invalid argument
Should I be concerned?
Hi,
I ran into some tor restart loop issues after upgrading to 0.2.8.6 on my
pi2 relay.
In short, it takes too long to read router_parse_list_from_string and
hits the systemd start timeout limit causing a restart (and loop)
Full story in the ticket here:
https://trac.torproject.org/projects
* Hack-Tic schrieb am 2016-08-05 um 21:19 Uhr:
> edit /lib/systemd/system/tor@default.service and change TimeoutStartSec=
Please don't write in /lib. Better create a new file
/etc/systemd/system/tor@default@default.service.d/override.conf
and add your change there. When you update Tor at some poi
On Fri, 05 Aug 2016, Jens Kubieziel wrote:
> * Hack-Tic schrieb am 2016-08-05 um 21:19 Uhr:
> > edit /lib/systemd/system/tor@default.service and change TimeoutStartSec=
>
> Please don't write in /lib. Better create a new file
> /etc/systemd/system/tor@default@default.service.d/override.conf
> an
18 matches
Mail list logo
