support

Last updated: June 27, 2024

This page lists every error message currently included in Psyche and the kernel monitor. If you encounter an unfamiliar problem, it's a good idea to start here.

Note that this page may change or become obsolete over time, and will not necessarily be accurate for your version of the system.

Kernel

[kernel] addresses table corrupted!

The kernel addresses table was set to JSON_INVALID, most likely by a double deletion or a script with invalid punctuation in its name (unmatched square brackets or braces). This will prevent any send_or_queue calls from working.

[kernel] Invocation failed.

Debug kernel only. No program could be found to process a send_or_queue call.

[kernel] invocation failed; unknown module in command-line: <command>

No program could be found to match the name specified for an invoke() call in the send_or_queue function.

[kernel] PANIC: Modules table corrupted! Lost program <name>

The program specified has a module address but not a modules table entry. This could be caused by a double deletion or some other parameter with invalid punctuation (unmatched square brackets or braces), such as a version number. The modules table is a shared resource between all programs, so <name> is not necessarily the culprit.

KERNEL HALTED. If the kernel monitor is installed, it will restart shortly.

Debug kernel only. Elaboration on the above error message.

Remaining modules: <JSON>

A dump of the modules table used for debugging. Elaboration on the "modules table corrupted" message when debugging is not enabled.

[kernel] modules table now corrupted! No program <name>

Strong debugging only. A final check of the modules table is performed after the LASTCMD parameter is updated, and this error message is generated if LASTCMD is the culprit. This most likely means that the SAFE_ENC() kernel macro is broken.

[kernel] waking <name>

Strong debugging only. Not an error; indicates that the result of send_or_queue was to dispatch a request to the delegate to wake up a hibernating user program so it can process the message.

[kernel] holding message <msg> for PID <number>

Debug kernel only. Not an error; indicates that the result of send_or_queue was to wait for a hibernation-enabled program to finish running. If nothing happens after this message appears, then the program is probably stuck, or failed to generate SIGNAL_DONE after its last task was completed.

[kernel] assigned <number> to module <name> in ring <number>

Debug kernel only. Not an error; the program <name> is initializing and the kernel has never seen it this boot.

[kernel] re-assigned <number> to module <name> in ring <number>

Debug kernel only. Not an error, though possibly evidence of a script crash; the program <name> is initializing, and the kernel has given it back its old PID number.

KERNEL: <uuid>
DAEMON: <uuid>
PROGRAM: <uuid>

Debug kernel only. The kernel has just reset or rezzed.

<name> compiled <date> in debug mode; <number> bytes used.

Debug kernel only. The kernel has finished the state_entry() handler and has asked its delegate(s) to send overview reports (modules table data).

<name> compiled <date>; <number> bytes used.

Non-debug kernel only. The kernel has finished the state_entry() handler and has asked its delegate(s) to send overview reports (modules table data).

[kernel] downloading <name> is prohibited; please add manually

A file called <name> has been detected in ring 1 (the root prim of ARES), but for safety reasons ARES refuses to automatically move it into ring 3 (user data), where it belongs. Currently <name> is always "autoexec.as."

[kernel] downloaded data file '<name>'; moved to user memory

The file <name> was received while ALLOW_DROP was enabled. As it was not a script, it has been moved to ring 3.

[kernel] sideloaded data file '<name>'; moved to user memory

The file <name> was received while ALLOW_DROP was disabled. As it was not a script, it has been moved to ring 3.

[kernel] dumping stale message <msg>

A message for the kernel was discovered in the event queue from the last time ARES was running; likely it was generated just before ARES was detached. Since any non-daemon scripts involved have most likely lost their state, it is being ignored to protect system integrity.

[kernel] jumping queue: <cmd>

Strong debug only. A program has sent SIGNAL_READY, so the kernel is reiterating the last message (or LASTCMD) that it was expected to handle. This is called "queue jumping," as any other messages sent to the program since the LASTCMD must wait until it is processed.

[kernel] unqueued <cmd>

Strong debug only. The program named in <cmd> has no outstanding job, so the kernel is sending the next task.

[kernel] busy job <name> rejected event dequeuing

Debug kernel only. When the delegate was asked to start a program, it reported that the program was already running, by sending SIGNAL_BUSY.

[kernel] sending termination signal to PID <number>

The kernel has been asked to shut down a program using the terminate() API call (SIGNAL_TERMINATE).

[kernel] delegation failed; unknown module: <name>

The kernel attempted to do something to the program <name> that the delegate couldn't find, e.g. a script that was recently deleted.

[kernel] rejecting: <name>

The delegate reported that <name> is running, but the kernel believes it should not be running. This often occurs during the boot (kernel reset) process, due to message queue saturation.

[kernel] system initialization complete

Not an error message. The delegate in ring 3 has run out of programs to reset.

[kernel] incoming inventory ALLOWED

Debug kernel only. ALLOW_DROP is now enabled, permitting package servers to transfer files to ARES.

[kernel] incoming inventory CLOSED

Debug kernel only. ALLOW_DROP is now disabled, preventing objects from transferring files to ARES.

warning - sending event triggers to kernel is deprecated and will be removed in 0.6: <msg>

The kernel received SIGNAL_TRIGGER_EVENT from a program that has not yet been updated to send SIGNAL_TRIGGER_EVENT directly to the scheduler, most likely an out-of-date system extension.

warning - creating timers via kernel is deprecated and will be removed in 0.6: <msg>

The kernel received SIGNAL_TIMER from a program that has not yet been updated to send SIGNAL_TIMER directly to the scheduler, most likely an out-of-date application.

not compiled for debugging

The user entered =ddt s to enable strong debugging, even though the kernel does not support debugging.

?

The user entered an invalid option to =ddt.

Kernel monitor

Compiled <date> <time>
default kernel: <name>

The kernel monitor has just been reset.

Detected kernel halt in <name>; restarting.

The kernel <name> has been detected as not running. The monitor will now reset its memory and start it running again. Not sent if the kernel isn't running when the monitor starts.

A crash in ARES kernel <name> was detected. It has been restarted. Please report this at http://develop.nanite-systems.com/?page=deet&s=1

Same as previous; sent automatically to DEBUG_CHANNEL.

not a kernel image

The name entered to k <name> isn't a script in ring 1.

Bad syntax: <cmd>
Enter 'help' for available commands. See documentation: http://support.nanite-systems.com/?id=3001

An unrecognized command was entered into the kernel monitor prompt. If you are attempting to send a numeric signal to the kernel directly, note that the number 0 must be typed as 0 (and not, e.g., 0.0 or 00 by accident)