schedulix server not able to start

[dilipt...@gmail.com]

Hi Roland,

 we check the required class is indeed contained and it shows like this :

-------------------------------------------------------------------------------------------------------

[schedulix@russia ~]$  cd $BICSUITEHOME/lib/

[schedulix@russia lib]$ jar tvf BICsuite.jar | grep BICServer

  3864 Tue Jun 12 05:18:14 CST 2018 de/independit/scheduler/BICServer.class

[schedulix@russia lib]$

we checked the $BICSUITECONFIG/java.conf the CLASSPATH and it shows like this,please find it below

----------------------------------------------------------------------------------------------------------------------------------------------

[schedulix@russia etc]$ cat java.conf

#

# Java and Java Flags for BICsuite server, jobserver and utilities

#

# Some installation dependent jarfiles

# If the examples aren't run, the SWTJAR file can be removed

# The JNAJAR file is needed for jobservers

# The JDBCJAR file is needed for the scheduling server and can be removed for client installations

#

JNAJAR=/path/to/jna.jar

SWTJAR=/path/to/swt.jar

JDBCJAR=/path/to/jdbc/jarfile

#

# Bicsuite JAR to use

#

BICSUITEJAR=$BICSUITEHOME/lib/BICsuite.jar

#

# CLASSPATH to use containing the path to jdbc driver and others if needed

#

BICSUITECLASSPATH==$BICSUITEJAR:$JDBCJAR:$JNAJAR:$SWTJAR:/usr/share/java/mysql-connector-java-5.1.14.jar

#

BICSUITEJAVA=`which java`

# java used for BICsuite Server

BICSUITEJAVA_BS=$BICSUITEJAVA

# java used for BICsuite Jobserver

BICSUITEJAVA_JS=$BICSUITEJAVA

# java used for BICsuite Tools

BICSUITEJAVA_TL=$BICSUITEJAVA

# java used for BICsuite Proxy

BICSUITEJAVA_PX=$BICSUITEJAVA

#

# Additional Java Flags to use

#

# java flags used for BICsuite Server

#

BICSUITEMEM=300

#

MAXMEM=${BICSUITEMEM}m

STARTMEM=`expr $BICSUITEMEM / 2`m

NEWSIZE=`expr $BICSUITEMEM / 16`m

MEMSIZES="-Xmx${MAXMEM} -Xms${STARTMEM} -XX:NewSize=${NEWSIZE}"

MEMFLAGS="-XX:+UseConcMarkSweepGC -XX:+CMSParallelRemarkEnabled -XX:CMSInitiatingOccupancyFraction=80 -XX:+DisableExplicitGC -XX:ParallelGCThreads=4"

MEMDEBUG=""

MEMCONF="$MEMSIZES $MEMFLAGS $MEMDEBUG"

#

BICSUITEJAVAFLAGS_BS="$MEMCONF"

# java flags used for BICsuite Jobserver

BICSUITEJAVAFLAGS_JS="-client -XX:ParallelGCThreads=2"

# java flags used for BICsuite Tools

# used to be "-client", but OpenJDK doesn't understand that

BICSUITEJAVAFLAGS_TL=""

# java flags used for BICsuite Proxy

BICSUITEJAVAFLAGS_PX=""

Thanks

Dilip

[Ronald Jeninga]

Hi Dilip,

well, at least your JDBCJAR in the java.conf file should point to a valid jdbc driver.

And it won't harm if the JNAJAR points to something valid as well. THE SWTJAR isn't that important if you don't want to use the examples.

After fixing those two issues above (which are not the cause for your problem (yet)), you can try to start the server by hand:

java -cp $BICSUITEHOME/lib/BICsuite.jar:/the/path/to/your/jdbc/jarfile de.independit.scheduler.BICServer $BICSUITECONFIG/server.conf

and look what happens. (Don't forget to specify a valid jdbc jarfile!)

Depending on the outcome, we'll continue our search.

You can stop the server by hitting ctrl-c, or by sdmsh ("stop server;") or by the GUI.

Best regards,

Ronald

[dilipt...@gmail.com]

Hi

we are starting the schedulix server, we are getting below error. Can you help us on this,

 

 [schedulix@russia scheduler]$ server-start

Error: Could not find or load main class de.independit.scheduler.BICServer

[scrolllog] Waiting for child (27134) to terminate

[scrolllog] Child exited with state 1

[scrolllog] Try to restart child (child terminated with exit code <> 0)

 i checked the path as well,

/home/schedulix/schedulix/src/de/independit/scheduler [schedulix@russia ~]$ cd /home/schedulix/schedulix/src/de/independit/scheduler

 

 

[schedulix@russia scheduler]$ ll

total 0

lrwxrwxrwx. 1 schedulix schedulix 49 Jun 12 05:18 BICServer.class -> /home/schedulix/schedulix-2.7/src/BICServer.class

lrwxrwxrwx. 1 schedulix schedulix 48 Jun  6 03:40 BICServer.java -> /home/schedulix/schedulix-2.7/src/BICServer.java

lrwxrwxrwx. 1 schedulix schedulix 38 Jun  6 03:40 demo -> /home/schedulix/schedulix-2.7/src/demo

lrwxrwxrwx. 1 schedulix schedulix 43 Jun  6 03:40 jobserver -> /home/schedulix/schedulix-2.7/src/jobserver

lrwxrwxrwx. 1 schedulix schedulix 42 Jun  6 03:40 Makefile -> /home/schedulix/schedulix-2.7/src/Makefile

lrwxrwxrwx. 1 schedulix schedulix 54 Jun  6 03:40 Makefile.CommonRules -> /home/schedulix/schedulix-2.7/src/Makefile.CommonRules

lrwxrwxrwx. 1 schedulix schedulix 37 Jun  6 03:40 md5 -> /home/schedulix/schedulix-2.7/src/md5

lrwxrwxrwx. 1 schedulix schedulix 41 Jun  6 03:40 SDMSApp -> /home/schedulix/schedulix-2.7/src/SDMSApp

lrwxrwxrwx. 1 schedulix schedulix 45 Jun 12 05:18 sdmsh.class -> /home/schedulix/schedulix-2.7/src/sdmsh.class

lrwxrwxrwx. 1 schedulix schedulix 44 Jun  6 03:40 sdmsh.java -> /home/schedulix/schedulix-2.7/src/sdmsh.java

lrwxrwxrwx. 1 schedulix schedulix 40 Jun  6 03:40 server -> /home/schedulix/schedulix-2.7/src/server

lrwxrwxrwx. 1 schedulix schedulix 39 Jun  6 03:40 shell -> /home/schedulix/schedulix-2.7/src/shell

lrwxrwxrwx. 1 schedulix schedulix 39 Jun  6 03:40 tools -> /home/schedulix/schedulix-2.7/src/tools

lrwxrwxrwx. 1 schedulix schedulix 41 Jun  6 03:40 utility -> /home/schedulix/schedulix-2.7/src/utility

[schedulix@russia scheduler]$

 

[Ronald Jeninga]

Hi Dilip,

did you read my previous message and test what I proposed?

What happened?

Best regards,

Ronald

[alexand...@gmail.com]

Hi Ronald,

I'm not sure exactly what happened with my installation. I haven't really changed anything. But whenever I try to start the schedulix-client or schedulix-server services and check for their status, I'm getting an error saying no server installation found. I can launch the zope web server but when I try to access the existing jobs, it just keeps on loading.

Attached are the server logs.

I followed your suggestion and got the following:

Error: could not find or load main class de.indpenendit.scheduler.BICServer

It was working  a day ago. So I really can't tell what went wrong.

Thanks,

Xander

[Ronald Jeninga]

Hi Xander,

the last entry in the server's log file is from today 6AM GMT.

That's not too long ago, about an hour or so. Apparently something happened within the last hour.

Never mind, let's just try to find out what happened.

If you installed from the rpms, the software tree is located in /opt/schedulix

Please check if that's still there.

If you installed the system manually (somewhere else), please check the location you chose.

The environment variable BICSUITEHOME should point to /opt/schedulix/schedulix

(or to the location you chose in your manual installation).

The jar file should be $BICSUITEHOME/lib/BICsuite.jar

The file is somewhat larger than 2MB (IIRC).

You can test if the class is included with "jar tvf $BICSUITEHOME/lib/BICsuite.jar | grep BICServer":

-bash-4.2$ jar tvf $BICSUITEHOME/lib/BICsuite.jar | grep BICServer

  3864 Fri Mar 15 12:28:34 CET 2019 de/independit/scheduler/BICServer.class

I have to go now, but will be back in about an hour.

Please do the checks I suggested in the meantime.

Best regards,

Ronald

[Ronald Jeninga]

Hi Xander,

while comparing the time you've sent your question and the times from the server log, it seems that your server is running smoothly.

What do you see if you do a "ps -fu schedulix" ?

Alternatively an "lsof -i -P | grep schedulix" also shows interesting information.

I don't see any accesses from the Zope server in the log file.

And you wrote that Zope seems to wait indefinitely.

If the server wouldn't run, Zope wouldn't be able to connect too, but it would return almost immediately and report a ConnectError.

My guess is that there might be a firewall issue.

Can you do a "telnet localhost 2506" ? (After verifying that the server is indeed running using the ps or lsof commands).

Like in

-bash-4.2$ telnet localhost 2506

Trying ::1...

Connected to localhost.

Escape character is '^]'.

connect system identified by 'G0H0ME';

Connect

CONNECT_TIME : 21 Mar 2019 12:42:23 GMT

Connected

SDMS> quit

Disconnected

SDMS> Connection closed by foreign host.

Maybe you did some "unreally" changes? You wrote that you didn't really change anything. But sometimes details matter.

(At least with computers; in my experience they only do what I say, not what I intend to say ;-).

Best regards,

Ronald

[alexand...@gmail.com]

Hi Ronald,

I did "ps -fu schedulix". And I got these:

UID        PID  PPID  C STIME TTY          TIME CMD

schedul+  1420     1  0 06:39 ?        00:00:00 /opt/schedulix/schedulix/bin/scrolllog /opt/schedulix/log/localhost.out -e /bin/java -XX:ParallelGCThreads=2 -cp /opt/sc

schedul+  1440  1420  0 06:39 ?        00:00:01 /bin/java -XX:ParallelGCThreads=2 -cp /opt/schedulix/schedulix/lib/BICsuite.jar:/usr/share/java/mysql-connector-java-5.1

schedul+  1455     1  0 06:39 ?        00:00:00 /opt/schedulix/schedulix/bin/scrolllog /opt/schedulix/log/host_1.out -e /bin/java -XX:ParallelGCThreads=2 -cp /opt/sched

schedul+  1456  1455  0 06:39 ?        00:00:01 /bin/java -XX:ParallelGCThreads=2 -cp /opt/schedulix/schedulix/lib/BICsuite.jar:/usr/share/java/mysql-connector-java-5.1

schedul+  1468     1  0 06:39 ?        00:00:00 /opt/schedulix/schedulix/bin/scrolllog /opt/schedulix/log/host_2.out -e /bin/java -XX:ParallelGCThreads=2 -cp /opt/sched

schedul+  1469  1468  0 06:39 ?        00:00:01 /bin/java -XX:ParallelGCThreads=2 -cp /opt/schedulix/schedulix/lib/BICsuite.jar:/usr/share/java/mysql-connector-java-5.1

schedul+  1544     1  0 06:39 ?        00:00:00 /opt/schedulix/schedulix/bin/scrolllog /opt/schedulix/log/BICserver.out -o /opt/schedulix/log/BICserver.pid -e /bin/java

schedul+  2206     1  0 06:42 ?        00:00:00 /bin/sh /opt/schedulix/schedulix/bin/server-start

schedul+  2207  2206  0 06:42 ?        00:00:00 /bin/sh /opt/schedulix/schedulix/bin/sdmsctl start

schedul+  2305  1544  0 06:42 ?        00:00:03 /bin/java -Xmx300m -Xms150m -XX:NewSize=18m -XX:+UseConcMarkSweepGC -XX:+CMSParallelRemarkEnabled -XX:CMSInitiatingOccup

schedul+  2459     1  0 06:42 ?        00:00:00 scrolllog /opt/schedulix/log/zope.out -e /opt/schedulix/schedulixweb/bin/runzope

schedul+  2460  2459  0 06:42 ?        00:00:01 /opt/schedulix/software/Zope/bin/python /opt/schedulix/software/Zope/bin/runzope -C /opt/schedulix/schedulixweb/etc/zope

schedul+  6792  2207  0 06:54 ?        00:00:00 sleep 1

and did a "telnet localhost 2506" and got the following:

Trying ::1...

Connected to localhost.

Escape character is '^]'.

Prior to this, I was having trouble getting the logs to show from the application gui, and so I followed this: 

https://groups.google.com/forum/#!topic/schedulix/3gcYHVxrxtk. Then I was able to access the logs fine. Everything is working okay too.

Other than that, the only change I did was changing my proxy address. But that might not probably it because I just switched it back to what it was before, and I'm still having the same problem.

I'm attaching my most recent log files and a screenshot of the commands I used to start the schedulix services and the responses I got when I tried to check their statuses.

Regards,

Xander

[alexand...@gmail.com]

Hi Ronald,

I tried the other checks you suggested above. I ran the command below:

jar tvf $BICSUITEHOME/lib/BICsuite.jar | grep BICServer

and I'm getting the following file not found error.

java.io.FileNotFoundException: /lib/BICsuite.jar (No such file or directory)

        at java.util.zip.ZipFile.open(Native Method)

        at java.util.zip.ZipFile.<init>(ZipFile.java:219)

        at java.util.zip.ZipFile.<init>(ZipFile.java:149)

        at java.util.zip.ZipFile.<init>(ZipFile.java:120)

        at sun.tools.jar.Main.list(Main.java:1115)

        at sun.tools.jar.Main.run(Main.java:293)

        at sun.tools.jar.Main.main(Main.java:1288)

 $BICSUITEHOME doesn't seem to persist in my system environment although it's been set in schedulix SETTINGS file attached.

 

It finds the BICServer class when I execute an export command for the  $BICSUITEHOME before running the "jar tvf..." command above.

Regards,

Xander

[Ronald Jeninga]

Hi Xander,

well, the ps output shows that you have the example jobservers running.

Those jobservers are started with the schedulix-examples service, not the schedulix-client service.

You also have a scheduling server running (pid 2305), but for some reason the sdmsctl script didn't finish.

I know this can happen, but it rarely ever does.

You can kill the sdmsctl script (pid 2207). This will also terminate the server-start script (that's actually only a wrapper).

Small question: do you have the utility "fuser" installed?

The "service schedulix-server status" does nothing more than testing if someone is using the named pipe /opt/schedulix/log/BICserver.out

If someone does, it thinks that the server is running.

And if no-one is trying to make trouble, it is actually a pretty good indication.

But if the utility isn't installed, the init.d script will interpret this as an error and report that the server is down.

Obviously you don't have any other jobservers installed, which is why "service schedulix-client status" reports it doesn't find any.

From what I see in the server log file, you are more or less in panic.

There's actually no reason for that at all.

As I already told you this morning, your server seems to run smoothly.

I can't tell if this is still the case after you've tried to start it several times, maybe after stopping it, maybe a few times in a row.

Your server starts. This is proven by the server log file, the jobserver log file, the fact that telnet can connect and by the ps output.

In short: your server is not the problem.

Now it is possible, for whatever reason, that the Zope server can't connect, but doesn't receive a response from the network layer (other than a TCP timeout, which can last several minutes).

If this is the case, something I derive from your previous message, we'll have to look at that.

To Do:

1. Please check if fuser is installed. If not, please install it

2. Have a look again at the ps output.

    You should find several pairs of processes: a scrolllog and a java, or a scrolllog and a python (Zope).

    In fact, it should be 5 pairs: scheduling server, 3 example jobservers and a Zope

    If the ps output doesn't match the description, please tell me.

    If you find server-start and/or sdmsctl scripts still running, kill them

After having done resp. checked this, your system is running smoothly (from the server point of view).

Hence

3. Can you access the GUI and does it work?

Best regards,

Ronald

[Ronald Jeninga]

Hi Xander,

if you work as user root it is very common to have a limited environment only.

The user root in a unix/linux system has all the privileges one can dream of (and this is a cause for nightmares).

This is why you don't want a long PATH, you don't set any application related variables, and so on.

The root user is for operating system maintenance.

To administrate a schedulix installation, you use the user that owns the installation, in this case schedulix.

The schedulix user will have its environment variables set up properly.

Of course, if you insist, you can set those environment variables for the root user as well.

But that's something YOU will have to do, because YOU are the system administrator.

I am just a developer of a scheduling system and cannot take such decisions for you or any other of our users.

This explains why the SETTINGS file isn't sourced from root's .bashrc or from /etc/profile or other files alike.

(at least not automatically by installing some rpms; IMHO this is a matter of ethics)

And since I already found out that your server is doing fine, I'm not surprised you've found the class file within the jar.

Best regards,

Ronald

[alexand...@gmail.com]

Hi Ronald,

Thanks for your response. It's a relief to know that nothing seems to be wrong with my installation. Except I guess with it having installed as a "root" user maybe. I hope it's not. I know I followed the rpm installation guide as it is. And I have a schedulix user created as well. Thanks for pointing that out. I need to be more cautious with that. I was not really particular about it as long as I can find my way around the system. But will have to keep it in mind from now on.

I don't have the fuser utility installed. I installed it as advised.

I did a "ps -fu schedulix" command again and I have exactly five pairs as you mentioned (scheduling server, 3 jobservers and zope) and without the sdmsctl and server-start.

They're all set to work fine then. But I tried accessing the GUI. I can access it. But when I try to select a folder or a jobserver in navigation panes of either the jobservers or jobs window, I just get a loading screen and then times out later saying "the connection was reset". I've attached the screenshot.

Also, whenever I start the server before, it automatically runs the zope server. So I needed to set it to not start automatically. Now I am manually starting them. But the example jobservers get started automatically I guess, and that's fine. I can leave them as is.

Does that mean I only have the zope and the schedulix-server services started manually?

And am I suppose to start all schedulix services using the schedulix user? Because I tried switching to schedulix user to do that, but it was asking for a password, and I'm not sure if I created a password for the schedulix user, and now it's just saying permission denied.

Thanks as always,

Xander

[Ronald Jeninga]

Hi Xander,

no worries, you've installed the rpms (which has to be done as root). The schedulix user is created in the process and the /opt/schedulix tree is owned by schedulix.

Installing systems like schedulix or mariadb and loads of other software requires support from the root user. This is in fact hidden by the rpm mechanism.

When starting up and halting the system (I mean the "iron" here), a lot of services owned by several technical users have to be started or shut down as well.

This is handled either within the init.d or comparable scripts, or sometimes from within the application itself (e.g. Apache needs to be started as root in order to be able to open port 80, but it'll set the uid just after that).

In case of schedulix, the init.d script does a "su - schedulix -c 'do something'" as a general pattern (have a look at them; they are pretty straightforward), which is why you have to enter the schedulix password if you aren't root.

In case of the schedulix-client service things are slightly different.

Many users can setup a jobserver for themselves. This is done by calling the setup_jobserver script (you can have a look at that too, but that's less straightforward).

By evaluating the directory structure below /opt/schedulix/taskfiles the init.d script knows for which user some jobserver has to be started.

Hence the script will do several "su - $JSOWNER -c '...'" (as a pattern; look at the script for details), which will only be successful if the init.d script is executed as root.

As user schedulix you can start the scheduling server with "server-start" and stop it with "server-stop".

The Zope server can be shut down from the Zope Management form. It can be started by manually executing the command line you'll find in the /etc/init.d/schedulix-zope script.

Basically it calls "runzope" using "scrolllog" as a wrapper.

A jobserver can be stopped by the user that runs it. And that very user can also start it, using the jobserver-run script.

Hence the init.d scripts are intended to automate the startup and the shut down of the components of the schedulix system.

As root user you can always set the password on behalf of the user schedulix.

After installing the rpms, the user schedulix will have the maximally insecure password schedulix.

It is more than recommended to change the password. It is also recommended to change the password of the schedulix internal user SYSTEM.

The standard password (G0H0ME) is nice for bootstrapping, but it is a well known password.

Within the schedulix system, the user SYSTEM plays a comparable role as the root user at operating system level.

What is left now is the Zope issue.

I'll write another answer on that today, mainly in order to separate the topics.

Best regards,

Ronald   

[alexand...@gmail.com]

Hi Ronald,

Thanks for that. I tried switching to schedulix user and keyed-in "server-start" but it just gets stuck and doesn't continue. And when I'm doing ps -fu schedulix I'm getting this:

UID        PID  PPID  C STIME TTY          TIME CMD

schedul+  2166     1  0 12:48 ?        00:00:00 /opt/schedulix/schedulix/bin/scrolllog /opt/schedulix/log/BICserver.out -o /opt/schedulix/log/BICserver.pid -e /bin/java

schedul+  2252     1  0 12:49 ?        00:00:00 /bin/sh /opt/schedulix/schedulix/bin/sdmsctl start

schedul+  6266     1  0 12:59 ?        00:00:00 /opt/schedulix/schedulix/bin/scrolllog /opt/schedulix/log/localhost.out -e /bin/java -XX:ParallelGCThreads=2 -cp /opt/sc

schedul+  6267  6266  0 12:59 ?        00:00:01 /bin/java -XX:ParallelGCThreads=2 -cp /opt/schedulix/schedulix/lib/BICsuite.jar:/usr/share/java/mysql-connector-java.jar

schedul+  6279     1  0 12:59 ?        00:00:00 /opt/schedulix/schedulix/bin/scrolllog /opt/schedulix/log/host_1.out -e /bin/java -XX:ParallelGCThreads=2 -cp /opt/sched

schedul+  6281  6279  0 12:59 ?        00:00:01 /bin/java -XX:ParallelGCThreads=2 -cp /opt/schedulix/schedulix/lib/BICsuite.jar:/usr/share/java/mysql-connector-java.jar

schedul+  6292     1  0 12:59 ?        00:00:00 /opt/schedulix/schedulix/bin/scrolllog /opt/schedulix/log/host_2.out -e /bin/java -XX:ParallelGCThreads=2 -cp /opt/sched

schedul+  6293  6292  0 12:59 ?        00:00:01 /bin/java -XX:ParallelGCThreads=2 -cp /opt/schedulix/schedulix/lib/BICsuite.jar:/usr/share/java/mysql-connector-java.jar

schedul+  7371     1  0 13:02 ?        00:00:00 scrolllog /opt/schedulix/log/zope.out -e /opt/schedulix/schedulixweb/bin/runzope

schedul+  7372  7371  0 13:02 ?        00:00:01 /opt/schedulix/software/Zope/bin/python /opt/schedulix/software/Zope/bin/runzope -C /opt/schedulix/schedulixweb/etc/zope

schedul+  9178     1  0 13:07 ?        00:00:00 /bin/sh /opt/schedulix/schedulix/bin/sdmsctl start

schedul+  9317  2166  0 13:07 ?        00:00:02 /bin/java -Xmx300m -Xms150m -XX:NewSize=18m -XX:+UseConcMarkSweepGC -XX:+CMSParallelRemarkEnabled -XX:CMSInitiatingOccup

schedul+ 12725  2252  0 13:12 ?        00:00:00 sleep 1

schedul+ 12730  9178  0 13:12 ?        00:00:00 sleep 1

And the problem with the GUI loading indefinitely when selecting a server or a job object on the navigation pane, is still persistent and I'm not sure if it's the server too because there are times when I try to open a file from the server using winscp, it gets disconnected.

Regards,

Xander

[Ronald Jeninga]

Hi Xander,

you just proved you can't start a second instance of a server that uses the same database schema as the first instance.

And depending on your configuration it is even possible that your installation became absolutely unresponsive.

All of this is intended behaviour.

If two servers would write into the same schema, they wouldn't be aware of each other's changes.

This would lead to inconsistencies in no-time.

We took precautions that this doesn't happen. The server that was started later tries to start up, but fails. It terminates and scrolllog will start the server again.

As long as the first server is healthy this will continue indefinitely. As soon as the first server terminates, the second one will take over.

This is a kind of warm standby.

If you want to set up a warm standby like this, you might want to have a main and a standby physical server server.

If the main server fails, the standby server will take over. But as soon as the cause for failure of the first server has been eliminated, you might want to switch back to normal operation.

(maybe simply because the standby server is less powerful).

In this case you set the SingleServer property of the first server to true.

If the first server is started after repair, it will take over automatically again and the second server will fall back into its standby role.

If you are creative enough to set this SingleServer property to true for both servers, you'll end up with a situation that both servers will play ping pong.

Each of them displaces the other one over and over again. The effect is that nothing works.

To get out of your situation, kill both servers (piid 9317, 2166, 6293 and 6292) and start a (single) new one.

The pids might change though (especially the one of the second server).

If the sdmsctl script doesn't die, kill that one as well.

I didn't have time to think about the GUI problem yet.

It will take some investigations in order to find out where the cause lies.

But it will be a great help if you don't play around with the scheduling server.

You already proved that connecting to the scheduling server is possible (the telnet test). So just leave the scheduling server in place and don't touch it.

If the light of your car don't work, it won't help you finding the cause if you keep starting and stopping the engine.

I will help you finding the cause of the GUI problem. But it will require some tests and some thinking.

You'll have to have a little patience. My desk isn't exactly empty.

Best regards,

Ronald

[Ronald Jeninga]

Hi Xander,

you still face the problem that the GUI doesn't seem to work properly.

We have checked the scheduling server and from the server log and the telnet test we've seen that the server runs and it is possible to connect to the server.

What happens:

1. If you access the GUI, your browser sends an http request to the Zope server.

2. The Zope server processes the request and issues a query to the scheduling server on your behalf.

3. The scheduling server processes this query and sends the result to the Zope server.

4. The Zope server interprets the reply from the scheduling server, builds an html page and sends this to your browser.

You'll see an hourglass all the time between step 1 and 4. If the response takes too long, you possibly get an error message.

From your ps output I can see that the Zope server runs on the same machine as the scheduling server.

On the other hand, your screen shots make it likely that the Zope server is able to respond to your browser requests.

The first thing we'll do is to check the configuration of the GUI.

Obviously the Zope server must know where to send the queries (we call them SDMS commands).

If you open the URL for the GUI in your web browser, the URL will look like http://some.host.name:8080/SDMS

Now if you take this URL and write manage instead of SDMS, Zope will offer you its management interface.

You'll see a list of folders and other objects.

From this list you click on the folder Custom

Zope will open the folder and present its contents.

Here you'll find a Python script called SDMSServers

If you click on this name, Zope will show you the contents of the script.

It is a very simple script that does nothing more than returning a data structure that describes where to find your scheduling server.

It could for instance look like

return { 

 'DEFAULT' : { 

  'HOST'    : 'localhost', 

  'PORT'    : '2506',

  'VERSION' : 'BASIC',

  'CACHE'   : 'Y',

  'TIMEOUT' : '60',

  'SSL'     : 'N',

  # 

  # Edit following Options if SLL set to 'Y'

  #

  # 'TRUSTSTORE' : 'truststore.pem',

  # 'KEYSTORE'   : 'keystore.pem'

 },

}

From this we now know that (with the above data structure) Zope expects to find a scheduling server at localhost that listens on port 2506.

(that's pretty much the default).

If you got this far in the first place, we can infer that your browser can communicate with the Zope server, and we know something about Zope's expectations.

If you didn't get that far, you'll have to check why your browser can't communicate with the Zope server (buy a bottle of wine for your network administrator).

If the host entry doesn't show localhost but some other hostname, you might have an issue with either dns, or, more likely, with a firewall.

Since your Zope runs on the same machine, localhost should work. Hence if there's some other name in there, please change it to localhost.

Another possibility is some confusion regarding ipv4 and ipv6. It should both work, but I have seen problems with that (but I don't recall the exact cause).

If in doubt, you can change localhost into 127.0.0.1, and test again. (Don't forget to save your changes!).

And please restart your browser, or at least close all windows/tabs that are GUI related, between two tests.

In our modern times browsers are now called intelligent.

This doesn't mean they do a better job, it only means that you need more intelligence to resolve problems.

If this all doesn't resolve any problems, please tell me and I'll do some more thinking.

But if it works sometimes (i.e. sometime you get a valid answer, sometime an hourglass) you seem to run into some transient error which is probably network related.

(Buy two bottles of wine for your network administrator).

Best regards,

Ronald

[alexand...@gmail.com]

Hi Ronald,

I can't seem to pinpoint yet what exactly is making the GUI behave as such. It isn't the proxy because I've changed it and even removed it. But we just figured that it's not the schedulix application either because we tried accessing it from another work station and it works as expected. Will have to look into it further. One thing is for sure, it's my work station causing this issue. Whew!

Thanks as always for taking time answering my questions. I actually have some more but I'll just post it soon in another topic. I already checked out the groups if it's existing, and it is, but probably for an older version. Anyways, thanks again Ronald. I appreciate you always.

Regards,

Xander