Why can't I directly start a job in the DEAD state?
As a safety mechanism, Job2Do tries to enforce every run of a job to end in either
a SUCC or FAIL state. Not only does this preserve a clean run history, but it also
lets any pending child (dependent) jobs know how to proceed. If you want to re-run
a killed (DEAD) job without having to force it to SUCC or FAIL, you can Reset it.
This has the same effect as loading the job as a brand new job. Back to top.
Why did my job run (or not run) when I expected?
Understanding automated jobs starts in a complex batch can be confusing, especially
if you have dependent jobs that cross over midnight. However, there are a few basic
Jobs never run automatically more than once per day (the leftmost column in the job
table shows a check mark if the job has run today).
Jobs never run automatically on the same day if they were created or edited after
their scheduled start time.
Dependent jobs never run before their parent(s) in the same day. The exception to
this rule is when dependent jobs are defined to have parents that start after them,
which means that they are dependent on previous days' runs of the parents.
Jobs that have gone into a PEND state remain there until their parent(s) enter the
required state (SUCC or FAIL), regardless of whether that happens today or on some
In general Job2Do takes a conservative approach. When there is any ambiguity as to
whether a job should automatically start, it does not. You can prevent some confusion
by minimizing dependent jobs whose dependencies cross over midnight, although such
dependencies are supported. Back to top.
Why do I see nothing in my stdout/stderr logs when my Windows job fails?
The short answer is, check your "OS Error" by right-clicking on the failed job (or
any failed run history in the history panel) and choosing "Get OS Error..." The
For Clients running on UNIX variants you can configure a default shell to pass commands
to (e.g. sh, ksh, bash, etc.). The shell will capture any stdout/stderr streams and
return them as the stdout/stderr of the shell. In addition, the shell generates
its own stdout/stderr. Therefore, in both the case where the target program itself
fails and the case where the shell fails to find/execute the target program, you
will usually find some logging in one of stdout/stderr.
On the other hand, in Windows your command is passed directly to the OS. This means
that if your command script or binary is not found by Windows or cannot be executed
by Windows, then Windows will return an error. However, in this case Windows does
not produce any stderr/stdout log streams. It simply produces an error. The most
likely cause is that your command is not found by Windows because you've spelled
the binary or path to the binary incorrectly.
To confirm this, check the OS error by choosing "Get OS Error..." after right-clicking
on the failed job. Alternatively, you can wrap your command in a DOS CMD shell to
capture the OS' output. For example, if your original command was "foo", then change
it to "cmd /c foo", re-run, and check your stderr log (choose "Get Stderr Log..."
after right-clicking on the job). Finally, another option is to directly inspect
the log of the Client process on the target machine (not be confused with the stderr/stdout
logs of the job itself). This log can be found in the "Client/log" subdirectory of
your installation directory. Back to top.
Why can't I see my job in the Jobs panel?
Except for the connected graph button, which overrides all filters temporarily, all
the navigation panels and buttons in the GUI also act as layered filters against
the list of jobs in the jobs panel. Most likely you have forgotten to clear one or
more of these filters. Do the following:
Select "ALL" in the Groups panel.
Select "ALL" in the Clients panel.
Delete any text from the text filter in the toolbar.
Make sure the full text search panel is either closed or the text is cleared.
Select the "All" button in the toolbar.
Now all jobs should be visible in the jobs list. Try using the text filter in the
toolbar or the full text search to find the job you're looking for. Back to top.
Why do I see a client with a raw IP address showing up in my Client panel?
This happens when a Client is started on a machine that has dynamically connected
to your network, e.g. using DHCP. In this case the machine has no properly defined
name in your DNS. Even though the Client may have its own local name, this name is
not a recognized, fully-qualified Internet machine name (FQDN). You should not be
running Clients on such dynamically connected machines. Not only is it potentially
insecure, but even if you did define a job to use the IP address that you see in
the Client panel, there is no guarantee that the next time this same physical machine
connects to the network it will receive the same IP address on your network, and
therefore there will be no way for the Server to send commands to it. Back to top.
Why is my Client showing up as unconnected (red) in the Clients panel?
First, make sure that your GUI is connected to the Server (check the Server status
at the bottom of your GUI's screen). If your GUI is not connected to the Server,
then all Clients should be showing up in red.
Next, if your GUI is connected, but your Client is still showing up in red, carefully
check the list of Clients and make sure that your Client is not showing up under
some alternative or similar name. Note that Client machine icons appear in the Client
panel both based on job definitions (jobs using that Client name) and based on Client
heartbeats sent by active Client processes on the network. This means that if your
job spells the Client name slightly differently, you might have 2 similar Client
names appearing, one with a red icon for the misspelled Client name and one with
a green icon for the Client that is successfully connecting.
If after doing the above checks you still see a particular Client(s) showing up in
red while others are green, then directly check the output of your Client process.
You need to go to the Client machine to do this. If your Client is having network
issues trying to connect to the Server, you should see error messages in the Client's
log. If your Client is running on a different subnet from your Server's subnet or
there is a firewall between the two, then you need to make sure that traffic is not
being restricted. Make sure that the port you're using (default port number=3310)
is not restricted by any network devices sitting between the Client and Server machine.
Back to top.
Why can't I see more that 1 month of job run history?
As a performance compromise job run history is limited to a 31-day window, i.e. job
history older than 31 days is deleted from the database on a rolling basis as new
run history is created. Future versions may make this windows size configurable in
a Server property. Back to top.
Can I directly query the job database to generate my own reports?
The job database is implemented using an embedded database. Currently this database
is not made visible to any process but the Server. If there is enough demand, we
will consider releasing a version based on MySQL or Oracle. However, by their very
nature these databases require more expertise to set up and maintain. Some basic
built-in reporting is planned for future releases. Back to top.
Are passwords embedded in my job definitions safe?
On the server side, job commands (including any embedded passwords) are stored in
encrypted format (unless you chose the no encryption option during Server installation).
When job data is passed between the GUIs, Clients, and Server, it is always encrypted
using SSL. Therefore, passwords in text commands are only visible in cleartext on
your GUI screen and only if the job definition panel is open.
This means that if you leave your job definition panel up with a text-based job's
definition containing an embedded password, then someone could walk by your desk
and see it. Unfortunately, since a text-based job's command is "free" text, there
is no easy way to identify and single out passwords within the text for screen hiding
(e.g. using bullets in place of the actual characters). Note that plug-in jobs can
define their own UI components, thereby separating out the password and using a proper
password field. For example, the FTP plug-in does this to hide the password from
In general we recommend that you keep any machines with GUIs locked down or at the
very least employ a locking screensaver with a short timeout. If you are very concerned
about passwords being left visible on the GUI, then we recommend that you try implementing
a plug-in with a password field. Back to top.
Why am I not receiving alert emails?
First, make sure that you have spelled the email addresses correctly. Second, make
sure that the alert emails are not going into a spam folder. Third, make sure that
you have properly configured the SMTP settings in the Server's properties file (J2DServer.properties).
Check with your email server administrator on this configuration. Finally, if you
are positive that everything has been set up correctly and you are still not receiving
alert emails, check the Server's logs directly to see what type of errors it may
be generating when trying to send emails. Back to top.
Why is there a limit on the size of an "inline" script that I can place in a job's
All jobs are stored in a database and the database schema limits the job representation
to a 1,024 bytes text column. Arbitrarily long job commands raise some database design
issues. 1,024 bytes was chosen as a reasonable compromise to allow "quick and dirty"
scripts to be "inlined" into job definitions' command lines.
Practically speaking, if your command is any longer than this, then you should seriously
consider storing and managing the code properly in a separate file. The command text
area is not a proper script development environment. You should try to limit inline
scripts to small code "snippets." Back to top.
Can I import holiday calendars created from scratch?
Yes. You can do this via the database export/import feature ("Tools" menu, "Import
Job Data..." Menu item.) However, you will need to create a properly formatted XML
file for import. See the schema here. Note that since holidays are highly country-,
industry-, and application-specific, even after obtaining 3rd party holiday data
and re-formatting it according to the schema, creating holiday calendars will likely
involve some manual work to adjust the calendar to your needs. Back to top.
Do other users with GUIs see the changes that I am making?
Yes. The system is a real-time distributed system. All online GUIs will see all changes.
Changes to job states will be visible immediately. Changes to job definitions will
be visible once you have pressed the "Save" button and committed your changes. If
2 users are editing the same job, then whichever user saves first "wins." Back to
Does the system support different user accounts?
No. The system was designed to be used by a single administrator or small group of
administrators. GUIs should only be installed on secure machines that can only be
accessed by trusted administrators. Clients should be installed under accounts with
restricted access limited to the purpose of the jobs running on the Client's machine.
That way, even if a malicious user gains access to a GUI and attempts to create malicious
jobs, the damage will be limited. Back to top.
Can I run jobs on remote client machines outside my LAN/WAN?
Theoretically, yes, as long as the ports you are using are opened up on any networking
equipment that your communications need to pass through. However, it is not recommended.
Make sure that you have the approval of you network administrator before attempting
to do this. The reverse topology, running the Server outside a secure network and
allowing access to Clients within the network is a severe security breach and should
never be attempted. Back to top.
Why can't I execute “Start” on a job (Why is the “Start” action disabled in the
Most actions on jobs are only enabled if the Client that the job is defined to run
on is online (connected to the Server). Check the status of the target Client in
the Clients panel. If the Client's machine icon is not green, then the Client process
is not connected and most actions (those requiring communication with the Client)
will be disabled. Back to top.
Why don't the Server and Client processes install as services on Windows?
Processes running as Windows services are subject to certain restrictions when trying
to access network resources. These restrictions can cause your batch to fail unexpectedly
and are not easy to debug. While it is possible to work around these restrictions,
it is not simple and requires detailed technical knowledge of Windows services and
authentication in order to configure properly. If you would like to install the Server
and/or Client as a service, you can start by looking at Microsoft’s srvany.exe tool.
Back to top.