Webpage for the project down #959

New issue

Closed

opened 2026-05-14 12:31:55 +00:00 by Andras · 15 comments

Andras commented 2026-05-14 12:31:55 +00:00

Owner

Copy link

http://193.93.250.90/app/

is down on a non-work day. We need service windows, but it is crucial that the service is available when not being actively maintained.

[http://193.93.250.90/app/](http://193.93.250.90/app/) is down on a non-work day. We need service windows, but it is crucial that the service is available when not being actively maintained.

Andras added the

_CRITICAL_

label 2026-05-14 12:31:55 +00:00

b24johka was assigned by c24danli 2026-05-15 06:46:38 +00:00

b24johka commented 2026-05-15 07:00:08 +00:00

Collaborator

Copy link

We're aware of this, this happened during deployment on Wednesday at 19:30. Since it was already out of work hours i didn't spend too much time on figuring out why the deployment failed.

This will hopefully be resolved today.

We're aware of this, this happened during deployment on Wednesday at 19:30. Since it was already out of work hours i didn't spend too much time on figuring out why the deployment failed. This will hopefully be resolved today.

b24johka commented 2026-05-15 07:18:26 +00:00

Collaborator

Copy link

Tried deploying again and it failed, i suspected that the "nohup" in the command wasnt working and that it wasnt executed remotely on the server with SSH-disonnects. I can now dismiss this theory as i kept my SSH-connected through out the whole deployment session.
LOG:

Tried deploying again and it failed, i suspected that the "nohup" in the command wasnt working and that it wasnt executed remotely on the server with SSH-disonnects. I can now dismiss this theory as i kept my SSH-connected through out the whole deployment session. **LOG:** 

image.png

119 KiB

b24johka commented 2026-05-15 07:41:00 +00:00

Collaborator

Copy link

For the question about availability, we have no current monitoring for the server. We don't actually know when or if the webpage goes down. Our suggestion on using Prometheus for notifications on down time was disregarded by the customer, how are we gonna support availability if we cant get information about it?

For the question about availability, we have no current monitoring for the server. We don't actually know **when** or **if** the webpage goes down. Our suggestion on using Prometheus for notifications on down time was disregarded by the customer, how are we gonna support availability if we cant get information about it?

b24johka commented 2026-05-15 08:09:08 +00:00

Collaborator

Copy link

Tried to reinstall the whole project on the server but it didnt work either, apperantly the docker container "RoomBookingApiMockup" doesnt want to shutdown and has been up for 6 days.

Tried to reinstall the whole project on the server but it didnt work either, apperantly the docker container "RoomBookingApiMockup" doesnt want to shutdown and has been up for 6 days.

a24julot referenced this issue 2026-05-15 09:34:42 +00:00

Questions for product owner and customer Week 7 #963

a24sakma commented 2026-05-15 09:48:41 +00:00

Collaborator

Copy link

@b24johka wrote in #959 (comment):

Tried to reinstall the whole project on the server but it didnt work either, apperantly the docker container "RoomBookingApiMockup" doesnt want to shutdown and has been up for 6 days.

did you try to close all containers manually and the start all?

@b24johka wrote in https://git.webug.se/Andras/BoundlessFlowCampus2K/issues/959#issuecomment-10686: > Tried to reinstall the whole project on the server but it didnt work either, apperantly the docker container "RoomBookingApiMockup" doesnt want to shutdown and has been up for 6 days. did you try to close all containers manually and the start all?

b24johka commented 2026-05-15 10:00:58 +00:00

Collaborator

Copy link

Had to terminate the container "RoomBookingApiMockup" by remove orphans. Apparently containers which was is not in the compose.yaml will not be removed with docker compose down -v, which is executed on the server through the rebuild script.
This is likely the causing issue since RoomBookingApiMockup was removed from compose.yaml in the merge to main.

Currently i have restarted the server, run docker stop all and the deployment script is executing.

Had to terminate the container "RoomBookingApiMockup" by remove orphans. Apparently containers which was is not in the compose.yaml will not be removed with docker compose down -v, which is executed on the server through the rebuild script. This is likely the causing issue since RoomBookingApiMockup was removed from compose.yaml in the merge to main.  Currently i have restarted the server, run docker stop all and the deployment script is executing.

image.png

41 KiB

b24johka commented 2026-05-15 10:06:17 +00:00

Collaborator

Copy link

@a24sakma wrote in #959 (comment):

@b24johka wrote in #959 (comment):

Tried to reinstall the whole project on the server but it didnt work either, apperantly the docker container "RoomBookingApiMockup" doesnt want to shutdown and has been up for 6 days.

did you try to close all containers manually and the start all?

I haven't restarted them manually since the rebuild script is the deploy standard. If the current execution wont work i will try to rebuild everything manually. Good Idea!

@a24sakma wrote in https://git.webug.se/Andras/BoundlessFlowCampus2K/issues/959#issuecomment-11056: > @b24johka wrote in #959 (comment): > > > Tried to reinstall the whole project on the server but it didnt work either, apperantly the docker container "RoomBookingApiMockup" doesnt want to shutdown and has been up for 6 days. > > did you try to close all containers manually and the start all? I haven't restarted them manually since the rebuild script is the deploy standard. If the current execution wont work i will try to rebuild everything manually. Good Idea!

b24johka commented 2026-05-15 11:01:41 +00:00

Collaborator

Copy link

It was identified that the monolithic rebuild script (Which the server uses), had not been updated which explains a lot.
Fixed it with a updater rebuild script, now most of the containers are starting but some are not starting properly.

It was identified that the monolithic rebuild script (Which the server uses), had not been updated which explains a lot. Fixed it with a updater rebuild script, now most of the containers are starting but some are not starting properly.  

image.png

80 KiB

image.png

102 KiB

b24johka commented 2026-05-15 12:21:12 +00:00

Collaborator

Copy link

The script was the biggest problem with the deployment, we should also consider adding a docker compose down --remove-orphans to the rebuild script to ensure that we delete containers that is not referenced by the compose.yaml file.

We also have to check for a better way than to have 2 separate rebuild scripts, since both needs to be uniform.
The website is now deployed and all of the containers are healthy.
http://193.93.250.90/app/

The script was the biggest problem with the deployment, we should also consider adding a **docker compose down --remove-orphans** to the rebuild script to ensure that we delete containers that is not referenced by the compose.yaml file. We also have to check for a better way than to have 2 separate rebuild scripts, since both needs to be uniform. The website is now deployed and all of the containers are healthy. http://193.93.250.90/app/ 

image.png

115 KiB

b24johka added the

needs review

label 2026-05-15 12:21:40 +00:00

b24johka referenced this issue 2026-05-15 12:24:14 +00:00

Update Unix rebuild debug script #968

a24sakma commented 2026-05-15 12:54:37 +00:00

Collaborator

Copy link

@b24johka wrote in #959 (comment):

The script was the biggest problem with the deployment, we should also consider adding a docker compose down --remove-orphans to the rebuild script to ensure that we delete containers that is not referenced by the compose.yaml file.

We also have to check for a better way than to have 2 separate rebuild scripts, since both needs to be uniform. The website is now deployed and all of the containers are healthy. http://193.93.250.90/app/

Well done! I think sometimes the containers does not get cleaned up when you only use the script therefor some manual steps and retry with script can do some magic :)

Yeah I agree. You can open a research on automation of the scripts and a sync between them

@b24johka wrote in https://git.webug.se/Andras/BoundlessFlowCampus2K/issues/959#issuecomment-11136: > The script was the biggest problem with the deployment, we should also consider adding a **docker compose down --remove-orphans** to the rebuild script to ensure that we delete containers that is not referenced by the compose.yaml file. > > We also have to check for a better way than to have 2 separate rebuild scripts, since both needs to be uniform. The website is now deployed and all of the containers are healthy. http://193.93.250.90/app/ > > [](/Andras/BoundlessFlowCampus2K/attachments/94bf6777-1f05-430f-806b-64c107a76186) Well done! I think sometimes the containers does not get cleaned up when you only use the script therefor some manual steps and retry with script can do some magic :) Yeah I agree. You can open a research on automation of the scripts and a sync between them

a24julot commented 2026-05-18 06:41:58 +00:00

Collaborator

Copy link

Should "docker compose down --remove-orphans" be added to the script or should the issue be closed @b24johka ?

Should "docker compose down --remove-orphans" be added to the script or should the issue be closed @b24johka ?

b24johka commented 2026-05-18 07:06:56 +00:00

Collaborator

Copy link

@a24sakma wrote in #959 (comment):

@b24johka wrote in #959 (comment):

The script was the biggest problem with the deployment, we should also consider adding a docker compose down --remove-orphans to the rebuild script to ensure that we delete containers that is not referenced by the compose.yaml file.
We also have to check for a better way than to have 2 separate rebuild scripts, since both needs to be uniform. The website is now deployed and all of the containers are healthy. http://193.93.250.90/app/

Well done! I think sometimes the containers does not get cleaned up when you only use the script therefor some manual steps and retry with script can do some magic :)

Yeah I agree. You can open a research on automation of the scripts and a sync between them

The server is up and running all the time except for a short moment during rebuild, therefor old containers which exists in prior versions will be kept running unless we include the --remove-orphans in the rebuild script.
We should really avoid going in and do manual changes on server because starting containers can take up to 1h, and that would increase down time.

@a24sakma wrote in https://git.webug.se/Andras/BoundlessFlowCampus2K/issues/959#issuecomment-11180: > @b24johka wrote in #959 (comment): > > > The script was the biggest problem with the deployment, we should also consider adding a **docker compose down --remove-orphans** to the rebuild script to ensure that we delete containers that is not referenced by the compose.yaml file. > > We also have to check for a better way than to have 2 separate rebuild scripts, since both needs to be uniform. The website is now deployed and all of the containers are healthy. http://193.93.250.90/app/ > > [](/Andras/BoundlessFlowCampus2K/attachments/94bf6777-1f05-430f-806b-64c107a76186) > > Well done! I think sometimes the containers does not get cleaned up when you only use the script therefor some manual steps and retry with script can do some magic :) > > Yeah I agree. You can open a research on automation of the scripts and a sync between them The server is up and running all the time except for a short moment during rebuild, therefor old containers which exists in prior versions will be kept running unless we include the **--remove-orphans** in the rebuild script. We should really avoid going in and do manual changes on server because starting containers can take up to 1h, and that would increase down time.

b24johka commented 2026-05-18 07:08:03 +00:00

Collaborator

Copy link

@a24julot wrote in #959 (comment):

Should "docker compose down --remove-orphans" be added to the script or should the issue be closed @b24johka ?

I think it should be added to the rebuild script, i will create an issue on this.

@a24julot wrote in https://git.webug.se/Andras/BoundlessFlowCampus2K/issues/959#issuecomment-11250: > Should "docker compose down --remove-orphans" be added to the script or should the issue be closed @b24johka ? I think it should be added to the rebuild script, i will create an issue on this.

b24johka referenced this issue 2026-05-18 07:11:32 +00:00

Add --remove-orphans to the rebuild script #983

a24sakma commented 2026-05-18 10:49:00 +00:00

Collaborator

Copy link

@b24johka wrote in #959 (comment):

@a24sakma wrote in #959 (comment):

@b24johka wrote in #959 (comment):

The script was the biggest problem with the deployment, we should also consider adding a docker compose down --remove-orphans to the rebuild script to ensure that we delete containers that is not referenced by the compose.yaml file.
We also have to check for a better way than to have 2 separate rebuild scripts, since both needs to be uniform. The website is now deployed and all of the containers are healthy. http://193.93.250.90/app/

Well done! I think sometimes the containers does not get cleaned up when you only use the script therefor some manual steps and retry with script can do some magic :)
Yeah I agree. You can open a research on automation of the scripts and a sync between them

The server is up and running all the time except for a short moment during rebuild, therefor old containers which exists in prior versions will be kept running unless we include the --remove-orphans in the rebuild script. We should really avoid going in and do manual changes on server because starting containers can take up to 1h, and that would increase down time.

I meant like debugging when the script is not working but if it takes that that much time then maybe it is irrelevant here. :)

@b24johka wrote in https://git.webug.se/Andras/BoundlessFlowCampus2K/issues/959#issuecomment-11253: > @a24sakma wrote in #959 (comment): > > > @b24johka wrote in #959 (comment): > > > The script was the biggest problem with the deployment, we should also consider adding a **docker compose down --remove-orphans** to the rebuild script to ensure that we delete containers that is not referenced by the compose.yaml file. > > > We also have to check for a better way than to have 2 separate rebuild scripts, since both needs to be uniform. The website is now deployed and all of the containers are healthy. http://193.93.250.90/app/ > > > [](/Andras/BoundlessFlowCampus2K/attachments/94bf6777-1f05-430f-806b-64c107a76186) > > > > > > Well done! I think sometimes the containers does not get cleaned up when you only use the script therefor some manual steps and retry with script can do some magic :) > > Yeah I agree. You can open a research on automation of the scripts and a sync between them > > The server is up and running all the time except for a short moment during rebuild, therefor old containers which exists in prior versions will be kept running unless we include the **--remove-orphans** in the rebuild script. We should really avoid going in and do manual changes on server because starting containers can take up to 1h, and that would increase down time. I meant like debugging when the script is not working but if it takes that that much time then maybe it is irrelevant here. :)

👍 1

a24sakma commented 2026-05-20 08:21:46 +00:00

Collaborator

Copy link

This has been fixed and an issue for fixing script is created. I close this issue

This has been fixed and an issue for fixing script is created. I close this issue

a24sakma closed this issue 2026-05-20 08:21:48 +00:00

b24johka referenced this issue 2026-05-22 07:44:37 +00:00

Research and implement deployment script #701

Sign in to join this conversation.

No Branch/Tag specified

Branches Tags

main

#1236-edit-mode-txt

#1229-generic-themed-buttons

Add-an-option-to-set-no-image-to-image-view-1227

#1242-prog-bar-colors-fix

#1239-Remove-Vertical-Scroll

Image-view-error-1230

Make-the-card-title-and-header-of-card-uniform-1233

both_teams_week_8

team_2_week_7

team_1_week_7

temp_branch_week_7

team_2_week_6

team_1_week_6

team_2_week_5

team_1_week_5

temp_branch_week_5

team_2_week_4

team_1_week_4

week_4_temp_branch

temp-branch-week-3

team_2_week_3

team_1_week_3

team_2_week_2

team_1_week_2

temp-week-2-merge-branch

team_2_week_1

team_1_week_1

No results found.

Labels

Clear labels   

_CRITICAL_

Only use this label for critical tasks that are project-scope,and must be addressed ASAP.

  

API

  

app

  

backEnd

  

Blocked, waiting for further changes

  

bug

Something is not working

  

cleanup

Issues to cleanup the codebase (restructure folders, remove deprecated or smelly code)

  

close

Issue to close

  

design

  

duplicate

This issue or pull request already exists

  

enhancement

New feature

  

feature request

  

frontEnd

  

help wanted

Need some help

  

invalid

Something is wrong

  

low priority

  

needs input

Issue needs input from product owner or customer

  

needs review

issue is in need of review

  

project documentation

  

question

More information is needed

  

research

  

reviewed

This Issue has been reviewed

  

script

  

security

use this for security-related issues

  

SQL

  

style

  

testing

  

topLevel

Reserved for top-level, project-wide issues.

  

wontfix

This won't be fixed

No labels

_CRITICAL_

API

app

backEnd

Blocked, waiting for further changes

bug

cleanup

close

design

duplicate

enhancement

feature request

frontEnd

help wanted

invalid

low priority

needs input

needs review

project documentation

question

research

reviewed

script

security

SQL

style

testing

topLevel

wontfix

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

b24johka

4 participants

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

Andras/BoundlessFlowCampus2K#959

No description provided.