Project

General

Profile

Actions

Bug #7559

closed

Mentat import pipeline running after reboot while disabled

Added by Radko Krkoš over 2 years ago. Updated 4 days ago.

Status:
Closed
Priority:
Low
Category:
Installation
Target version:
Start date:
02/15/2022
Due date:
% Done:

0%

Estimated time:
To be discussed:
No

Description

The DB upgrade procedure, as described in #7555, allows for reboot in step 9, if the circumstances require it. During execution on mentat-hub, after the reboot, the Mentat's import pipeline (the daemons) were running. No data was actually imported as the warden-filer was disabled at systemctl level (and the issue described in #7121 also surfaced).
In step 1, Mentat is stopped and disabled using mentat-controller.py, so there seems to be some inconsistency. Should those two steps actually be enough to prevent the pipeline from running?
Setting low priority as this is actually a very rare scenario.


Related issues

Related to Mentat - Feature #6928: Reconsider Mentat process managementNew01/13/2021

Actions
Blocked by Mentat - Bug #7758: Stopping mentat.service results in failure even though modules are stoppedClosedRajmund Hruška07/11/2024

Actions
Actions #1

Updated by Radko Krkoš over 2 years ago

  • Assignee set to Jan Mach
  • To be discussed changed from Yes to No

Mek, see the last question. Any ideas?

Actions #2

Updated by Radko Krkoš over 2 years ago

  • Related to Feature #6928: Reconsider Mentat process management added
Actions #3

Updated by Pavel Kácha over 2 years ago

Seems this is wanted behavior - stop stops Mentat daemons, disable stops cronjobs.

For disabling starting up after reboot, systemctl disable is needed. Would be fine to update docs.

Actions #4

Updated by Pavel Kácha 3 months ago

  • Assignee deleted (Jan Mach)
Actions #5

Updated by Rajmund Hruška 19 days ago

  • Assignee set to Rajmund Hruška
  • Target version changed from Backlog to 2.13.1

So the only thing needed here is to mention systemctl stop mentat.service in the documentation?

Actions #6

Updated by Radko Krkoš 18 days ago

Rajmund Hruška wrote in #note-5:

So the only thing needed here is to mention systemctl stop mentat.service in the documentation?

Short: That would solve the issue for this specific case. Replacing usage of mentat-controller.py with systemctl everywhere in the documentation (and in the heads of administrators ).

For discussion: I guess mentat-controller.py should be able to enable/disable or start/stop the mentat services and it should be integrated with general system management tools - ideally there should be no difference in using mentat-controller.py and systemctl. Then of course, those would be redundant interfaces. This leads us again to #6928.

Actions #7

Updated by Rajmund Hruška 16 days ago

  • Related to Bug #7758: Stopping mentat.service results in failure even though modules are stopped added
Actions #8

Updated by Rajmund Hruška 16 days ago

  • Related to deleted (Bug #7758: Stopping mentat.service results in failure even though modules are stopped)
Actions #9

Updated by Rajmund Hruška 16 days ago

  • Blocked by Bug #7758: Stopping mentat.service results in failure even though modules are stopped added
Actions #10

Updated by Rajmund Hruška 16 days ago

  • Status changed from New to Resolved
Actions #11

Updated by Rajmund Hruška 9 days ago

  • Status changed from Resolved to In Review
Actions #12

Updated by Rajmund Hruška 4 days ago

  • Status changed from In Review to Closed
Actions

Also available in: Atom PDF