Project

General

Profile

Feature #17570

Need a mechanism to block consecutive invocations of SL7 init reload command

Added by HyunWoo Kim about 2 years ago. Updated almost 2 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
-
Target version:
Start date:
08/23/2017
Due date:
% Done:

0%

Estimated time:
Stakeholders:

Factory operations

Duration:

Description

systemctl reload is non-blocking, namely, when we issue systemctl reload command,
it returns immediately while the reload is still in progress.
This opens a possibility we can issue a second reload command while the first is still in progress.
We need a mechanism to prevent this sort of situation.

History

#1 Updated by HyunWoo Kim about 2 years ago

I started working on creating a new lock that will prevent a second invocation of the reload.
For this, I am both looking into the possibility of inheriting pidSupport and also creating a new simple lockSupport.

#2 Updated by HyunWoo Kim about 2 years ago

  • Status changed from Assigned to Work in progress

Modified two files, creation/reconfig_frontend and frontend/glideinFrontend.py
and added a new file lib/lockSupport.py
in order to implement a block in a non-blocking reload call in Sl7 init.

All code changes are in v3/17570.

Current tests seem to work.
I will have to make lib/lockSupport.py more sophisticated.

How can    I sophisticate lockSupport?
For this, I first need to refine or polish what will be requirements for this    component?

1. this thing is independent of the main pid in /var/lib/gwms-frontend/vofrontend/lock/frontend.lock
2. this thing is solely and merely needed during the duration of a reload process..

this means
- I can just pick a unique name e.g. /tmp/frontend_reload_lock
- I just need to make sure this file does not exist when the system(frontend or factory) starts
- and this file is created only when the following set of codes are executed
  + signal.signal(signal.SIGHUP,  hupsignal)
  + def hupsignal(signr, frame): raise HUPException, "Received signal %s" % signr
  + except HUPException: signal.signal( signal.SIGHUP,  signal.SIG_IGN )
   os.execv( "creation/reconfig_frontend", ['reconfig_frontend', '-sighupreload', '-xml', '/etc/gwms-frontend/frontend.xml'] )
- and this file is destroyed right before the execution return from reconfig_frontend to glideinFrontend.py
  if sighupreload:
     mylock = lockSupport.LockSupport()
     mylock.delete()
     os.execv( os.path.join(FRONTEND_DIR, "glideinFrontend.py"), ['glideinFrontend', '/var/lib/gwms-frontend/vofrontend'] )

Wait..

I just realized that I might NOT need this lockSupport altogether,
i.e. this only thing that I need would be

except HUPException:
      signal.signal( signal.SIGHUP,  signal.SIG_IGN )

The purpose of this lines is in order to invoke
raise HUPException, "Received signal %s" % signr
only the first time, i.e. when the mylock does not exist.

def hupsignal(signr, frame):
    mylock = lockSupport.LockSupport()
    if mylock.check():
        print "doing nothing" 
    else:
        mylock.create()
        raise HUPException, "Received signal %s" % signr

But my initial tests claim that this structure alone does not completely block the redundant invocations of kill -SIGHUP.

I might need both mylock and
      signal.signal( signal.SIGHUP,  signal.SIG_IGN )

#3 Updated by HyunWoo Kim almost 2 years ago

  • Status changed from Work in progress to Feedback
  • Assignee changed from HyunWoo Kim to Dennis Box

#4 Updated by Marco Mambelli almost 2 years ago

  • Status changed from Feedback to Resolved
  • Target version changed from v3_2_21 to v3_2_20

Added to 3.2.20 since ready and tested.

#5 Updated by Marco Mambelli almost 2 years ago

  • Status changed from Resolved to Closed

#6 Updated by Parag Mhashilkar almost 2 years ago

  • Stakeholders updated (diff)


Also available in: Atom PDF