FAQ

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 rules:

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 future date.

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 long answer...

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 screen view.

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 command?

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 top.

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 popup menu?)

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.

Home

Job2Do

About Sypsoft

Architecture

Feature Set

FAQ

Resources

Forums

Download