You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Usually, when creating a mid server container, it starts doing an upgrade. After that I manually rekey it and that's it. This worked with quebec and all before them. With sandiego however the container restarts endlessly after what looks like an unsuccessful upgrade. In Servicenow the mid server alternates endlessly between "Upgrading" and "Down" status.
The command used to create the container:
sudo docker run -d --name servicenow_mid --restart unless-stopped --env SN_HOST_NAME=acme.service-now.com --env USER_NAME=acme-mid --env PASSWORD=**** moers/mid-server:sandiego.latest
The user has the roles "mid_server" and "snc_internal", only allowed for webservices. To avoid any local permission issues, I temporarily made the user an admin.
There are a number of warnings in the logs (see attachment). Among those:
AutoUpgrade.3600 WARNING *** WARNING *** Unable to determine upgrade scenario with current=sandiego-12-22-2021__patch9a-hotfix1-01-31-2023_02-01-2023_1625 assigned=sandiego-12-22-2021__patch9a-12-12-2022_01-04-2023_0931
Maybe that's an indication ?
Is there something I can check to fix this issues ?
THX
Maybe related to this issue, the shutdown doesn't seem to complete gracefully. The typical last lines in the logs are:
03/02/23 09:25:24 (742) MIDServer MID Server stopped
03/02/23 09:25:24 (742) MIDServer the ServiceNow MID Server is now terminated
DOCKER MONITOR: /opt/agent/logs/agent0.log.0 last updated 6 sec ago
...
DOCKER MONITOR: /opt/agent/logs/agent0.log.0 last updated 307 sec ago
DOCKER MONITOR: /opt/agent/logs/agent0.log.0 was not updated for 300sec, MID server potentially frozen.
DOCKER MONITOR: Stopping MID server process 1 now!
DOCKER: Stop MID server
It always restarts because the logs are too old. Even though /opt/agent/work/mid.pid is gone. But maybe that's the intention.
PS. Great work ! It's so much easier for managing mid servers !
The text was updated successfully, but these errors were encountered:
Usually, when creating a mid server container, it starts doing an upgrade. After that I manually rekey it and that's it. This worked with quebec and all before them. With sandiego however the container restarts endlessly after what looks like an unsuccessful upgrade. In Servicenow the mid server alternates endlessly between "Upgrading" and "Down" status.
The command used to create the container:
sudo docker run -d --name servicenow_mid --restart unless-stopped --env SN_HOST_NAME=acme.service-now.com --env USER_NAME=acme-mid --env PASSWORD=**** moers/mid-server:sandiego.latest
The user has the roles "mid_server" and "snc_internal", only allowed for webservices. To avoid any local permission issues, I temporarily made the user an admin.
There are a number of warnings in the logs (see attachment). Among those:
AutoUpgrade.3600 WARNING *** WARNING *** Unable to determine upgrade scenario with current=sandiego-12-22-2021__patch9a-hotfix1-01-31-2023_02-01-2023_1625 assigned=sandiego-12-22-2021__patch9a-12-12-2022_01-04-2023_0931
Maybe that's an indication ?
Is there something I can check to fix this issues ?
THX
Maybe related to this issue, the shutdown doesn't seem to complete gracefully. The typical last lines in the logs are:
03/02/23 09:25:24 (742) MIDServer MID Server stopped
03/02/23 09:25:24 (742) MIDServer the ServiceNow MID Server is now terminated
DOCKER MONITOR: /opt/agent/logs/agent0.log.0 last updated 6 sec ago
...
DOCKER MONITOR: /opt/agent/logs/agent0.log.0 last updated 307 sec ago
DOCKER MONITOR: /opt/agent/logs/agent0.log.0 was not updated for 300sec, MID server potentially frozen.
DOCKER MONITOR: Stopping MID server process 1 now!
DOCKER: Stop MID server
It always restarts because the logs are too old. Even though /opt/agent/work/mid.pid is gone. But maybe that's the intention.
PS. Great work ! It's so much easier for managing mid servers !
The text was updated successfully, but these errors were encountered: