Hi John,
If I remember correctly when I was using Job Scheduler, if you are using a clustered configuration, you need the cluster licence. The free version only provides a single controller not clustered.
Regards
Brian
Name Brian Johnson – Planned Leave NONE.
Cloud Engineer
UK - Digital, Data and Cloud
Unless otherwise stated, this email has been sent from Fujitsu Services Limited (registered in England No 96056); Fujitsu EMEA PLC (registered in England No 2216100) both with registered offices at: Lovelace Road, Bracknell, Berkshire RG12 8SN; PFU (EMEA) Limited, (registered in England No 1578652) registered offices at: Belmont, Belmont Road, Uxbridge, England, UB8 1HE and Fujitsu Research of Europe Ltd (registered in England No. 4153469) 4th Floor, Building 3, Hyde Park Hayes, 11 Millington Road, Hayes, UB3 4AZ.
This email is only for the use of its intended recipient. Its contents are subject to a duty of confidence and may be privileged. Fujitsu does not guarantee that this email has not been intercepted and amended or that it is virus-free.
Brian's hint is correct. However, I cannot identify a line of log output in your watchdog.log file that indicates a license check. It looks to me that you are operating a standalone Controller.
Prominent root causes you can address from the following actions:
In the /var/sos-berlin.com/js7/controller directory, can you identify any Java Fatal Error Logs, available from hs_err<PID>.log files?
Delete the /var/sos-berlin.com/js7/controller/state directory and restart the Controller.
If the problem persists, enable debug log level from the ./config/log4j2.xml file, Find instructions how to enable debug log level from the JS7 - Log Levels and Debug Options article.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
js7@john_linux_machine:~$sudosystemctlstatuscontroller.service×controller.service-SOSJS7Controller-id=ubuntu_controllerLoaded:loaded(/usr/lib/systemd/system/controller.service;enabled;preset:enabled)Active:failed(Result:exit-code)sinceMon2025-10-2710:08:31CET;1min58sagoDuration:4.313sProcess:35072ExecStart=/opt/sos-berlin.com/js7/controller/bin/controller_instance.shstart(code=exited,status=0/SUCCESS)Process:35132ExecStartPost=/bin/sleep1(code=exited,status=0/SUCCESS)Process:35177ExecStop=/opt/sos-berlin.com/js7/controller/bin/controller_instance.shstop(code=exited,status=3)MainPID:35133CPU:13.940sOkt2710:08:25john_linux_machinesystemd[1]:Startingcontroller.service-SOSJS7Controller-id=ubuntu_controller...Okt2710:08:26john_linux_machinesystemd[1]:controller.service:Supervisingprocess35133whichisnotourchild.We'll most likely not notice when it exits.Okt2710:08:26john_linux_machinesystemd[1]:Startedcontroller.service-SOSJS7Controller-id=ubuntu_controller.Okt2710:08:31john_linux_machinecontroller_instance.sh[35177]:...notstarted!Okt2710:08:31john_linux_machinecontroller_instance.sh[35177]:...couldnotterminatetheJS7Controller(ubuntu_controller)withpid=!Okt2710:08:31john_linux_machinesystemd[1]:controller.service:Controlprocessexited,code=exited,status=3/NOTIMPLEMENTEDOkt2710:08:31john_linux_machinesystemd[1]:controller.service:Killingprocess35133(n/a)withsignalSIGKILL.Okt2710:08:31john_linux_machinesystemd[1]:controller.service:Killingprocess35133(n/a)withsignalSIGKILL.Okt2710:08:31john_linux_machinesystemd[1]:controller.service:Failedwithresult'exit-code'.Okt2710:08:31john_linux_machinesystemd[1]:controller.service:Consumed13.940sCPUtime,163.2Mmemorypeak,0Bmemoryswappeak.jobscheduler@john_linux_machine:~$
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This translates to the fact that systemd is killing the Controller after successful start. Prominent reasons includes that systemd does not find the Controller's pid file that on your machine might take more time to be created.
Modify the controller.service file. You will find it in one of /etc/systemd/system or /usr/lib/systemd/system directories.
Change the following entry from "sleep 1" to "sleep 3"
ExecStartPost=/bin/sleep 3
Then execute sudo systemctl daemon-reload
and start the Controller from sudo systemctl start controller.service.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The 'private.conf' file could not be found in the 'config' folder. I copied the example file from the private folder there. However, the controller still does not start. Having reviewed the debug log, I suspect that the file belongs in the config/private directory. I moved it there:
Sorry for indicating the wrong location. However, it's great that you found it.
The issue boils down to the fact that the js7_install_controller.sh script should take care of providing the ./config/private/private.conf file which is required. This seems not to apply to all situations.
Can you please forward the log output that you received when installing the Controller from the script? Should be located in /tmp/js7 as indicated by your initial post.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In my opinion, the tar.gz file is missing a working default 'private.conf' file. I also think that this line should be output to the 'controller.log' file.
A file essential for the operation of js7 controller is missing here. Users should be able to access this information immediately without having to go through the debug log.
thank you, this is helpful. In fact things are little bit more complex: we do not ship the ./config/private/private.conf file from the tarball as we know that users tend to simply extract the tarball to an existing installation directory and would inadvertedly overwrite existing configuration.
This is why the installation script takes care of this - which it usually does, however, not in your situation. You are certainly right about missing log output at error level should the private.conf file not be available.
We will take care of this.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello
I am trying to install the JS7 controller on Linux. To do this, I downloaded the latest version 2.8.1 and installed it using this script.
The controller starts briefly and then shuts down again immediately.
This is the conf file
I was able to install agent and agent is running.
What could be the reason for this?
Hi John,
no immediate error is apparent from use of the script and log output.
Please check the Controller's ./logs/watchdog.log file that includes output written to stdout/stderr.
There is no error in the watchdog.log file.
Hi John,
If I remember correctly when I was using Job Scheduler, if you are using a clustered configuration, you need the cluster licence. The free version only provides a single controller not clustered.
Regards
Brian
Name Brian Johnson – Planned Leave NONE.
Cloud Engineer
UK - Digital, Data and Cloud
[group-logo] [cid:image002.png@01DC4746.32A3A320] [cid:image003.png@01DC4746.32A3A320]
From: discussion@jobscheduler.p.re.sourceforge.net discussion@jobscheduler.p.re.sourceforge.net On Behalf Of John Baltimore
Sent: Monday, October 27, 2025 1:29 PM
To: [jobscheduler:discussion] 486122@discussion.jobscheduler.p.re.sourceforge.net
Subject: [jobscheduler:discussion] Controller shuts down immediately after startup
There is no error in the watchdog.log file.
"/usr/bin/java" -DJS7.Controller="ubuntu_controller" -Xmx500m -Dfile.encoding=UTF-8 -XX:+HeapDumpOnOutOfMemoryError -XX:+ExitOnOutOfMemoryError -classpath "/opt/sos-berlin.com/js7/controller/lib:/var/sos-berlin.com/js7/controller/config/patches/:/var/sos-berlin.com/js7/controller/config/lib/:/opt/sos-berlin.com/js7/controller/lib/patches/:/opt/sos-berlin.com/js7/controller/lib/user_lib/:/opt/sos-berlin.com/js7/controller/lib/sos/:/opt/sos-berlin.com/js7/controller/lib/3rd-party/" js7.controller.ControllerMain --id="ubuntu_controller" --http-port="4444" --config-directory="/var/sos-berlin.com/js7/controller/config" --data-directory="/var/sos-berlin.com/js7/controller"
...JS7 Controller(ubuntu_controller) is starting with pid=30720!
...see log file /var/sos-berlin.com/js7/controller/logs/controller.log
...watchdog for pid 30720 is started
Hit ENTER to return to command prompt.
2025-10-27 08:26:34.467+0100 JS7 Controller 2.8.1
Controller shuts down immediately after startuphttps://sourceforge.net/p/jobscheduler/discussion/486122/thread/603e9a0b51/?limit=25#6f7d
Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/jobscheduler/discussion/486122/
To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/
Unless otherwise stated, this email has been sent from Fujitsu Services Limited (registered in England No 96056); Fujitsu EMEA PLC (registered in England No 2216100) both with registered offices at: Lovelace Road, Bracknell, Berkshire RG12 8SN; PFU (EMEA) Limited, (registered in England No 1578652) registered offices at: Belmont, Belmont Road, Uxbridge, England, UB8 1HE and Fujitsu Research of Europe Ltd (registered in England No. 4153469) 4th Floor, Building 3, Hyde Park Hayes, 11 Millington Road, Hayes, UB3 4AZ.
This email is only for the use of its intended recipient. Its contents are subject to a duty of confidence and may be privileged. Fujitsu does not guarantee that this email has not been intercepted and amended or that it is virus-free.
Hi John,
Brian's hint is correct. However, I cannot identify a line of log output in your watchdog.log file that indicates a license check. It looks to me that you are operating a standalone Controller.
Prominent root causes you can address from the following actions:
If the problem persists, enable debug log level from the ./config/log4j2.xml file, Find instructions how to enable debug log level from the JS7 - Log Levels and Debug Options article.
The controller is installed as a standalone instance. There are no other log files. The folder ../state only contains a lock file.
Ok, next let's check systemd.
sudo systemctl status controller.service?./bin/controller_instance.sh startDoes is work when manually started?
This is the debug log
I have started manually and with systemctl
This translates to the fact that systemd is killing the Controller after successful start. Prominent reasons includes that systemd does not find the Controller's pid file that on your machine might take more time to be created.
Modify the controller.service file. You will find it in one of /etc/systemd/system or /usr/lib/systemd/system directories.
Change the following entry from "sleep 1" to "sleep 3"
ExecStartPost=/bin/sleep 3Then execute
sudo systemctl daemon-reloadand start the Controller from
sudo systemctl start controller.service.same result....
From your response, I didn't find a clear indication what you get in case of manual start of the Controller.
Start the Controller manually using:
./bin/sh -x ./controller_instance.sh startDoes is work when manually started? If no, then please forward the log output created from the above command.
When I start manually, the behavior is the same. The log then looks like this.
Please, perform a few checks:
A debug log should provide more evidence.
<property name="RootLogLevel">INFO</property>and<property name="LogLevelOfDebugLog">OFF</property>to DEBUG in log4j2.xmlFor details see JS7 - Log Levels and Debug Options
Last edit: Andreas 4 days ago
The 'private.conf' file could not be found in the 'config' folder. I copied the example file from the private folder there. However, the controller still does not start. Having reviewed the debug log, I suspect that the file belongs in the config/private directory. I moved it there:
After that, the controller started.
Thank you very much for your support.
Sorry for indicating the wrong location. However, it's great that you found it.
The issue boils down to the fact that the js7_install_controller.sh script should take care of providing the ./config/private/private.conf file which is required. This seems not to apply to all situations.
Can you please forward the log output that you received when installing the Controller from the script? Should be located in /tmp/js7 as indicated by your initial post.
Here is the installation log. Incidentally, I noticed that the installation fails for the same reason when using the method described here:
https://kb.sos-berlin.com/display/JS7/JS7+-+Controller+-+Headless+Installation+on+Linux+and+Windows.
In my opinion, the tar.gz file is missing a working default 'private.conf' file. I also think that this line should be output to the 'controller.log' file.
A file essential for the operation of js7 controller is missing here. Users should be able to access this information immediately without having to go through the debug log.
Hi John,
thank you, this is helpful. In fact things are little bit more complex: we do not ship the ./config/private/private.conf file from the tarball as we know that users tend to simply extract the tarball to an existing installation directory and would inadvertedly overwrite existing configuration.
This is why the installation script takes care of this - which it usually does, however, not in your situation. You are certainly right about missing log output at error level should the private.conf file not be available.
We will take care of this.
Thank you very much. I'm glad that I can now use JS7 on Linux.
The thread can be closed with this summary.
The tar installation file does not contain a private.conf file so that any existing configurations are not overwritten.
The documentation at https://kb.sos-berlin.com/display/JS7/JS7+-+Controller+-+Headless+Installation+on+Linux+and+Windows
will be supplemented with a note that the file private/private.conf must be created manually. A working default sample file is private/private-example.conf.
The log output
will be moved to controller.log.