This repository has been archived by the owner on Apr 17, 2023. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 475
CatalogJob fails in production mode #479
Labels
Comments
By default, the Whenever I fix that issue, I'll come back to this one ;) |
I think the problem here is that the value stored in the 'log' field is the every last output from the 'bundle exec crono' not just the most recent output. So with docker compose setup it very quickly files up the field and the job stops working as it get a MySQL2 error . |
mssola
added a commit
to mssola/Portus
that referenced
this issue
Dec 15, 2015
Before this commit, the crono job kept on adding the log into the `log` column from the `crono_jobs` table. This is, of course, a bad thing. What I did to fix this is to simply remove this columns from the DB, and crono is ok with that. Running crono again with this patch runs in the very same way as it used to be, but without adding the log all the time. Moreover, the log is supposed to go to the stdout, as envisioned by the Twelve-Factor App manifesto: http://12factor.net. Docker follows this too, and by doing so then the log of this job blends in with docker-compose logs command. This has two main consequences: 1. The user can decide how to manage logs in an easier way, so there's no way that we run out of disk (an issue we were having). 2. supervisor is no longer needed. Instead, we take advantage of the compose-setup.sh script to do it properly. Before this patch, for some reason the catalog job did not reach the db container. Fixes SUSE#479 Fixes SUSE#505 Signed-off-by: Miquel Sabaté Solà <msabate@suse.com>
mssola
added a commit
to mssola/Portus
that referenced
this issue
Dec 15, 2015
Before this commit, the crono job kept on adding the log into the `log` column from the `crono_jobs` table. This is, of course, a bad thing. What I did to fix this is to simply remove this columns from the DB, and crono is ok with that. Running crono again with this patch runs in the very same way as it used to be, but without adding the log all the time. Moreover, the log is supposed to go to the stdout, as envisioned by the Twelve-Factor App manifesto: http://12factor.net. Docker follows this too, and by doing so then the log of this job blends in with docker-compose logs command. This has two main consequences: 1. The user can decide how to manage logs in an easier way, so there's no way that we run out of disk (an issue we were having). 2. supervisor is no longer needed. Instead, we take advantage of the compose-setup.sh script to do it properly. Before this patch, for some reason the catalog job did not reach the db container. Fixes SUSE#479 Fixes SUSE#505 Signed-off-by: Miquel Sabaté Solà <msabate@suse.com>
mssola
added a commit
that referenced
this issue
Dec 21, 2015
Before this commit, the crono job kept on adding the log into the `log` column from the `crono_jobs` table. This is, of course, a bad thing. What I did to fix this is to simply remove this columns from the DB, and crono is ok with that. Running crono again with this patch runs in the very same way as it used to be, but without adding the log all the time. Moreover, the log is supposed to go to the stdout, as envisioned by the Twelve-Factor App manifesto: http://12factor.net. Docker follows this too, and by doing so then the log of this job blends in with docker-compose logs command. This has two main consequences: 1. The user can decide how to manage logs in an easier way, so there's no way that we run out of disk (an issue we were having). 2. supervisor is no longer needed. Instead, we take advantage of the compose-setup.sh script to do it properly. Before this patch, for some reason the catalog job did not reach the db container. Fixes #479 Fixes #505 Signed-off-by: Miquel Sabaté Solà <msabate@suse.com>
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Got the following Error when in production mode? Also the CatalogJob gets executed every 10 seconds? Don't know why? I thought i can set this value via ENV variable CATALOG_CRON
The text was updated successfully, but these errors were encountered: