TOR relay keeps dying

After updating from OpenWRT 15.05.1 to Lede-17.01.0, I'm having problems running a TOR relay (no exit).

I keep getting this message:

Apr 04 19:25:04.000 [err] Out of memory on malloc(). Dying.

In OpenWRT it worked fine, even with an uptime of over six months.

Should this be put in a bug report?

Hardware: Netgear WNDR4300.

That is not a bug, you need to tweak your settings and/or run less daemons.

Question: Why did it work perfectly in OpenWRT 15.05.1?

Yes, I have 'tweaked' my settings in TOR, to the point to just running the relay, and nothing else.

In OpenWRT I was running the relay (no exit) and an OSDir.

In Lede, I switched off the OSDir, and it did run a little while longer, but then it still died.

Surely, if it ran perfectly in OpenWRT 15.05.01, it should work in Lede -- or do fewer things now work in Lede?

Regarding demons, yes I have a few running, just the basics, like I did with OpenWRT.

Well, it might also be related to the tor version is use.
In 15.05.1 you used while in LEDE 17.01 the version is and in LEDE master
You might need to tweak tor settings.

But as the newer Linux kernel takes a bit more memory, it is possible that your previous config causes tor's memory usage to exceed the available RAM amount after a while.

You might test again with 15.05.1 and look more closely into memory consumption (both system memory in general, and then specifically tor)

I have done enough tweaking. I have only the bare minimum of the TOR relay (no exit node) going. There really isn't that much to tweak.

And no, I'm not going to waste yet more time on it. If it doesn't work, it doesn't work.

I'm using a WNDR4300 (Ver 1), which has only 128mb of RAM, which isn't that much.

Thus, we can now clearly state that a TOR relay will not work on Lede-17.01.0 on just 128mb of RAM.

Can zram be helpfull?

It seems like a good possibility.

But sadly, it's not available as an opkg package.

It seems that Lede-17.01.0 will not be that useful for 'legacy' routers.

It works fine on 64/128 devices, just because you wont bother to do some research doesn't mean that it doesn't work.

just because you wont bother to do some research doesn't mean that it doesn't work.

No, I have a life.

When an OS is released as 'stable', it should be stable. If I want pain and agony, and if I want a massive amount of my time to be wasted, then I will dedicate my life to trying to figure out why TOR keeps dying in Lede-17.01.0 -- or I will use Debian unstable (SID).

Since there's no device with the infinite RAM/storage just yet, I'm curious as to how would you suggest the "stable" swapless OS should behave when users install and run packages with requirements which exceed hardware capabilities?

I guess it would be quite some news to run Debian unstable and tor on a WNDR4300, even bog standard x86 would be quite challenging with 128 MB RAM (I'm not saying it's totally impossible (on x86), but neither the Debian kernel, respectively its initramfs, nor apt wil particularly appreciate running in such a constrained environment without special tweaking - that's before actually running any optional userspace services).

It did run fairly well in OpenWRT 15.05.1. What's the explanation for that?

And now with Lede-17.01.0 it doesn't work:

Apr 05 20:52:33.000 [notice] Bootstrapped 0%: Starting
Apr 05 20:58:32.000 [err] Out of memory on malloc(). Dying.

Point made: Lede-17.01.0 can work fine on 'legacy' devices, but don't be able to run additional services (like TOR) on these devices. If you want to run additional services, get a router/device with much more RAM than the legacy 2012 Netgear WNDR4300 (which only has 128 mb of RAM).

Use OpenWRT 15.05.1 instead. How's that for a solution?