Hi, Baan seems to be up and running, but someone noticed that the shmtimer process is no longer there! We would expect to see something like...

root 15421 1 0 Sep 25 ? 75:39 /apps0/baan/bse/bin/shmtimer6.1 -i

but ps -ef|grep shm shows nothing! What are the effects of this? Can I restart just this timer without affecting users?

Cheers - Andy

You can run without timer, you can also restart the timer:

$ shmtimer6.2 -i
Shmtimer started: pid = 397548, time = 1161773718 (Wed Oct 25 10:55:18 2006)
$ shmtimer6.1 -?
Usage: shmtimer6.1 [-iksvu]
-i : start timer
-k : stop timer
-s : show timer status
-v : show version
-u : show this text
$ shmtimer6.1 -s
Shmtimer info: pid = 397548, time = 1161773739 (Wed Oct 25 10:55:39 2006)

The timer takes care that all users read the time from shared memory instead of doing a more expensive systemcall. So, if the timer is not there, it will do the system call. Beside that you have a performance penalty, there should not be any issues.

Kind regards,
Dick

thanks for the quick response, I ran shmtimer6.1 -i and it has started the daemon. However, it also gave the following error

$ shmtimer6.1 -i
shmtimer6.1: get_sem failed - error 22 (Invalid argument)
shmtimer6.1: rel_sem 44820 failed - error 22 (Invalid argument)
Shmtimer started: pid = 20798, time = 1161774597 (Wed Oct 25 12:09:57 2006)[/

shmtimer6.1 -s also gives the error above

process is running though...
ps -ef|grep shm
root 20798 1 0 12:09:57 ? 0:00 shmtimer6.1 -i

Is it working? Is there a lock file $BSE/tmp perhaps that's why it can't 'rel_sem'? Can I restart the process again without kicking people out of Baan?

Thanks - Andy

Have you started the shmtimer as the same users as you started your shared memery (normally the user that runs rc.start). If not that can explain the problem.

Baan started with rc.start - shmtimer I assume should have started at the same time but hadn't. rc.start runs as root, shmtimer started manually as root today. Any ideas?

Hi Andy,

depending on your platform (Hp-Ux, Aix, ...) you maight have a problem with the kernel settings. It looks like the shmtimer can not acquire the semaphore it needs. This could be due to a kernel limit.

...
The timer takes care that all users read the time from shared memory instead of doing a more expensive systemcall. So, if the timer is not there, it will do the system call. Beside that you have a performance penalty, there should not be any issues.
...


Dick,
ba6.1 seems to run jobs ok when shmtimer6.1 is down. However using ba6.1 as user interface is not possible when shmtimer is down. Is that simply because ba6.1 is not coded to use the system call instead unless BAMODE is 1 or something like that?

Thanks,

Eduardo