That message we show about choosing the right version of MongoDB might be a red herring. I’ve got the latest version of MongoDB we support running on my Windows 10 Enterprise machine.
Could I get the installer log? That should explain what’s failing.
Our Repository installer creates an installation log in the system’s temporary directory. On Windows, the log will be created in the user’s local temp directory, usually C:\Documents and Settings\%USERNAME%\Local Settings\Temp . The default name of the generated log file is bitrock_installer.log , but if the file already exists from a previous installation, the installer will try to create an unique filename trying bitrock_installer_[pid].log and bitrock_installer_[pid]_[uid].log where [pid] is the PID of the process and [uid] is an unique identifier.
Also! Just to warn you, non-server editions of Windows have a very low limit on how many concurrent connections they’ll support so you may hit a wall if you try to have more than 5 Workers on the farm when using a direct connection. If your old database machine was running a non-server edition you should continue to be okay.
So this is about as close as I find as far as an error log in my temp file: installbuilder_installer_6968.zip (997 Bytes)
To your last point; yes, our previous install of deadline did support all the machines we needed but thanks for the reminder.
This is a newly built machine on the same network so I am wondering if its a permissions thing or even some hardware issue.
Thanks for your help
Thanks! Unfortunately there’s not much more useful info in there - I’d hoped the stderr stream would have a useful error for us, but child killed: unknown signal doesn’t do much for me. It does sound like some other process is killing the mongo process we start to verify the mongo version, but other than a very aggressive anti-virus I’m not sure what would trigger that. I can’t find previous occurrences of this issue in the ticket system either.
There’s two ways forward here, with #1 being the most likely to get your database install done, and #2 the most likely to figure out why the installer is failing:
Manually install the database with these steps to avoid whatever issue the installer is having with this Windows machine, or have the same failure but with a better error message. It’ll be more work than having the installer hook everything up for you, but should be easier to troubleshoot.
When the installer fails and shows you that popup, the temporary directory everything gets unpacked into is still in place. With that in mind, you could try to run the command the installer is using to see if you encounter the same killed process behaviour, or if we get different behaviour. That’ll prove if the issue is with this executable, or with how the installer is running it.