Update 1.4.17c released

  • It seems like the stops are unrelated to that message in the eventlogs.
    I just had multiple machine stop sending images halfway through a study, without the Client error message, and without anything in the pacstrouble log.


    The last version we had running is 1.4.17 beta3
    If I want to downgrade to that version again, do I copy the whole folder back or would the dgate files be enough?

  • 1.4.17c Restart Script :: Problems


    After installing the startup script, I've never gotten it to work consistently.

    Code
    conquest-pacs.sh



    It will stop dgate, but won't start it back up again consistently. Below, You'll see where it's running. I know this because I'm able to get the process ID. I'm able to stop dgate using the stop command, but then it takes several tries to get it to start. I've tested this several times and i consistently get this same result.

    Code
    root@vlconquest01:/conquest# ps -elf | grep dgate | grep -v grep | awk '{ print $4}'5477root@vlconquest01:/conquest# /etc/init.d/conquest-pacs.sh stopStopping Conquest PACS Serverps -elf | grep dgate | grep -v grep | awk '{ print $4}'root@vlconquest01:/conquest# /etc/init.d/conquest-pacs.sh startStarting Conquest PACS Server: conquest_pacs.sh.root@vlconquest01:/conquest# ps -elf | grep dgate | grep -v grep | awk '{ print $4}'root@vlconquest01:/conquest# ps -elf | grep dgate | grep -v grep | awk '{ print $4}'root@vlconquest01:/conquest# /etc/init.d/conquest-pacs.sh startStarting Conquest PACS Server: conquest_pacs.sh.root@vlconquest01:/conquest# ps -elf | grep dgate | grep -v grep | awk '{ print $4}'root@vlconquest01:/conquest# ps -elf | grep dgate | grep -v grep | awk '{ print $4}'root@vlconquest01:/conquest# /etc/init.d/conquest-pacs.sh startStarting Conquest PACS Server: conquest_pacs.sh.root@vlconquest01:/conquest# ps -elf | grep dgate | grep -v grep | awk '{ print $4}'root@vlconquest01:/conquest# /etc/init.d/conquest-pacs.sh startStarting Conquest PACS Server: conquest_pacs.sh.root@vlconquest01:/conquest# ps -elf | grep dgate | grep -v grep | awk '{ print $4}'root@vlconquest01:/conquest# /etc/init.d/conquest-pacs.sh startStarting Conquest PACS Server: conquest_pacs.sh.root@vlconquest01:/conquest# ps -elf | grep dgate | grep -v grep | awk '{ print $4}'root@vlconquest01:/conquest# /etc/init.d/conquest-pacs.sh startStarting Conquest PACS Server: conquest_pacs.sh.root@vlconquest01:/conquest# ps -elf | grep dgate | grep -v grep | awk '{ print $4}'root@vlconquest01:/conquest# /etc/init.d/conquest-pacs.sh startStarting Conquest PACS Server: conquest_pacs.sh.root@vlconquest01:/conquest# ps -elf | grep dgate | grep -v grep | awk '{ print $4}'root@vlconquest01:/conquest# /etc/init.d/conquest-pacs.sh startStarting Conquest PACS Server: conquest_pacs.sh.root@vlconquest01:/conquest# ps -elf | grep dgate | grep -v grep | awk '{ print $4}'5627


    Here, I tried to run the command manually and got the same result where I'm having to try multiple times before dgate will actually start.

    Code
    root@vlconquest01:/conquest# start-stop-daemon --start --chuid root --chdir /conquest --exec /conquest/dgate --startas /conquest/dgate --background -- -^/conquest/serverstatus.logroot@vlconquest01:/conquest# ps -elf | grep dgate | grep -v grep | awk '{ print $4}'root@vlconquest01:/conquest# start-stop-daemon --start --chuid root --chdir /conquest --exec /conquest/dgate --startas /conquest/dgate --background -- -^/conquest/serverstatus.logroot@vlconquest01:/conquest# ps -elf | grep dgate | grep -v grep | awk '{ print $4}'root@vlconquest01:/conquest# start-stop-daemon --start --chuid root --chdir /conquest --exec /conquest/dgate --startas /conquest/dgate --background -- -^/conquest/serverstatus.logroot@vlconquest01:/conquest# ps -elf | grep dgate | grep -v grep | awk '{ print $4}'root@vlconquest01:/conquest# start-stop-daemon --start --chuid root --chdir /conquest --exec /conquest/dgate --startas /conquest/dgate --background -- -^/conquest/serverstatus.logroot@vlconquest01:/conquest# ps -elf | grep dgate | grep -v grep | awk '{ print $4}'root@vlconquest01:/conquest# start-stop-daemon --start --chuid root --chdir /conquest --exec /conquest/dgate --startas /conquest/dgate --background -- -^/conquest/serverstatus.logroot@vlconquest01:/conquest# ps -elf | grep dgate | grep -v grep | awk '{ print $4}'root@vlconquest01:/conquest# start-stop-daemon --start --chuid root --chdir /conquest --exec /conquest/dgate --startas /conquest/dgate --background -- -^/conquest/serverstatus.logroot@vlconquest01:/conquest# ps -elf | grep dgate | grep -v grep | awk '{ print $4}'root@vlconquest01:/conquest# start-stop-daemon --start --pidfile /var/run/conquest_pacs.sh.5678.pid --chuid root --chdir /conquest --exec /conquest/dgate --startas /conquest/dgate --background -- -^/conquest/serverstatus.logroot@vlconquest01:/conquest# ps -elf | grep dgate | grep -v grep | awk '{ print $4}'root@vlconquest01:/conquest# start-stop-daemon --start --chuid root --chdir /conquest --exec /conquest/dgate --startas /conquest/dgate --background -- -^/conquest/serverstatus.logroot@vlconquest01:/conquest# ps -elf | grep dgate | grep -v grep | awk '{ print $4}'root@vlconquest01:/conquest# start-stop-daemon --start --pidfile /var/run/conquest_pacs.sh.5678.pid --chuid root --chdir /conquest --exec /conquest/dgate --startas /conquest/dgate --background -- -^/conquest/serverstatus.logroot@vlconquest01:/conquest# ps -elf | grep dgate | grep -v grep | awk '{ print $4}'root@vlconquest01:/conquest# start-stop-daemon --start --chuid root --chdir /conquest --exec /conquest/dgate --startas /conquest/dgate --background -- -^/conquest/serverstatus.logroot@vlconquest01:/conquest# ps -elf | grep dgate | grep -v grep | awk '{ print $4}'5832


    I'm not sure, but the issue might have something to do with the PIDFILE variable within the script

    Code
    PIDFILE=/var/run/$NAME.$PORT.pid


    I don't see anywhere in the script where the PIDFILE is actually being created. To confirm this, I looked in the directory to be sure and the PIDFILE doesn't exist.

    Code
    ls -lhtr /var/run/


    Notice in the second example where i tried to run the start script manually several different ways, of the ways tried, i ran it BOTH omitting and with the PID section. Regardless of the variations, It still took multiple tries before dgate actually started.


    In the end, I created my own script.


    FIRST, I created a shell script (such as is suggested) in /etc/rc5.d called Z99Conquest, that contains

    Code
    /conquest/dgate -^/conquest/serverstatus.log & >/dev/null


    This script starts Conquest on server boot.


    THEN, I created this script for manually starting and stopping Conquest, named /conquest/cqservice

    Code
    CQHOME=/conquestif [ $1 = start ]; then CQPID=`ps -elf | grep dgate | grep -v grep | awk '{ print $4}'` if [ -z "$CQPID" ]; then echo "Starting Conquest" /etc/init.d/conquest >/dev/null CQPID=`ps -elf | grep dgate | grep -v grep | awk '{ print $4}'` echo "The Conquest PID is ::" $CQPID else echo "Conquest Already Running under ::" $CQPID fi echofiif [ $1 = stop ]; then echo "Stopping Conquest" CQPID=`ps -elf | grep dgate | grep -v grep | awk '{ print $4}'` if [ -z "$CQPID" ]; then echo "Conquest Not Running. Terminating Script." exit fi kill $CQPID echofiif [ $1 = restart ]; then echo "Stopping Conquest" CQPID=`ps -elf | grep dgate | grep -v grep | awk '{ print $4}'` if [ -z "$CQPID" ]; then echo "Starting Conquest" /etc/init.d/conquest >/dev/null CQPID=`ps -elf | grep dgate | grep -v grep | awk '{ print $4}'` echo "The Conquest PID is ::" $CQPID exit fi kill $CQPID echo echo "Starting Conquest" /etc/init.d/conquest >/dev/null CQPID=`ps -elf | grep dgate | grep -v grep | awk '{ print $4}'` echo "The Conquest PID is ::" $CQPID echofi


    I've tested this script successfully. I know it's much simpler, probably less eligant, and may not account for certain situations, but for a quick and dirty basic start/stop/restart script, it works.


    Example usage ::

    Code
    /conquest/cqservice stop
    /conquest/cqservice start
    /conquest/cqservice restart
  • My Restart Script :: Updated


    Example usage ::

    Code
    /conquest/cqservice status/conquest/cqservice clstatus/conquest/cqservice stop/conquest/cqservice start/conquest/cqservice restart/conquest/cqservice clrestart


    (1) I've added a status option so that you can see whether the dgate service is running or not - status.


    **I have two Conquest servers running in a cluster for redundancy, so....


    (2) There's also an option to check the status of the dgate service on the cluster (both local and peer Conquest servers) - clstatus.
    (3) I may also want to restart the dgate service on the cluster (both local and peer Conquest servers), instead of just on the local system - clrestart.
    - Lets say I'm using 192.168.1.71 for Conquest01 and 192.168.1.72 for Conquest02
    - This will restart the dgate service on the cluster; otherwise, I can just use the restart option if I only want to restart the dgate service on whichever server I'm currently logged into


    To use this script


    (1) you'll need to first make sure you've created a shell script in /etc/rc5.d called Z99Conquest, that
    contains

    Code
    cd /conquest/conquest/dgate -^/conquest/serverstatus.log & >/dev/null


    (2) Then update your Conquest home CQHOME; and ONLY if you are running two servers in a cluster, update the remote aka peer CQPEER IP address, otherwise, comment out CQPEER and any other section relating to the cluster such as clstatus and clrestart.


    (3) IF you are running Conquest on an identical system as part of a cluster for redundancy purposes, THEN copy this script to the peer system and repeat the TWO steps above for that system. Example :: 192.168.1.71 for Conquest01 and 192.168.1.72 for Conquest02.


    Reference
    I'm running Ubuntu 12.04 LTS, with Conquest 1.4.17c
    My conquest home location is /conquest
    My restart script is called cqservice and is located at /conquest/cqservice


    Here's my latest Conquest Restart Script

  • hello
    I have 1.4.17b running on my win 7 server, recently downgraded from "c" because of issues. right now I have setup for mirror it was working correctly up until today. suddenly it can't see right location of mirror drive. I have double and triple checked dicom.ini file and location is correct but in gui it shows different drive when it writes failed to copy mirror drive. is there any other config file where else I have to change I'm really confused why it can't see right location in dicom.ini file?

  • Hi,


    the value in dicom.ini at time of server startup is used, not the one you see in the GUI. But the GUI keep copies of the variables. Writing setup from the GUI may therefore overwrite dicom.ini settings. I.e., either config from dicom.ini or the GUI but not both.


    Van you post your dicom.ini?


    Marcel

  • hello
    here is my dicom.ini
    so is there any solution? I did restarted PC and dicom server itself many times thinking it may read correct dicom.ini settings after, but still does same :?

  • hello
    I tried your suggestion and still this happens: ***Writing mirror copy failed: f:\studybkp\
    I did tried 1.4.17c just to see if its "b" version, but it does on "c" too. there got to be way to make it see right location. may be deleting some files or downloading fresh copy may help?
    any suggestions? thanks for your help

  • Hi,


    it says f:\ in the message, while it says g:\ in your ini file for the mirror device. Is there an dgate.exe running that is not in control of the GUI?


    Try this:


    open gui
    uninstall as service
    close gui
    open task manager
    kill dgate.exe if you can find any


    open gui again
    see if everything runs ok.


    Marcel

  • hello
    yes that's what I was trying to say in gui it sees different location while dicom.ini has different location and I did tried the steps u just suggested and didn't work. I just did again and no luck still gui sees f:\ drive instead of g:\ drive. in task manager it shows dgate64.exe no other tasks. any other suggestions? thank you.

  • Hi,


    there is a backlog file called CopyFailuresxxxx. This stores all failures from the past and will retry once in a while. The copy commands with the f:\ disk may be stored in there. Can you check that such a file exists and delete it?


    Marcel

  • A preview of 1.4.17d is available.


    ftp://ftp-rt.nki.nl/outbox/Mar…rver/dicomserver1417d.zip
    ftp://ftp-rt.nki.nl/outbox/Mar…conquestlinux1417d.tar.gz
    ftp://ftp-rt.nki.nl/outbox/Mar…icomserver/dgate1417d.zip
    ftp://ftp-rt.nki.nl/outbox/Mar…mserver/dicomlib1417d.zip


    Please try it out.


    Marcel


    Postgres users:
    1) create database
    2) right click on database ->properties -> definition
    3) table space-> pg_default
    4) set definition to coding you want

  • I tried starting a basic 1.4.17d instance with a SqLite database. After generating the database tables, I went straight to "browse database" and tried to anonymize the HEAD_EXP2 data set. Unlike the earlier versions of 1.4.17, the patient ID I entered was indeed written to the patient, both in the DICOM files and in the patient list in the Conquest GUI. Unfortunately it seems that some of the internal references broke; I get nothing in the study- and series lists when I select the newly anonymized patient. If I open the DICOM files in DicomPyler, everything appears fine, but even if I try to rebuild the Conquest database the issue remains.


    Any thoughts?


    I'm on a Win7 x64 by the way.

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!