In case anyone is interested, I updated the binaries for sn_httpd with the target set for this test net: Release v0.3.2 · traktion/sn_httpd · GitHub
Edit: I’ll update the docker image when I get a mo too. I’ve not had chance to participate in this network much yet, unfortunately!
pretty hopeful the CPU usage will drop off when the network reaches larger scale so large shut downs of nodes affect each system less and less.
I could get sn_httpd (using sn_client libs) working with Termux only, but it errored when trying to start a node, unfortunately.
Ive been having a problem trying to start >20 nodes on this box using the launchpad. I think I sussed it.
I have 308Gb free on / as reported by launchpad. df tells me I have 322Gb free but its in the same ball park.
I have ~/.local/share/safe on its own partition on a 120 Gb SSD at /dev/sda1 , ~103Gb reported available from df
It seems like node-launchpad is correctly storing chunks, logs etc correctly on /dev/sda1, but as there is only room for 20 nodes there, that is all it will start.
I will make another symlink to another 500Gb partition I just freed and then see if I can start more nodes.
Maidsafe has this been carefully considered?
Some greenhorns arrive with a terabyte to spare ends up starting 250 nodes. Mayhem ensues and they run for the hills never to be seen again.
My understanding is LaunchPad starts as many as it can per storage allocation, so if you allocate 1 Terabyte is it going to start 250 nodes?
My thinking is that hopfully it will be possible to choose connecting with port forwarding in the node launcher or any way that is used to start nodes.
If you port forward then you know that the ports are open, one less thing to worry about. Even if a keepalive would also be nice to have.
It turns out you can reduce the number of nodes by pressing ‘O’ to set resources and inputting a new number. It will kill the nodes that are now surplus to requirements. So if you set 50GB and 10 nodes started reducing it to 25GB will result in 5 being killed. No choice in which - it goes from the highest number down. And if you add nodes by increasing the number you have to do a ctrl-g start the new ones.
But @user_space is right that if you want more control over things use safenode-manager.
I don’t have nodes running in DO and only 1 in AWS but your Network Size graph looks a bit like an inversion of my router’s graph for the port my RPi4 is on with its 5 nodes:-
Time is GMT on my graph.
So this just another example that nodes leaving and joining causes more traffic for remaining nodes. I’m not tracking CPU but I imagine it was somewhat higher.
thanks for sharing good to know it was not just a local thing 
I can also see an increase of in out data at the same period as well
So I’ve had some weirdness today, I might of accidentally killed all my nodes 
that I launched using the new node-launchpad.
I access the host, which is headless over ssh, and use a unprivileged user to run safe - I elevate to root using sudo [ Debian Bookworm 6.1.90-1 (2024-05-03) x86_64 GNU/Linux ]
So, it seems that when I logoff the SSH session, all the nodes are killed… When I log back in on SSH, they all get started at the same time which tanks the machine…logoff again, then all get killed 
done some poking, and the service definition is being created under ~/.config/systemd/user/default.target.wants as safenode1.service
running systemctl --user status safenode1 confirms it’s running under a user.slice.
CGroup: /user.slice/user-1000.slice/user@1000.service/app.slice/safenode1.service
Default seems to be kill all user slice sessions on logoff 
I think it can be over-ride by elevating to root, and using loginctl enable-linger <unprivalegd username>
also, after the ssh logoff, node kill, ssh logon… node-launchpad status shows all the safenodes as stopped, but a ps -ef shows them running - you then can’t use node-launchpad or safenode-manager to stop / start / control the nodes…
Maybe it’s by design that nodes only run when you are on the machine ? Thought I would mention it, as if lots of new people using this to run nodes, could be undesirable to have the safenodes up and down all the time.
J
The dreaded binary vs decimal. The lies the drive people created. Memory is binary sizing and drives are extension of memory so should always be reported in binary. But hey lets dumb down everything and make money off it. And comms has always been in decimal, but its not memory related.
Be great if launchpad had options for the highlighted node, like stop, kill, start, status, etc
And with launchpad (TUI for node-manager) and node-manager would allow the creation of only one wallet to use for all nodes. (or select wallet for each node individually). Save worrying about doing token collection into one wallet manually when you want to use tokens, separate wallet ofr each node is a carry over thinking from when there would only be one node per subnet
Code is there now to forward earnings to a single wallet. Just make it one that you own.
Can we use it? Be nice if launchpad allowed the creation of that one wallet as well and be able to use it for client in the process. @joshuef (the fall guy 
) can you find out if the TUI will be able to do that?
I’d hope so, haven’t looked at what’s happening there but it would be fantastic if we could.
In the initial, yes. Though users will be able to earn without forwarding too. So they could well save up and spend it. how that looks from a UX pov vs earning etc is another Q that needs straightened out.
We’ll be iterating over a few aims.
Because it’s not there yet Doesn;t mean it wont be there soon. But we’re busy wee bees at the moment.
The functionality is there long latent, but actually the wallet isn’t yet in a place wher ewe want folk to try this (ie, it doesn’t feel like “this is my forever wallet” yet, which could be problematic).
Discord switched to a new naming setup recently. I’m adding a command to clarify thi, I think it might be helpful.
From where they were. Though depending on reboot length they may yet be shunned… Tolerance here needs to be poked at.
It’ll come.
one thing after another! haha, there’s quite the list of wants growing, which is awesome. But aye… bit by bit by bit!
edit:
There’s a good chance we bring this down soon. Hopefully to test some discord integrations pronto.
Are you going to merge this into main? It seems to have performed as well or better than the last stable test.
Sounds like the ‘forever wallet’ is some way away. I noticed that work on the account packet stopped a while ago and was wondering about this before I got up today.
It’s a bit of a hole, quite an important one! A hole in both the UX and in how apps will access the wallet and integrate into their UI. If you can share any thoughts about the latter I’d be interested, for both CLI and GUI apps.
So… I left my (test) machine running over night and this morning it was unresponsive. Had to power it down and restart it that way. On restart it was
again also non-responsive.
I decided to just re-installed linux mint.
I did not realize that increments of 5GB meant that 1 node would be created for each 5GB. I thought that was just a total allocation of space to a node.
Running 10 nodes now. Machine not struggling at all.
I was trying to start 600 nodes by allocating 3TB yesterday. Ouch.
Got the latest vdash from cargo. Nice.
Managed to load all 10 log files at once using,
vdash /home/ubuntu/.local/share/safe/node/safenode*/logs/safenode.log
vdash is amazing.
Haha that was exactly my fear. I did not see a limit to what it starts when I had look.
Many people will do this, most wont find it amusing.
Idk who works on this, so just going to ping @joshuef (sorry) you get pinged so often what is one more 
I just experienced something very similar, not sure what is happening here.
I closed out my ssh sessions last night for the first time since starting the nodes which have been running just fine.
However the first thing I checked this morning was my state table which was almost non existent.
Mild heart attack, did all my nodes die, ssh in and check peer count, 3 to 5 peers per node.
10 minutes later connection tracking is where it should be and connected peers are way up.
This looks an awful lot like @Jadkin is on to something. sorry I will not ping you again (today) @joshuef 
