Hi, i wont change something in ISPconfig control panel (server ip). Maybe I made other settings too quick and jobqueue with red bubble display since 12 hours. In "Jobqueue" menu doesn't disappear the jobs. I tried to resolve with "debug" setting etc. Can you help me?
Please post ISPConfig related questions in the ISPConfig board. I have moved your post now. https://www.howtoforge.com/community/threads/please-read-before-posting.58408/ -> ISPConfig is not writing changes to disk.
ISPconfig System log: Mon May 24 07:54:01 CEST 2021 24.05.2021-07:54 - DEBUG - Calling function 'check_phpini_changes' from plugin 'webserver_plugin' raised by action 'server_plugins_loaded'. Mon May 24 07:54:01 CEST 2021 24.05.2021-07:54 - DEBUG - Remove Lock: /usr/local/ispconfig/server/temp/.ispconfig_lock Mon May 24 07:54:01 CEST 2021 finished server.php.
According to the debug output, on the server where you run the script, there is nothing in the job queue. Is or war this a multiserver system?
yes.i've tried the debugging steps. debug on/off, ran server.sh manual, modify server/updated column. I noticed that mysql updated,but the bubble doesn't disappear and ispconfig display the jobqueue.
Alright, so that explains it. The server now thinks it's up to date while the changes are still pending. Set the updated column back to the previous value and then run the server.sh script again, with debug mode on. In the future, never change the updated column values.
I followed Till's instructions -> https://www.howtoforge.com/community/threads/ispconfig-3-job-queue-gets-stuck.83290/ I don't know anymore what was the previous value. What should I do?
What is the highest value of datalog_id in the sys_datalog table, where the status is "ok"? Set it to that. EDIT: you can find this with Code: SELECT MAX(datalog_id) FROM `sys_datalog` WHERE status = 'ok'
Other jobs (password modify,new user etc) processed succesfully. Only the server ip modify jobs stay in jobsqueue but modified in database
You could change the updated to 17614, with the "risk" that some tasks would be run again, though this should not hurt - I think. @till wdyt?
I'd guess the missing task numbers were for other servers, unless 'updated' was changed multiple times, resulting in multiple gaps in numbers.