ID:1829466
 
Resolved
Limits placed on startup() were too restrictive.
BYOND Version:506
Operating System:Windows 7 Home Premium
Web Browser:Chrome 41.0.2272.118
Applies to:Dream Daemon
Status: Resolved (507.1282)

This issue has been resolved.
Descriptive Problem Summary:

Using startup() you cannot launch more than two servers per session (meaning until the world is rebooted or restarted). It doesn't matter if there is a delay between startup() calls or no delay at all. After two servers have been started, startup() simply fails and returns a null value from that point forward.

This has been tested in 506.1250 and 507.1281, and the results are the same.


Numbered Steps to Reproduce Problem:
I've made an incredibly simple demo. The expected behavior is that clicking the "TestStartup" verb will launch all four servers without an issue. Instead, only two actually start.

No permutation of args etc. changes anything. Only two calls to startup() are effective until the server restarts.

Demo: http://silkgames.com/random/StartupExample.zip


I'm not sure if this is some sort of intentional security measure or not... if so then a higher threshold would be much appreciated. I'm working on a server cluster system for NEStalgia and trying to automate stuff, and this is a big drag.

Thanks!
I took a look into this and it is indeed an intentional security measure. I thought it sounded familiar. There are two measures that might impact you:

1) Slave instances (started by another world) cannot call startup().
2) The server is limited to 2 startups within a certian period. Past that, the timeout jumps higher.

The latter is the one you're running into. I'm okay with upping the limit in the next release. What limit would cover your needs and allow you some flexibility while still not being completely open?
Thanks for taking a look at this, I really appreciate it.

If it were possible for you to up it to 5 or 6, that would be great. If you need to do something like require a five or ten second delay between each of the permitted startup() calls then that's not a problem either.

Also, the master server that I'm using to call startup() will always be running in Trusted mode, so if you think that it's better to only increase the startup() threshold for servers running in Trusted mode then that would solve my particular issue as well. Thank you!
Will do. I'll up the limit to 6 and I'll probably shorten that if more than 2 servers start up within a certain much smaller amount of time. So maybe plan for a 10s delay and I can throttle to >5s, and that'll be set.

The limit increase will be included in 507.1282.
Right on, thank you very much.
Lummox JR resolved issue with message:
Limits placed on startup() were too restrictive.
Bump. Could we possibly get an "unsafe" mode, like world.loop_checks? I need to start more than 6 servers in my final game. It increases with the amount of players. If not, I do think I have a workaround, so that's no problem either. It'd just be nice to have it built in.

EDIT: I also believe the limit stays when you shutdown the servers, including the main server, without closing Dream Daemon, so that's also worth looking into.
In response to Kamuna
Kamuna wrote:
Bump. Could we possibly get an "unsafe" mode, like world.loop_checks? I need to start more than 6 servers in my final game. It increases with the amount of players. If not, I do think I have a workaround, so that's no problem either. It'd just be nice to have it built in.

EDIT: I also believe the limit stays when you shutdown the servers, including the main server, without closing Dream Daemon, so that's also worth looking into.

I think the problem is that the restriction is not in place for the developer, but for whomever may be hosting the world. Allowing an override like that, rather than as a host option, could defeat the purpose and allow, essentially, a DD-style fork bomb.
In response to Audeuro
Bingo.
Then it shouldn't be running in trusted mode. Also, anyone can easily bypass that, so it does more harm to the developer than good to the host. Perhaps an "Ultratrusted" mode could be made, then? Though, I may not need this feature anymore since I'm changing my networking plan for the game. It'd still be a nice addition. Also, it could just be a host option too, I guess. I don't care how it is done, so long as it is possible.
Honestly, I'd be a tad bit scared if any of DD's security modes did more than raise the limit allowed a little bit. In my personal opinion, DD's security mode is directly indicative of my trust in you as a developer. If I don't trust the software, I'm throwing it in a chroot jail or a new VM so that it doesn't touch my system because no amount of software-implemented security modes will prevent DD from going rogue if Lummox turns into an evil monkey from the great byond and tries to kill everything.

As far as startup() is concerned, though, I tend to take the following approach: Do I trust the people in the world? Do I trust the software? Do I trust the developer?

I lost where I was going with this, so TL;DR: should be separate from security mode, expose a -startuplimit n -- n < 0 = unlimited, n == 0 = none, n > 0 = n limit</0>
That's fine too. I don't really care how it is implemented. Setting the limit is even better.
This would actually be very useful in the server setup that I have planned. I need a master hub server to be able to launch server instances for individual matches in my project. A limit to 2 servers at a time would be really... really inconvenient.
To anyone further interested, see: id:1969593
uhmm.... its very easy to make a dll to do this so long as there isn't like a counter keeping tabs on the overall process limit running on the os
In response to GatewayRa
You don't even need to go that far. You lose the ability for checking Master with both of these methods, but not only can you make a DLL, but you can also use shell(), no need for a DLL call at all. We should post in the other thread, though. This one is already solved, no need to keep it living further.
In response to Kamuna
You lose the ability for checking Master with both of these methods

you can still keep track of all of the processes that are made by the master and handle them externally

for many reasons, id say the .dll is far easier to manage, but i forgot a lot of people here don't do low-level programming

We should post in the other thread, though.

sure