OpenREM version 1 not able to load skin dose maps for high dose procedures

[Ingrid Turner]

Hi Ed / David,

Sorry to keep bringing up the subject of the skin dose maps!

We now have the new version of OpenREM available at North Bristol for testing, but I have found that I am unable to view the skin dose maps for high dose procedures - it looks as though the system is timing out after a few minutes after trying to load. I'm guessing this is because the phantom is now bigger with the head model and has more information to display.

This may be a stupid question but is there any way of increasing the length of time before the system times out? Or is there a way of loading the maps offline using the downloaded RDSR? Usually if I can view a map there is also a link available to download the .csv export that can be loaded into OpenSkin, but this is not available until the map has loaded (if that makes sense). 

I was also wondering if there was a way to display the calculated peak skin dose without loading the map, e.g. with the DAP and RP dose information to the left of the map? This would then at least give me something to compare to our results in the interim.

I can send a screenshot to illustrate the issue if needed.

Many thanks and best wishes,

Ingrid

[Ed McDonagh]

Hi Ingrid

Glad to hear you are testing v1.0!

Do the skin maps work for any of your studies?

Thanks,

Ed

--
You received this message because you are subscribed to the Google Groups "OpenREM" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openrem+u...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/openrem/f0fc4f8d-1e8d-43b3-a698-2de5d5ae5b21n%40googlegroups.com.

[David Platten]

Hi,

If you're using a Windows server you can increase the web server timeout: https://docs.openrem.org/en/1.0.0b2/install_windows.html#webserver

The new skin dose map code takes longer to calculate than the previous code even for the same phantom size because it now makes four calculations for each 1x1 cm patch rather than just one.

Kind regards,

David

To view this discussion on the web, visit https://groups.google.com/d/msgid/openrem/CAKjkgSQjr7xgB_646isDbbFitMUC6wMHHt%3DPhEceYG9bFS6c4Q%40mail.gmail.com.

[Ingrid Turner]

Hi both,

Many thanks for getting back to me, I thought it might be something simple like that! 

I will have a go at this if I can do it without admin rights, otherwise I'll ask IT to do it :-)

In answer to Ed - yes they do work for the more simple studies but I guess this is because there are less fields to load onto the phantom etc. So it's been good to see it working in that regard!

Many thanks,

Ingrid

[Ross Dawson]

Hi Ed & David,

Having been responsible for the very painless migration to Docker from a linux build in testing we've discovered the wait time to generate the maps does take a considerable time when we hit the 100 event mark. Some reference over 200 events that won't generate. On increasing the https web and timeout value and appending --timeout 600 to the docker YAML file to help alleviate the issue and stopping and starting the container instances (with the docker compose down and docker compose up -d command )the export tasks don't seem to be completing now although they where working when the database was imported and initial migration commands where run. No DICOM info has been fed to this new system to test DICOM dose. 

This email or any attachments may contain confidential or legally privileged information intended for the sole use of the addressees. Any use, redistribution, disclosure, or reproduction of this information, except as intended, is prohibited. If you received this email in error, please notify the sender and remove all copies of the message, including any attachments.

[Ed McDonagh]

Have the docker containers come up cleanly? Is there anything in the docker logs? It looks to me like something didn't shut down or start up again properly?

To view this discussion on the web, visit https://groups.google.com/d/msgid/openrem/51a8c2c0-17b9-4f5e-aad6-7f4b203ce890n%40googlegroups.com.

[Ross Dawson]

Hi Ed, 

Although the containers appear to stop and start


 I'm not convinced they are able to handle unclean shutdowns. I've reviewed the startup with 
docker-compose logs -ft

openrem-redis      | 2023-09-21T07:50:20.825818912Z 1:C 21 Sep 2023 07:50:20.825 # Redis version=7.0.12, bits=64, commit=00000000, modified=0, pid=1, just started
openrem-redis      | 2023-09-21T07:50:20.825821678Z 1:C 21 Sep 2023 07:50:20.825 # Warning: no config file specified, using the default config. In order to specify a config file use redis-server /path/to/redis.conf
openrem-redis      | 2023-09-21T07:50:20.825823646Z 1:M 21 Sep 2023 07:50:20.825 * monotonic clock: POSIX clock_gettime
openrem-redis      | 2023-09-21T07:50:20.827236947Z 1:M 21 Sep 2023 07:50:20.826 * Running mode=standalone, port=6379.
openrem-redis      | 2023-09-21T07:50:20.827246901Z 1:M 21 Sep 2023 07:50:20.826 # Server initialized
openrem-redis      | 2023-09-21T07:50:20.827248927Z 1:M 21 Sep 2023 07:50:20.826 * Loading RDB produced by version 7.0.12
openrem-redis      | 2023-09-21T07:50:20.827250579Z 1:M 21 Sep 2023 07:50:20.826 * RDB age 245 seconds
openrem-redis      | 2023-09-21T07:50:20.827252116Z 1:M 21 Sep 2023 07:50:20.826 * RDB memory usage when created 0.96 Mb
openrem-redis      | 2023-09-21T07:50:20.827253806Z 1:M 21 Sep 2023 07:50:20.826 * Done loading RDB, keys loaded: 1, keys expired: 0.
openrem-redis      | 2023-09-21T07:50:20.827255177Z 1:M 21 Sep 2023 07:50:20.826 * DB loaded from disk: 0.000 seconds
openrem-redis      | 2023-09-21T07:50:20.827256528Z 1:M 21 Sep 2023 07:50:20.826 * Ready to accept connections

I've got the logs in debug mode at the moment. The only thing that warns is redis 

The issue looks like django timeouts from yesterdays testing. Could this be the issue?

[2023-09-20 14:56:27 +0000] [1] [CRITICAL] WORKER TIMEOUT (pid:8)
[2023-09-20 15:56:27 +0100] [8] [INFO] Worker exiting (pid: 8)
[2023-09-20 14:56:27 +0000] [11] [INFO] Booting worker with pid: 11
Internal Server Error: /admin/auth/user/2/change/
Traceback (most recent call last):
  File "/usr/local/lib/python3.10/site-packages/django/db/backends/utils.py", line 84, in _execute
    return self.cursor.execute(sql, params)
psycopg2.errors.UniqueViolation: duplicate key value violates unique constraint "django_admin_log_pkey"
DETAIL:  Key (id)=(12) already exists.


The above exception was the direct cause of the following exception:

Kind regards,

Ross

[Ed McDonagh]

The Redis warning looks normal to me, I think we keep the default config.

The django_admin_log_pkey issue seems to be the issue - I guess that could have been from an unclean shutdown of the docker container?

There aren't many references to it I can find, but there is a django-users thread from a decade ago that has this error and a solution, but it involves using SQL to reset the index or delete the log.

Do you know how the error may have come about?

Ed

To view this discussion on the web, visit https://groups.google.com/d/msgid/openrem/69f819e9-a259-41ca-a2f4-15ef2309d500n%40googlegroups.com.

[Ed McDonagh]

I forgot to include the link to the google-group discussion: https://groups.google.com/g/django-users/c/hAD0XfpF3UY/m/238fgt9NBAAJ

[Ingrid Turner]

Many thanks for trying to resolve this everyone! Sorry I am a bit useless when it comes to this kind of thing!

Given that we've tried a number of options with increasing the timeouts etc, is there anything else we can try to successfully load the skin dose maps online without things giving up? Ross is able to load them at his end as he has a high speed connection, but for me and other users there is something else stopping the process after 5 minutes regardless of what the timeout is set to.

Ross has shown me how to disable the maps and just get the export link to download the openSkin export - is there a copy of openSkin available which I could run locally without relying on a network connection? Sorry again if that's a daft question!

BW,

Ingrid

[Ed McDonagh]

Can you tell me all the timeouts you've investigated, so I can try and work out what is missing?

Thanks,

Ed

To view this discussion on the web, visit https://groups.google.com/d/msgid/openrem/f8232342-ba67-4ada-935e-348c4f09f206n%40googlegroups.com.

[Ingrid Turner]

Hi Ed,

Just looking back at my correspondence with Ross, I believe we did the following (Ross please correct me if I am wrong!):

• Modified config for HTTPS (using the OpenREM documentation for Linux webservers) resulting in a 5 minute timeout
• Then found there was an additional security overlay of linux called selinux - there were a number of exemptions that had to be allowed so that OpenREM could read and write the data. At this point, Ross could load the maps in a number of seconds from his high speed remote connection but I was still stuck with things giving up after 5 minutes
• Ross then upped the timeout (I assume the same one as the 1st step) to 15 minutes, but when I tried to load the maps with high number of events these would still give up at 5 minutes. Ross could load them his end after about 10 minutes (for about 100 events). Ross got an upstream (HTTP) warning for the timeout. He said the following: "The system needs time to generate this map by the looks of things but is insisting on a constant web connection while this happens. Its unlikely to work under these circumstances as upstream servers  (not openrem or the nginx instance serving the web content) could be cutting off the connection before the map is generated."

I think that's what we've tried so far. The problem may also be to do with the fact I am having to remote desktop to North Bristol's network from UHBW. However I did go up to North Bristol to try it directly on their system a few weeks ago and I had the same problem! Hope that helps?

Many thanks,

Ingrid

[Ed McDonagh]

Can I check (maybe a question for Ross) - you mentioned SELinux so are you using Redhat, or a Redhat derivative? And are you using Docker or a native install?

Also, do you have "Calculate skin dose map on import?" ticked? If you do, are large studies that have been recently imported presenting the skin dose map correctly?

Ed

P.S. I don't think the remote desktop will have any impact :)

To view this discussion on the web, visit https://groups.google.com/d/msgid/openrem/1ff63b80-6cda-4de8-8ee7-33bf296165e9n%40googlegroups.com.

[Ingrid Turner]

Hi Ed,

First question above definitely for Ross, although I believe we are using Docker?

Yes I have the "calculate skin dose map on import" box ticked. I've not been able to check any large studies unfortunately as I the maps stop loading, even with this feature turned on. The simpler studies however do appear to me importing correctly :-)

Many thanks,

Ingrid

[Ross Dawson]

Hi Ed, Ingrid

 

I’ve just discovered I hadn’t set the gunicorn ttimout but had set Nginx timeout.

 

The nginx docker config and the command for  gunicorn are now set to 300

 

 

Although I did get more coverage with 600 longer waits did produce more results as the time to wait for large events spilled over 300s but at the cost of web performance when enabling this huge timeout triggers the client time-out settings.

 

You just need to click the wait button but it’s not the best option.

 

Kind regards,

Ross

Hi Ed, 

 

Hi Ed & David,

 

Having been responsible for the very painless migration to Docker from a linux build in testing we've discovered the wait time to generate the maps does take a considerable time when we hit the 100 event mark. Some reference over 200 events that won't generate. On increasing the https web and timeout value and appending --timeout 600 to the docker YAML file to help alleviate the issue and stopping and starting the container instances (with the docker compose down and docker compose up -d command )the export tasks don't seem to be completing now although they where working when the database was imported and initial migration commands where run. No DICOM info has been fed to this new system to test DICOM dose. 

--
You received this message because you are subscribed to a topic in the Google Groups "OpenREM" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/openrem/Iun0uWPMSQI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to openrem+u...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/openrem/45e2b4ff-87ee-4461-8851-64e202a5a424n%40googlegroups.com.

[Ingrid Turner]

Hi Ross / all,

Thank you for spotting this, I've just had another go at loading something with 96 events with these new settings - the timer is now not cutting out at 5 minutes but even this exam is not loading for me after 15 minutes.

The timer still seems to keep going after 15 minutes but I'm given up timing it!

The procedures we typically need to check often have a high number of events, usually in the 100s. There is one one there currently that has >800 events.

I also think there is something inconsistent happening as i.e. not a linear response, as I just tried to load another exam with about 50 events and this only took ~2mins to load. Perhaps there is an issue with bi-plane machines?

Sorry that's probably not very helpful, I'm trying to find any patterns with the loading times!

Many thanks,

Ingrid

[Ed McDonagh]

Do you know what the resources of this machine are? It does seem to be taking a long time.

I don't understand why they aren't coming up quickly for recent studies that have had the maps calculated on import. And for those that are only calculated on opening the web page, we need to be able to make that process be asynchronous too.

We (developers) need to discuss this further!

To view this discussion on the web, visit https://groups.google.com/d/msgid/openrem/367322f8-0371-4340-83a4-70db3772a74dn%40googlegroups.com.

[Ingrid Turner]

It's not letting me open the resource monitor on the virtual machine but looks like the CPU is going a bit mad...

I'm wondering if the maps that are actually loading have been calculated on import as it is behaving very inconsistently - I tried another example from August on a single plane machine and the timer gave up after 5 minutes. So perhaps Ross's changes only apply to exams after he has made the changes?

Is there a way to re-import them so that they are all calculated on import?

Sorry this is a headache for you!

[Ed McDonagh]

That looks like the resource monitor for the virtual desktop you are using to run the browser client? It was the specs of the server system I was interested in.

Something is obviously not working with the generate on import function with your setup - with my system any study that has come in since I upgraded to the new software opens within a few seconds, including the skin dose map. I've tried that with studies with 600 exposures, and studies with two planes involved.

However, large studies that were not processed on import do take more than the 300 seconds/5 minutes that my system is currently configured to, leaving the page with no content where the map should be.

I'll have a think about it/talk to David about how we can improve the experience. Thank you for generating the feedback, it is much appreciated!

Kind regards

Ed

[Ingrid Turner]

Yes, I'm not sure how to get the server specs - might be another question for Ross!

So sorry it's being such a pain, it does sound like it can be done with a high speed connection and perhaps there is a way to re-import and process the maps...

I'll see you at the IPEM event anyway! :-D 

[Ross Dawson]

Hi Ed,

 

The system is a VM running on a 2 server cores @ 3.2 GHz and 8GB RAM and 100GB disk space on SSD media.

I’ve not had much experience with the OpenREM  database but if I can reset it and re-import  a DB dump clearing the existing DB data first can the steps I followed be repeated or do I need to perform a different set of steps?

Kind regards,

Ross

 

 

From: ope...@googlegroups.com <ope...@googlegroups.com> On Behalf Of Ingrid Turner
Sent: Monday, October 2, 2023 10:48 AM
To: OpenREM <ope...@googlegroups.com>
Subject: Re: [openrem] OpenREM version 1 not able to load skin dose maps for high dose procedures

 

Yes, I'm not sure how to get the server specs - might be another question for Ross!

--

You received this message because you are subscribed to a topic in the Google Groups "OpenREM" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/openrem/Iun0uWPMSQI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to openrem+u...@googlegroups.com.

To view this discussion on the web, visit https://groups.google.com/d/msgid/openrem/b8f39ffd-f99c-40e7-852d-94ebc7f56fd9n%40googlegroups.com.

[Ross Dawson]

Hi Ed,

 

The system is not receiving any DICOM just yet. I just realised, we have only imported the database and not sent in any DICOM so if a DICOM send is required to trigger the creation process can we send a manual trigger event for the imported DB on the existing exams before sending in some live data?

 

Kind regards,

Ross

 

From: Ross Dawson <ross....@intelerad.com>
Sent: Thursday, October 5, 2023 4:07 PM
To: 'Ingrid Turner' <irtu...@hotmail.co.uk>; 'OpenREM' <ope...@googlegroups.com>
Subject: RE: [openrem] OpenREM version 1 not able to load skin dose maps for high dose procedures

 

Hi Ed,

 

The system is a VM running on a 2 server cores @ 3.2 GHz and 8GB RAM and 100GB disk space on SSD media.

I’ve not had much experience with the OpenREM  database but if I can reset it and re-import  a DB dump clearing the existing DB data first can the steps I followed be repeated or do I need to perform a different set of steps?

Kind regards,

Ross

 

 

From: ope...@googlegroups.com <ope...@googlegroups.com> On Behalf Of Ingrid Turner

Sent: Monday, October 2, 2023 10:48 AM

To: OpenREM <ope...@googlegroups.com>
Subject: Re: [openrem] OpenREM version 1 not able to load skin dose maps for high dose procedures

 

Yes, I'm not sure how to get the server specs - might be another question for Ross!

--

You received this message because you are subscribed to a topic in the Google Groups "OpenREM" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/openrem/Iun0uWPMSQI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to openrem+u...@googlegroups.com.

To view this discussion on the web, visit https://groups.google.com/d/msgid/openrem/b8f39ffd-f99c-40e7-852d-94ebc7f56fd9n%40googlegroups.com.

[Ed McDonagh]

Hi Ross, Ingrid

It was good to see you Ingrid on Wednesday, thank you for your talk. Shame I didn't work out who you were earlier in the day so I could have said hello properly!

Ross, regarding the database re-import, can you confirm that you are using Docker (or Podman?) on Redhat Linux? If so, I'll have a look at the instructions and see if I can point you in the right direction.

Regarding the skin dose maps not being generated - it had occurred to me that you might be using a migrated database so there are no new RDSRs coming in, and hence no skin dose maps being generated on import! David hopefully is going to be able to work on making the trigger to generate the maps a background task when you open the study, which should resolve the issue on a study-by-study basis. We should also look at whether we can somehow trigger them in a bulk fashion too, but I think that would be a lower priority.

Kind regards

Ed

You received this message because you are subscribed to the Google Groups "OpenREM" group.

To unsubscribe from this group and stop receiving emails from it, send an email to openrem+u...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/openrem/f3338aaa5665e161dc08e0c1a1197838%40mail.gmail.com.

[Ed McDonagh]

Forgot the link to the issue: https://bitbucket.org/openrem/openrem/issues/1007/make-skin-dose-map-calculation-a

[Ross Dawson]

Hi Ed,

 

Using Docker on Rocky Linux 9.2

 

Kind regards,

Ross

To view this discussion on the web, visit https://groups.google.com/d/msgid/openrem/CAKjkgSSiOjP-_Mm%3DjYdg1hUAkUFogYkbivv22sON4KpaRjUKUA%40mail.gmail.com.

[Ingrid Turner]

Hi Ed,

Yes lovely to meet you on Wednesday and hopefully I got all my facts right! 😂 That's ok, I should have made myself more obvious! I had a chat with David and he also mentioned about the migrated database issue so that does make sense and seems to line up with what's happening our end.

Thank you so much again for taking the time to look into all of this 😊

BW,

Ingrid

---

From: ope...@googlegroups.com <ope...@googlegroups.com> on behalf of Ed McDonagh <e...@openrem.org>
Sent: 06 October 2023 09:43

To view this discussion on the web, visit https://groups.google.com/d/msgid/openrem/CAKjkgSSiOjP-_Mm%3DjYdg1hUAkUFogYkbivv22sON4KpaRjUKUA%40mail.gmail.com.

[dpla...@gmail.com]

Hi All,

I have been working on a branch of the source code that uses a background task for all skin dose map calculations. I think it might solve the problems you've been having.

The branch is here: https://bitbucket.org/openrem/openrem/branch/issue1007calculateSkinDoseMapsInBackground

I have tested it and as far as I can see it works as expected.

I'm afraid that I don't know how you go about testing it in a Docker container - perhaps Ed could advise on that?

Kind regards,

David

[Ingrid Turner]

Hi David,

Apologies for my delayed reply, that's really great news thank you for working on that!

We'll have a go and see if we can get it to work :)

Best wishes,

Ingrid

[Ed McDonagh]

Hi Ingrid, David

I need to build you a new image, and my initial attempt failed because one of the packages has changed. I'll try and get back to it as soon as I can.

Kind regards

Ed

To view this discussion on the web, visit https://groups.google.com/d/msgid/openrem/322530de-b791-4d20-9e12-7b99401c581an%40googlegroups.com.

[Ingrid Turner]

Hi all and happy new year!

Sorry to jump in but I don't suppose you have any development on the new branch of the code for testing in a Docker container? 

Apologies if I've missed something.

Many thanks,

Ingrid :-) 

[Ed McDonagh]

Sorry, my fault. I need to test it. I'll try and do it in the next few days.

To view this discussion on the web, visit https://groups.google.com/d/msgid/openrem/c4aee0d0-e769-43c3-8d9d-4a1f4fc0ddb1n%40googlegroups.com.

[Ingrid Turner]

No problem! Many thanks Ed :-)

[Ross Dawson]

Hi Ed,

Something I've been meaning to point out is your Offline Docker Documentation needs updating.
Offline Docker installation — OpenREM 1.0.0b2 documentation

The pull commands are not the same as the image repos in the yml docker compose file and you get the following error.

[root@OPENREM10B localimg]# docker pull openrem/openrem:release-1.0.0b2

Error response from daemon: manifest for openrem/openrem:release-1.0.0b2 not found: manifest unknown: manifest unknown

That and no export the redis image. So if you were to try the docker compose up command; this would fail.

REPOSITORY        TAG                   IMAGE ID       CREATED        SIZE

redis             7-alpine              20658529aaf6   8 days ago     46.1MB

postgres          12-alpine             07f0565a99b5   3 weeks ago    234MB

rabbitmq          3-management-alpine   a095b429d01b   7 months ago   175MB

openrem/openrem   1.0.0b2               703970188cb4   9 months ago   1.11GB

nginx             stable-alpine         0cd127114627   9 months ago   41.1MB

openrem/orthanc   latest                9584cf7ae800   3 years ago    819MB

Kind regards,

Ross

To view this discussion on the web, visit https://groups.google.com/d/msgid/openrem/CAKjkgSQ8AV7Fu7D%3D9wsjVj%2B1b1cvc_1-1FQy6qcpfQkiLu3Now%40mail.gmail.com.

[Ingrid Turner]

Hi Ed / David,

I was just wondering if there had been any progress with this or perhaps I missed something? So sorry to keep asking, I imagine you are snowed under!

We are also having a lot of problems at North Bristol with the current version of OpenREM not showing new exports routinely. Ross I think is now in a new role so not available to help (correct me if I'm wrong), so I'm trying to explain the issue to the PACS team who look after it but they keep asking for further details. Ross if you're still there could you let me know again what the issue is with this? It think it was to do with disk space and it resolved if the system was re-booted?

Apologies for the brain dump!

Many thanks,

Ingrid

On Monday 15 January 2024 at 16:00:41 UTC Ed McDonagh wrote:

[h4n ke]

dear all, this appears to be the best conversation for my question, 

Here in my hospital we have a good functioning version of OpenREM 0.9.0

Now Skin dose map was currently not being used. 

I
 modified the settings, "enable skin dose maps", "calculate skin dose
maps", and have been retrospectively loading the high dose at RP
studies. In some of our patient groups >100 events happens regularly.
Now I find a very poor "succes rate" of skin dose map, which is in my top 20 of highest exposures only 60%.

I
 think this is related to a calculation/time-out issue as pointed out
above, as my low-dose group has a succes rate of skin dose map that is
100% (I quickly checked in a small group of 8).






update: error and fix below:


Skin dose map is not generated; “Radiation exposure incidence map” stays empty.
 
Check nginx log:
 
tail -f -n -10 /var/log/nginx/error.log
 
Example error:
 
2025/09/18 10:17:01 [error] 19105#19105: *343 upstream prematurely closed connection while reading response header from upstream, client: xxx.xx.x.xxx, server: xxxx, request: "GET /openrem/rf/212375/skin_map/?http%3A%2F%2Fxxxxx%2Fopenrem%2Frf%2F212375%2F=undefined HTTP/1.1", upstream: "http://unix:/tmp/xxxxx.socket:/openrem/rf/212375/skin_map/?http%3A%2F%2Fxxxxx%2Fopenrem%2Frf%2F212375%2F=undefined", host: "xxxxx", referrer: http://xxxxx/openrem/rf/212375/
 
Identify gunicorn process PID
 
ps -ef | grep gunicorn
 
Sep 18 10:17:01 xxxxx.xx.nl gunicorn[1221]: [2025-09-18 10:17:01 +0000] [1221] [CRITICAL] WORKER TIMEOUT (pid:19379)
 
Fix wsgi timeout:
 
Find openrem service, in my case:
/etc/systemd/system/ gunicorn-openrem.service
sudo nano gunicorn-openrem.service
 
Increase wsgi timeout from 300 to (for example) 3600
 
ExecStart=/var/dose/veopenrem/bin/gunicorn \
    --bind unix:/tmp/openrem-server.socket \
    openremproject.wsgi:application --timeout 3600 --workers 4
 
systemctl daemon-reload
 
restart service
 
systemctl restart gunicorn-openrem
 
Fix nginx timeout:
 
Edit the nginx config file:
 
nano /etc/nginx/sites-available/server-name
 
server {
    listen 80;
    server_name server-name;
    location /static {
        alias /var/dose/static;
    }
    location / {
        proxy_pass http://unix:/tmp/openrem-server.socket;
        proxy_set_header Host $host;
        #proxy_read_timeout 300s;
        proxy_read_timeout 3600;
        proxy_connect_timeout 3600;
        proxy_send_timeout 3600;
        proxy_buffers 8 16k;
        proxy_buffer_size 32k;
    }
}
 
Test the config
 
nginx –t
 
Reload
systemctl reload nginx
 

Op dinsdag 12 maart 2024 om 11:14:51 UTC+1 schreef irtu...@hotmail.co.uk:

[Ed McDonagh]

Hi. All the development work to improve skin maps has been going into the current development version, which should be released as version 1.0 in the next few weeks.

Hopefully when you are able to upgrade, you will have a better experience with them.

Kind regards

Ed

To view this discussion, visit https://groups.google.com/d/msgid/openrem/209a23ee-2bdb-4a0b-a976-1a3fa4e5a777n%40googlegroups.com.