Questions in this catagory:
Evaluator says "Error: invoking _run_tool: Can't exec helper"
Evaluator says "Parse error: Expected `{' at start of block.\nCurrent token class: Semicolon, `;'."
Evaluator says "Error: Expected assignment, function def, type def, or iteration."
Evaluator says "Parse error: Expected `=' in assignment.\nCurrent token class: LBrace, `{'."
- Evaluator says "Error: Failed to convert text to file"
- This means that the evaluator was unable to write to a file created in the repository's storage pool (the "sid" directory). Possible explanations:
The repository server is not running as the right user (almost always "vadmin").
The evaluator is not set-user-id to the right user (the same user that runs the repository, almost always "vadmin").
The repository disk (usually /var/lib/vesta or /vesta-srv) is full.
Some portion of the repository's file storage area (usually /var/lib/vesta/sid or /vesta-srv/sod) is not owned by the user that runs the repository and that the evaluator is setuid to (almost always "vadmin").
- Evaluator says "Error: invoking _run_tool: Can't exec helper"
This error comes from the RunToolServer on which the evaluator was trying to run a tool (not from the evaluator itself). It means that from some reason it was unable to start the tool_launcher helper program (which has special priviledges, allowing it to perform the chroot(2) system call).
Check the [Run_Tool]helper configuration setting (i.e. with "vgetconfig Run_Tool helper") to find out what command the RunToolServer was trying execute. Make sure that it exists, is accessible to the RunToolServer, and is set-user-id to root.
- Evaluator says "Error: RunTool error (2): problem with making files immutable for volatile directory"
- This means that the evaluator was unable to mark files written by a tool as immutable. This probably means that the evaluator binary is not set-user-id to vadmin.
- Tool fails with "Inconsistency detected by ld.so: rtld.c: 1192: dl_main: Assertion `(void *) ph->p_vaddr == _rtld_local._dl_sysinfo_dso' failed!"
Some versions of the Linux kernel randomize addresses used by the run-time loader. (This feature is called "randomized vDSO".) Some versions of /lib/ld.so don't handle this and exit with this error message. Vesta's tool invocations happen in a chroot, so the /lib/ld.so may be different from the one provided with your Linux distribution and may not be able to handle this feature You can probably make this error message go away by disabling the use of vDSO altogether with "echo 0 > /proc/sys/kernel/vdso" on all your machines running the RunToolServer. If this makes the problem go away, you may want to make this change permanent in /etc/sysctl.conf. See also: RedHat Bug 126084 – Inconsistency detected by ld.so.
- Evaluator says "Parse error: Expected `{' at start of block.\nCurrent token class: Semicolon, `;'."
- This error comes because you have called a function and not used its return value. Your code looks like this:
func(arg);
and you're saying, "what block?" Since the func is seen by the parser without using a return value, it thinks it's a function definition and therefore is expecting a {block} as the function body next -- but it sees the ; instead. If you really dont need the return value just dummy it up like this:
dummy = func(arg);
or this in which the underscore character ("_") is the entire dummy variable name:_=func(arg);
- Evaluator says "Error: Expected assignment, function def, type def, or iteration."
-
the line number indicated might be the end of a function definition which is missing a return statement. All functions must end with a return statement: vesta's take on functional language and the wikipedia explanation of "functional programming"
- Does your code look like this:
files = [tmp="text"];
The identifier files is a keyword used in the files clause in SDL model files. You cannot use a reserved word as a variable name. There is a complete list of the reserved keywords on the "Syntax" page of the programmer's reference.
- mountrepos says "vmount /vesta: Invalid argument"
The repository server is denying the NFS client permission to mount the repository. Check your export file. (This unhelpful error message comes directly from the mount(2) system call.)
- Evaluator says "Can't establish working directory /vesta-work/.volatile/01234567/.WD (Input/output error)"
- Make sure that the hostname of the client resolves to the right IP address on the repository server.
- On the client where you're running the evaluator check what "hostname" prints
On the repository server, check what IP address that hostname resolves to with "host client-hostname" or "ping client-hostname"
- Check if the IP address matches one of the network interfaces of the client with "ifconfig" on the client.
When the evaluator creates a temporary directory for a tool invocation, it tells the repository "my hostname is client-hostname, please call me back at TCP port 12345 for information about the contents of the temporary directory I just asked you to create". This avoids tranferring the entire filesystem to the repository server at once and allows the evaluator to observe the filesystem accesses which the tool makes (and thus record dependencies). If the client has the wrong hostname or the cleint's hostname doesn't resolve to the client's IP, the repository server will not be able to connect back to the builder. Another possible cause is packet filtering, firewalling, or NAT (network address transaltion) between the client running the builder and the repository server.
Another symptom of this problem is messages like the following in the repository's logs (usually sent through syslog(3) to /var/log/messages). Note that such messages will show you what hostname the client sent to the server and what IP address it resolved to.
VDirEvaluator::lookup of .WD in 01234567 (clienthost:12345 0x82be230000200002) returns VestaSource::rpcFailure: Can't connect to 192.168.1.2:12345 (Connection refused) (-2)
- Evaluator says "Can't establish working directory /vesta-work/.volatile/01234567/.WD (No such file directory)"
- This could be due to the repository not being mounted properly on the client running the tool. To check whether the volatile root is mounted correctly, try this:
df -h `vgetconfig Run_Tool VolatileRootName`
If the output doesn't mention the repository NFS host (vgetconfig Repository NFS_host) and the repository NFS port (vgetconfig Repository NFS_port), you should tyr unmounting and remounting the repository.
This could also be due to not creating the .WD binding in dot: ./root/.WD.
Here's one example of how this is typically done from the SWIG bridge:
{ // The command to invoke. command = ./command; // The root filesystem to use for this platform (which must include // the executable named by "command"). root = ./root; bridge_name = "swig"; // put your bridge name there swig() { // Set up the shared files in the filesystem where SWIG will // expect them; root can be a function . ++= [ root = (if _is_closure(root) then root() else root) ]; // Add input file to "." . ++= [ root/.WD = _append(input,includes) ]; // ... the bridge function... }; return [ /* ... */ ]; }See the lex bridge dissection and the full documentation of the _run_Tool primitive function.
- Evaluator says "Parse error: Expected `=' in assignment.\nCurrent token class: LBrace, `{'."
- It could be that you have a function defination without the parameter parenthesis: Wrong:
myfunc { // ^ evaluator complains here // ... };Ah, that's better:myfunc() { // ... };
- vrepl says "No permission, inserting /vesta/..."
This usually means that the source repository you're trying to replicate from is not listed in the appropriate #replicate-from attribute in the destination repository. There are several important things to keep in mind for getting #replicate-from set correctly:
Unlike on the command line, the port number is not optional.
The attribute value must match exactly the string you use with vrepl's -s option. (There's actually a trakcer entry about this, as an IP address match should be sufficient but isn't currently.)
The innermost #replicate-from takes precedence. If the source repository is in the #replicate-from attribute on /vesta but not in the attribute on /vesta/example.com, then you won't be to replicate anything under /vesta/example.com (though you might be able to replicate things under other top-level directories).