Feature #17570

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

Added by HyunWoo Kim almost 3 years ago. Updated over 2 years ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:

Factory operations



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.


#1 Updated by HyunWoo Kim almost 3 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 almost 3 years ago

  • Status changed from Assigned to Work in progress

Modified two files, creation/reconfig_frontend and frontend/
and added a new file lib/
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/ 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
  if sighupreload:
     mylock = lockSupport.LockSupport()
     os.execv( os.path.join(FRONTEND_DIR, ""), ['glideinFrontend', '/var/lib/gwms-frontend/vofrontend'] )


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" 
        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 over 2 years ago

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

#4 Updated by Marco Mambelli over 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 over 2 years ago

  • Status changed from Resolved to Closed

#6 Updated by Parag Mhashilkar over 2 years ago

  • Stakeholders updated (diff)

Also available in: Atom PDF