Error while compiling: compiler v0.0.0.0 was closed

Hi,

Using a debian linux box, I'm having issues whenever trying to reload a plugin. Rust lives under a non-root user with ownership of home/rustuser/. Ownership is re-granted whenever new files are added for mods and such.

This is the error: [Error] Exception while calling NextTick callback (Win32Exception: ApplicationName='LD_TRACE_LOADED_OBJECTS=1', CommandLine='/home/rustserver/serverfiles/CSharpCompiler.x86_x64', CurrentDirectory='')

I've tried chmodding the 'CSharpCompiler.x86_x64' (755) and this hasn't fixed the problem.

I get no warning when starting the server, and have installed all of the required dependencies. Oxide version 2.0.3103, rust version: 1172.69.

Any ideas?

Thanks,
Myles

 

Everything inside the user folder (rustserver) is owned by the user - I frequently re-run 'chown rustserver -R home/rustserver' from root.

Is there any way to know what the missing dependencies might be?

 

Was trying to reload DeathNotes after altering the config.

Just re-ran the LGSM rust debian dependency get as root - everything seems fine. The ones which look most relevant are:

lib32gcc1 is already the newest version.
libstdc++6 is already the newest version.
libstdc++6:i386 is already the newest version.

Tried re-running and this was returned:

(17:27:10) | Reload requested for plugin which is already loading: DeathNotes
(17:27:39) | Timed out waiting for plugin to be compiled: DeathNotes

 

All sorted, kinda. Rust:IO was the problem. I created a new user on my box and followed the LGSM steps, installed oxide, installed Rust:IO and all my usual mods. Same issue as before. I then removed Rust:IO and bam - I can reload plugins.

 

Agreed! But I've tried a variety of different steps, and this issue can only be reproduced by having the rustio dll in the managed folder. Any ideas? I'm completely stumped.

 

Does this offer any more insight? I'm so lost with this...


==> log/server/rust-game-2017-02-26-22:06:48.log <==
(Filename: /home/builduser/buildslave/unity/build/artifacts/generated/common/runtime/UnityEngineDebugBindings.gen.cpp Line: 42)
Exception while calling NextTick callback (Win32Exception: ApplicationName='LD_TRACE_LOADED_OBJECTS=1', CommandLine='/home/rust/serverfiles/CSharpCompiler.x86_x64', CurrentDirectory='')
(Filename: /home/builduser/buildslave/unity/build/artifacts/generated/common/runtime/UnityEngineDebugBindings.gen.cpp Line: 42)
Error while compiling: compiler v0.0.0.0 disconnected
(Filename: /home/builduser/buildslave/unity/build/artifacts/generated/common/runtime/UnityEngineDebugBindings.gen.cpp Line: 42)

 

I know haha

Yeah I've tried 755, 744 and even 777.

I've just spun up another server, this time keeping the LGSM install basically vanilla, then installed oxide, then Rust IO - all from the same user with wget. Able to oxide.reload RustIO. Then wget for a plugin, and oxide.reload works on that too. Might see if I can install everything via wget and edit all configs and such via nano, perhaps the issue is with me ssh'ing via root and sftp'ing via root then chowning everything to the rust user. Not sure.

This is the output of the above:


root@deb2lon01:~# LD_TRACE_LOADED_OBJECTS=1 /home/rust/serverfiles/CSharpCompiler.x86_x64
linux-vdso.so.1 (0x00007ffe65ae0000)
libmonoboehm-2.0.so.1 => not found
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f5c4376c000)
/lib64/ld-linux-x86-64.so.2 (0x00007f5c43b21000)

Not entirely sure what that means - is libmono a dependency?

 

@Wulf - thanks for adding try-catch, little more info on this now. Same issue as before, but this is the new error:

(22:43:16) | User running server may not have access to all service files
(22:43:16) | Error while compiling: compiler v0.0.0.0 was closed unexpectedly

Strange thing is, the user (rustserver) owns the entire user directory (home/rustserver). Is it possible that reloading a plugin is requesting use of a resource outside of the user's directory?

I've double checked, and chowned the dir again. and ensured that home/rustserver/serverfiles/CSharpCompiler.x86_x64 is executable.

Any ideas?

 

I have a similar issue myles. I have a Rust Server running on Linux and a few plugins. Sometimes, and I want to stress it is only sometimes, when I start or the server auto restarts on schedule I get the "User running server may not have access to all service files" message and all the plugins fail to load.

I can simply load them manual from an rcon console. It doesn't happen all the time. I may have to check removing the Rust.IO plugin as I am using that too, and see if it fixes it. Really sucks when it happens.

My file permissions are fine on all the files. The fact that it works sometime and doesn't others is the frustrating part.

But if getting rid of Rust.IO fixes it... I just need a replace Clans plugin.

 

Any update on this?

I'm still getting this error, even when RustIO isn't loaded now - most plugins can't be reloaded.

User running server may not have access to all service files
Error while compiling: compiler v0.0.0.0 was closed unexpectedly

 

I'm running into the same issue when trying to load the HeliControl plugin. Double-checked my perms to make sure the correct user owned the file, then did a recursive chown on the entire user folder to make sure all were owned correctly. Still no dice, and haven't come across any clues quite yet.

 

same problem

> oxide.reload CopyPaste
User running server may not have access to all service files
Error while compiling: compiler v0.0.0.0 was closed unexpectedly

triple checked ownership, permissions are 777

 

Anyone made any progress diagnosing this one? I spun up a new instance from scratch after the last run-in but now after a few weeks I'm running into the same problem. The first error I saw was being caused by the LD_LIBRARY_PATH env var not being set, but afterward I'm still seeing the same errors mentioned above when reloading some plugins (BetterLoot, QuickSmelt, CraftSpamBlock for starters). A few plugins will still reload however (ie Vanish). This is making things rather difficult when trying to tweak config during a wipe cycle because it now requires a full restart, which itself is pretty slow now that the navmesh generation takes so much longer.