ID:1671259
 
Resolved
The linux/bsd webclient required a the BYOND_SYSTEM environment variable to be set in order to locate the web files. This is normally accomplished through the installer script, but this can be inconvenient for testing different versions. In order to facilliate testing, linux/bsd users can now use the included 'byondexec' script to point to to the version of the BYOND program (DreamDaemon or DreamMaker) that they would like to use. This will automatically set the proper LD_LIBRARY_PATH and BYOND_SYSTEM for the respective program. Eg, "installerless" usage would be: byondexec /path/to/DreamDaemon [file] [port].
BYOND Version:507
Operating System:Linux
Web Browser:Chrome 39.0.2138.3
Applies to:Webclient
Status: Resolved (507.1255)

This issue has been resolved.
Chatters cannot open in the webclient.
the server is located http://www.byond.com/play/2071348944

Lummox stated: "Chatters is acting as if it can't find the ../web dir where the webclient.dart.js and the .dms files are stored."

I've spoken with Stephen001 (he actually runs the server and Chatters builds) and he says everything seems fine on his end. the /web dir is right where the rest of the BYOND installation is, as well as having proper permissions.
BYOND specifically is installed at:

/opt/byond/507.1251/bin
/opt/byond/507.1251/lib
/opt/byond/507.1251/web

The shared objects are in lib, not bin where BYOND seems to distribute them. DreamDaemon is then launched with:

export LD_LIBRARY_PATH=/opt/byond/507.1251/lib
cd /root/Chatters
nohup /opt/byond/507.1251/bin/DreamDaemon Chatters.dmb 6001 -safe -webclient > Chatters.log 2>&1 &

nohup detaches the process and file stdout/stderr file descriptors from the current shell, attaching it to the root process, so I can kill off the SSH session.
To clarify, by shared objects are you referring to other files like byondcore.so, or do you mean the .dms and .js files for the webclient are there also? The webclient's files definitely need to be in the ../web dir relative to the binary.

Also out of curiosity, I wonder if the web dir's permissions aren't allowing a file list to operate, since we get the set of files to send via a file list operation. If you make the dir executable, does the issue resolve?
No, the shared objects I'm referring to are just libbyond.so and libext.so. web folder was already executable, but I've just applied that again. How about the files in the folder? They are rw-r--r-- at the moment?
Any solution for this coming along?
I don't really have enough info on this yet. This is a big one though since it impacts Linux clients, so I'd like to figure it out. If Stephen001 is available to chat at some point, maybe we can bang this out.

For now I'm putting a bug message in so that if we haven't chatted by the time 507.1254 is out, maybe it'll spit out something useful. It'll complain when it has no files to send to the end user.
I have successfully tested on linux with the default install, so you might try that (if it's possible)-- or to simulate with symlinks-- just so we can rule out that variable. I looked over the code though and it should be looking for the files in ../web relative to your bin/ dir, so it's unclear why that is failing. We could also put in some debugging.
Here's an strace:

http://awesomeware.org/Chatters.strace.log

CWD when the process launches is /root/Chatters and the executable path is /opt/byond/${BYOND_VERSION}/bin/DreamDaemon ${DMB_FILE} ${GAME_PORT} ${SECURITY_LEVEL} ${GAME_OPTIONS} > ${LOG_FILE} 2>&1

With these variables:

DMB_FILE=Chatters.dmb
DME_FILE=Chatters.dme
GAME_PORT=6001
GAME_FOLDER=/root/Chatters
PID_FILE=Chatters.pid
SECURITY_LEVEL=-safe
GAME_OPTIONS=-webclient
BYOND_VERSION=507.1251
LOG_FILE=Chatters.log
/root/Chatters contains:

drwxr-xr-x  7 root root    4096 Sep  3 22:28 .
dr-xr-x--- 10 root root 4096 May 16 21:44 ..
drwxr-xr-x 9 root root 4096 Aug 30 22:44 .git
-rw-r--r-- 1 root root 100 Nov 12 2013 .gitignore
-rw-r--r-- 1 root root 360 Jan 29 2014 .gitmodules
-rw-r--r-- 1 root root 176114 Sep 1 17:42 Chatters.dmb
-rw-r--r-- 1 root root 1706 Apr 30 18:22 Chatters.dme
-rw-r--r-- 1 root root 159 Sep 3 22:15 Chatters.dyn.rsc
-rw-r--r-- 1 root root 64 Sep 3 22:28 Chatters.log
-rw-r--r-- 1 root root 6 Sep 3 22:28 Chatters.pid
-rw-r--r-- 1 root root 234741 Sep 2 00:15 Chatters.rsc
-rw-r--r-- 1 root root 1577 Nov 12 2013 LICENSE.txt
-rw-r--r-- 1 root root 780 Nov 12 2013 README.md
drwxr-xr-x 3 root root 4096 Aug 30 22:43 data
-rw-r--r-- 1 root root 4471296 Dec 23 2013 libmysql.dll
drwxr-xr-x 3 root root 4096 Dec 23 2013 rsc
drwxr-xr-x 3 root root 4096 Nov 12 2013 schema
drwxr-xr-x 4 root root 4096 Jan 29 2014 src
Incidentally, while I don't know the cause, I do see the process trying to access stuff that should be beyond the -safe sandbox:

openat(AT_FDCWD, "hsqldb-2.3.0.zip", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = -1 ENOTDIR (Not a directory)
openat(AT_FDCWD, "all_dbs.sql", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = -1 ENOTDIR (Not a directory)
openat(AT_FDCWD, ".gitconfig", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = -1 ENOTDIR (Not a directory)
openat(AT_FDCWD, "websites.tar.bz2", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = -1 ENOTDIR (Not a directory)


These files and directories are in /root, which would be the CWD of the script I ran to launch BYOND (the script itself lives in /opt/byond-support/bin)
stat64("/root/.byond/cfg/byond.txt", {st_mode=S_IFREG|0644, st_size=119, ...}) = 0
stat64("/root/.byond/cfg/byond.txt", {st_mode=S_IFREG|0644, st_size=119, ...}) = 0
stat64("cfg/byond.txt", 0xff875da0) = -1 ENOENT (No such file or directory)
chdir("cfg") = -1 ENOENT (No such file or directory)
chdir("/root/Chatters") = 0
getcwd("/root/Chatters", 512) = 15
stat64("cfg/byond.txt", 0xff875ec0) = -1 ENOENT (No such file or directory)


Near the bottom, presumably after the web client connect attempt I made. Is it just checking this to try to inform me of potential updates, as byond.txt seems to only have version information in?
Can you try just launching this (or just a test program) conventionally (without a script) so we can see if that works? We can try testing a script example on our machine as well. It does seem to be getting confused about the actual cwd for the safe path (unless a third-party such as mysql is responsible for that output).
In response to Stephen001
Stephen001 wrote:
Near the bottom, presumably after the web client connect attempt I made. Is it just checking this to try to inform me of potential updates, as byond.txt seems to only have version information in?

That is probably the server looking up the hub address, which is stored in byond.txt (if you don't use the default).
As there's no particular evidence of it trying to access a web directory here (regardless of path), what kind of prerequisites need satisfying? Any network or firewall concerns?

I'll try a vanilla install tomorrow.
It shouldn't have anything to do with the network, as this is just the server looking for the configuration files on your drive. I have no idea why it is attempting to list those files in your /root, unless it is somehow confused about the cwd. I think this will be easy to isolate with debugging, but it would definitely help if you could test a very basic project because I want to make sure the mysql has nothing to do with it.
No joy on a vanilla install or a test project.

http://www.byond.com/games/Stephen001/Test

Hosting on awesomeware.org:6002, can connect fine on DreamSeeker, no dice with the webclient.

Command is:

export LD_LIBRARY_PATH=/opt/byond/byond/bin
/opt/byond/byond/bin/DreamDaemon Test.dmb 6002 -safe -webclient

CWD is:
/root/Test

Project is:

world
hub = "Stephen001.Test"

client
verb
Test()
src << "Hello!"

What output did you get from the server? There should have been a "BYOND bug" line printed out somewhere.
I'm on 507.1251, so nothing. I'll grab the latest.
BUG: BYOND bug: No files for webclient found in dart/
That's curious. It's acting as if the bin path is empty. That's a good clue for us though.
Page: 1 2