Difference: ProductionProcedures (88 vs. 89)

Revision 892015-02-11 - AndrewMcNab

Line: 1 to 1
 
META TOPICPARENT name="LHCbComputing"

LHCb Production Operations Procedures

Line: 34 to 36
  Status = InActive } }
Changed:
<
<
} to desactivate the LFC checking.

>
>
}
 
Changed:
<
<

Building,Deploying & Installing LHCbDirac (and Core Software)

>
>
to desactivate the LFC checking.

Building,Deploying & Installing LHCbDirac (and Core Software)

 

Building the DIRAC binary distributions

Line: 62 to 66
 If you see an error message like "Warning : Cannot add voms attribute /lhcb/Role=user to proxy Accessing data in the grid storage from the user interface will not be possible. The grid jobs will not be affected." then try doing chmod 644 $DIRAC_VOMSES/lhcb-voms.cern.ch. You will also need to set $X509_CERT_DIR and X509_VOMS_DIR. Refer to lxplus for default settings, or take a look at the Dirac tool dirac-admin-get-CAs available in Diracs later than v4r19. However you do it, if you make a local copy of these two directories, you will need to keep that copy up-to-date. -- WillReece - 2009-10-06

"user guide" on how to take advantage of the CMT setup of LHCbDirac

Changed:
<
<
Summary of commands to be used for taking advantage of the LHCbDirac installation using CMT.

>
>
Summary of commands to be used for taking advantage of the LHCbDirac installation using CMT.

 

Deployment of LHCb Software on the Grid

Line: 72 to 77
 

Primary job states in DIRAC

Changed:
<
<
dirac-primary-states
>
>
dirac-primary-states
 

Job Management Operations

Line: 80 to 85
  The procedure for search string in output for selected jobs (suitable for Grid Shifters and Grid Experts).
Changed:
<
<
A low level investigation on LSF to check why LHCb jobs do not start at CERN.
>
>
A low level investigation on LSF to check why LHCb jobs do not start at CERN.
 

Running Jobs Locally With DIRAC

Added:
>
>
 There are three submission modes associated with DIRAC: default WMS submission, local execution of a workflow and finally execution of a workflow in the full agent machinery. This procedure explains the steps for running jobs locally with DIRAC.

Production management

Line: 148 to 156
 

Pilots monitor

If jobs are not being submitted for a long time, you can check first of all if pilots are submitted, and then if they are actually matched. First, you can look in the portal in the "Pilot monitor" page, to see if there pilots running or submitted. Then, with the command

Deleted:
<
<
 
dirac-admin-get-job-pilots jobID
Changed:
<
<
you check if pilots are submitted, for you job queue. This will print the logs for the pilots in the queue. If you don't see a line with
'Status': 'Submitted'
then it might be that there is a problem.
>
>
you check if pilots are submitted, for you job queue. This will print the logs for the pilots in the queue. If you don't see a line with

'Status': 'Submitted'

then it might be that there is a problem.

  Also, through the pilot monitor page you can see the pilot output for the "done" pilots, that can contain useful information of why the pilots might not be matched.
Line: 178 to 189
 Query OK, 1 row affected (0.02 sec)

mysql> select * from BkQueries where BkQueryID = 7590 ;

Changed:
<
<
Empty set (0.00 sec)
>
>
Empty set (0.00 sec)
 
      • Delete Additional Parameter from Production
mysql> select * from AdditionalParameters where TransformationID = 16309 and ParameterName = "BkQueryID" ;
Line: 194 to 206
 Query OK, 1 row affected (0.01 sec)

mysql> select * from AdditionalParameters where TransformationID = 16309 and ParameterName = "BkQueryID" ;

Changed:
<
<
Empty set (0.00 sec)
>
>
Empty set (0.00 sec)
 
  • Add the needed files to the production via the script below, provide production ID, run number and list of files (Certificate role needs to be lhcb_prod)
transID = 16310
Line: 214 to 225
  raise Exception, res['Message'] res = tsClient.addTransformationRunFiles( transID, run, sortList( listOfFiles ) ) if not res['OK']:
Changed:
<
<
raise Exception, res['Message']
>
>
raise Exception, res['Message']
 

Dealing with gaudi applications commands

Line: 224 to 234
 For what regards install_project.py:
Changed:
<
<
Operations->LHCb-Production->GaudiExecution->installProjectOptions
>
>
Operations->LHCb-Production->GaudiExecution->installProjectOptions
  can be used for setting the flags of install project, when really installing the project. I remind you that this action is triggered only if the project is not (yet) installed. If such option is not set, the default is to run install_project.py with "-b" flag.

Instead, the option

Changed:
<
<
Operations->LHCb-Production->GaudiExecution->checkProjectOptions
>
>
Operations->LHCb-Production->GaudiExecution->checkProjectOptions
  can be used for setting possible flags for checking if the project is already installed. This is done running with the default flags "-b --check". In case you want to override such behavior, by setting this option in the CS, do not forget to always add at least "--check".

The option

Changed:
<
<
Operations->LHCb-Production->GaudiExecution->removalProjectOptions
>
>
Operations->LHCb-Production->GaudiExecution->removalProjectOptions
  is instead for removing application. It's by default '-r'.

It is also possible to modify the install_project location (the script is downloaded from the web server), setting:

Changed:
<
<
Operations->LHCb-Production->GaudiExecution->install_project_location
>
>
Operations->LHCb-Production->GaudiExecution->install_project_location
  which, by default, points at http://lhcbproject.web.cern.ch/lhcbproject/dist/
Line: 260 to 267
 

Transfer PIT - CASTOR

Changed:
<
<
The Data transfer betwen the PIT and CASTOR for the RAW is handle on the machine lbdirac.cern.ch by the user lhcbprod. The dirac installation is done under /sw/dirac/data-taking. The transfer itself is managed by the Agent /sw/dirac/data-taking/startup/DataManagement_transferAgent. This python process should run MaxProcess processes and each process can start a new process for each transfer (MaxProcess can be found in /sw/dirac/data-taking/etc/DataManagement_TransferAgent.cfg). If you don't see too many processes, you can look at the log /sw/dirac/data-taking/DataManagement_TransferAgent/log/current. A typical behaviour can be seen here.
>
>
The Data transfer betwen the PIT and CASTOR for the RAW is handle on the machine lbdirac.cern.ch by the user lhcbprod. The dirac installation is done under /sw/dirac/data-taking. The transfer itself is managed by the Agent /sw/dirac/data-taking/startup/DataManagement_transferAgent. This python process should run MaxProcess processes and each process can start a new process for each transfer (MaxProcess can be found in /sw/dirac/data-taking/etc/DataManagement_TransferAgent.cfg). If you don't see too many processes, you can look at the log /sw/dirac/data-taking/DataManagement_TransferAgent/log/current. A typical behaviour can be seen here.
  You can also look at this web page to spot a potentiel problem if you see that the rate decrease. In principle in normal condition of data taking period, it means that one or several processes are stuck. you can find them with strace -f -pid _PID_. As soon as you find it you can kill it kill -9 _PID_. If it has no effect, you can stop the agent in a proper way touch /sw/dirac/data-taking/control/DataManagement/TransferAgent/stop_agent. If it does not produce any effect, you can finnalyy try runsvctrl t /sw/dirac/data-taking/startup/DataManagement_TransferAgent. As last resort, you will have to kill it by hand kill -9 _PID_
Line: 282 to 291
 

How to recover replicas that are lost even if SRM reports they are existing

Added:
>
>
 This can happen. The file is physically lost but SRM (lcg-ls) reports the file is there, see this GGUS. This replica is totally lost from tape and disk:
Changed:
<
<
 > lcg-ls -l srm://gridka-dCache.fzk.de/pnfs/gridka.de/lhcb/data/2011/RAW/FULL/LHCb/COLLISION11/98298/098298_0000000077.raw

>
>
 > lcg-ls -l srm://gridka-dCache.fzk.de/pnfs/gridka.de/lhcb/data/2011/RAW/FULL/LHCb/COLLISION11/98298/098298_0000000077.raw

 -rw-r--r-- 1 2 2 3145768992 NEARLINE /pnfs/gridka.de/lhcb/data/2011/RAW/FULL/LHCb/COLLISION11/98298/098298_0000000077.raw * Checksum: 51e2fc3d (adler32) * Space tokens: 39930230
Line: 289 to 298
  * Checksum: 51e2fc3d (adler32) * Space tokens: 39930230
Added:
>
>
 You have then to remove the lost replicas and then copy them over again from other another site:
Changed:
<
<
$ dirac-dms-remove-lfn-replica /lhcb/data/2011/RAW/FULL/LHCb/COLLISION11/98298/098298_0000000077.raw GRIDKA-RAW

>
>
$ dirac-dms-remove-lfn-replica /lhcb/data/2011/RAW/FULL/LHCb/COLLISION11/98298/098298_0000000077.raw GRIDKA-RAW

 $ dirac-dms-replicate-lfn /lhcb/data/2011/RAW/FULL/LHCb/COLLISION11/98298/098298_0000000077.raw GRIDKA-RAW
Added:
>
>
If there is only one replica and the corresponding file at the site has been lost completely, then you need to use dirac-dms-remove-files to remove the entry in the replica catalogue. You need to double check this is really the case, as this command will remove all replicas of the given file!
 

Changing the Default Protocols List for a given Site (Tier-1)

The order of the list of protocols supplied to SRM can be changed e.g. testing root at NIKHEF means root is prepended to the list. This guide explains how to change the protocols list for a given site. This operation is restricted to those with the diracAdmin role. (Grid Experts)

Line: 305 to 316
  Example to ban all the SEs at RAL in writing.
Changed:
<
<
dirac-admin-ban-se -c RAL.uk
>
>
dirac-admin-ban-se -c RAL.uk
  Example to ban one SE at RAL
Changed:
<
<
dirac-admin-ban-se RAL-DST
>
>
dirac-admin-ban-se RAL-DST
  Example to ban one SE in writing at CNAF
Changed:
<
<
dirac-admin-ban-se -w CNAF-USER
>
>
dirac-admin-ban-se -w CNAF-USER
  Also keep in mind that NIKHEF and SARA have different SE. LCG.NIKHEF.nl SE are:
Line: 350 to 358
 The following is a simple description of the replacement for genCatalog in DIRAC3. This uses the standard LHCb input data resolution policy to obtain access URLs.

Determining Versions of LCG Utils, GFAL and the Default SRM2 Protocols List in DIRAC

Changed:
<
<
There is a simple non-intrusive script to obtain the external package versions in DIRAC (Grid Shifters and Grid Experts)
>
>
There is a simple non-intrusive script to obtain the external package versions in DIRAC (Grid Shifters and Grid Experts)
 

Checking the throughput from the pit to Castor (during data taking)

Added:
>
>
 The link band-with is 10GBit. Expected rate (beginning of 2012) is about 280 MB/s, some more details here.

DIRAC Configuration Service

Line: 367 to 376
 

Getting information from BDII

Changed:
<
<

DIRAC (and not) Services monitoring

>
>

DIRAC (and not) Services monitoring

 

Getting the List of Ports For DIRAC Central Services (and how to ping them)

The ports for DIRAC central services for a given setup can easily be checked (useful for hardware requests). The procedure for port discovery as well as how to ping a service is available (Grid Shifters and Grid Experts).

SLS sensors

GridMap Overview

Changed:
<
<

CERN Core Services monitoring


>
>

CERN Core Services monitoring

 
Changed:
<
<

Sites Management

>
>

Sites Management

 

Banning and allowing sites

  • When to ban a site.
Changed:
<
<

Sites rank: Unspecified Grid Resources Error....

>
>

Sites rank: Unspecified Grid Resources Error....

 
  • In this Rank procedure some guidelines to debug understand why a site is not running payload.

Site Availability Monitoring (SAM) tests

Line: 400 to 409
  If many jobs start to fail at a site they should be immediately investigated.

SQLlite hint

Changed:
<
<
The following SQLlite is meant to provide a template description to feed a GGUS requests of investigation about one of the most recurrent problems.

>
>
The following SQLlite is meant to provide a template description to feed a GGUS requests of investigation about one of the most recurrent problems.

 

Site Problems Follow up

Deleted:
<
<
Grid jobs (=pilot jobs in DIRAC terminology) are often failing. In this link an encyclopedic summary of all known issues concerning (mainly) grid jobs issues is reported
 
Changed:
<
<

Getting in touch with sites: Tickets and Mails

How to deal with GGUS follows

GGUS

>
>
Grid jobs (=pilot jobs in DIRAC terminology) are often failing. In this link an encyclopedic summary of all known issues concerning (mainly) grid jobs issues is reported
 
Changed:
<
<

In this practice-guide we aim to provide few clear rules to the operators/GEOCs/experts to submit GGUS tickets and a quick introduction to the ticketing system. In Grid a problem is not a problem if a GGUS has not been open. With that clear in mind we wanto to present and analyze the best way to submit a GGUS ticket to a site (for a site specific problem). In the early days there was the mail as unique tool to contact sites. It was quick and also efficient. GGUS ticketing system came in the game bringing much more functionality but also a less fast way to get in touch with sites. While indeed it was a good tool to track problems and also to accumulate know-how about problems, the path of the ticket was not always straight to the experts that had to fix the problem on the remote sites. We noticed (years of experience) that a ticket GGUS + direct mail to support mailing list at the site wss the most efficient and quick way to get in touch with the site. The responsiveness increases if a LHCb local T1 contact person was also put in the loop. (please note that contact mailing address for T1s are available at https://twiki.cern.ch/twiki/bin/view/LHCb/ProductionProcedures#Mailing_lists )
The recent releases of GGUS introduced new features that matched both the need for a quick contact with sites in a old mail fashion and the robustness typical of a ticketing system. More in details together with the usual USER ticket GGUS is offering the possibility to submit both TEAM tickets and ALARM tickets.
>
>

Getting in touch with sites: Tickets and Mails

How to deal with GGUS follows

GGUS


In this practice-guide we aim to provide few clear rules to the operators/GEOCs/experts to submit GGUS tickets and a quick introduction to the ticketing system. In Grid a problem is not a problem if a GGUS has not been open. With that clear in mind we wanto to present and analyze the best way to submit a GGUS ticket to a site (for a site specific problem). In the early days there was the mail as unique tool to contact sites. It was quick and also efficient. GGUS ticketing system came in the game bringing much more functionality but also a less fast way to get in touch with sites. While indeed it was a good tool to track problems and also to accumulate know-how about problems, the path of the ticket was not always straight to the experts that had to fix the problem on the remote sites. We noticed (years of experience) that a ticket GGUS + direct mail to support mailing list at the site wss the most efficient and quick way to get in touch with the site. The responsiveness increases if a LHCb local T1 contact person was also put in the loop. (please note that contact mailing address for T1s are available at https://twiki.cern.ch/twiki/bin/view/LHCb/ProductionProcedures#Mailing_lists )
The recent releases of GGUS introduced new features that matched both the need for a quick contact with sites in a old mail fashion and the robustness typical of a ticketing system. More in details together with the usual USER ticket GGUS is offering the possibility to submit both TEAM tickets and ALARM tickets.

 
  • A TEAM ticket is a special ticket that matters production activities and is targetted to problems at sites that have to be followed by a crew as a whole rather than a single person (ex. production team).Any problem at every each site that everyone in the operations team is potentially demanded to follow and intervene, must be spawned via a TEAM ticket. A TEAM ticket either can allow for a direct routing of the problem to the site (in which case the submitter must put from a drop-down menu the GOC name of the site affected) or can go through the usual path TPM/ROC/SITE with the unavoidable lost of time. A TEAM ticket is not a top priority ticket. Submitter has the possibility to select the severity from the web form. The only difference is that everybody in the same TEAM could modify and interact with the ticket that is owned by the TEAM and not the user. GGUS knows about the meber of the TEAM via VOMS. All people entitled to dress the Role=production (now) or Role=team (coming soon) are part of the TEAM and recognize to act on the ticket.
Changed:
<
<
  • An ALARM ticket is another special ticket that is meant really to generate ALARMs on the interested sites. The implementation of the ALARM at site level is different and different the support each site decided to put in place. Mails to special site mailing list (alarming mailing list) internally on the site, might in turn trigger procedures to react quickly to a problem even outside working hour. SMS, phone calls, operators, control rooms, remedy tickets...Everything is left behind the scenes.T1's, as per MoU, are demanded to react in less than 30 minutes, 24X7 to ALARM tickets. What matters here is: VOs are guaranteed to have a answer in at least 30 minutes but the solution is not necessarily guaranteed in such short time! Only a very well restricted number of people inside the VO (read: alarmers) are entitled to submit ALARM tickets. This limitation is clearly a need to avoid that non-experts had the possibility to wake up someone else for a fake problems. Soon GGUS will retrieve authorized alarmers from VOMS (Role=alarm). A list of authorized ALARMERS for LHCb is today available here.
>
>
  • An ALARM ticket is another special ticket that is meant really to generate ALARMs on the interested sites. The implementation of the ALARM at site level is different and different the support each site decided to put in place. Mails to special site mailing list (alarming mailing list) internally on the site, might in turn trigger procedures to react quickly to a problem even outside working hour. SMS, phone calls, operators, control rooms, remedy tickets...Everything is left behind the scenes.T1's, as per MoU, are demanded to react in less than 30 minutes, 24X7 to ALARM tickets. What matters here is: VOs are guaranteed to have a answer in at least 30 minutes but the solution is not necessarily guaranteed in such short time! Only a very well restricted number of people inside the VO (read: alarmers) are entitled to submit ALARM tickets. This limitation is clearly a need to avoid that non-experts had the possibility to wake up someone else for a fake problems. Soon GGUS will retrieve authorized alarmers from VOMS (Role=alarm). A list of authorized ALARMERS for LHCb is today available here.
  Would you please mind that - despite those new tools are extremely useful and important we warmly recommend to not abusing about them. The net effect indeed is a lost of credibility that would relax the ALARM threshold. I propose below some suggestions about typical problems and action to be taken.
Changed:
<
<
  1. If the problem is a show stopper the shifter has to call the GEOC. The Experts has then to investigate whether the problem is really a show stopper and in case submit the ALARM. A show stopper here is mainly a problem that prevents to continue with the activity on the site.In the GGUS portal for ALARM ticket, there is available a list of identified MoU activities that may give origin to an alarm. It's worth to remind however that at CERN a show stopper only matters data. When submitting please put in cc also lhcb-grid@cernNOSPAMPLEASE.ch mailing list and open an entry in the e-logbook
>
>
  1. If the problem is a show stopper the shifter has to call the GEOC. The Experts has then to investigate whether the problem is really a show stopper and in case submit the ALARM. A show stopper here is mainly a problem that prevents to continue with the activity on the site.In the GGUS portal for ALARM ticket, there is available a list of identified MoU activities that may give origin to an alarm. It's worth to remind however that at CERN a show stopper only matters data. When submitting please put in cc also lhcb-grid@cernNOSPAMPLEASE.ch mailing list and open an entry in the e-logbook
 
  1. If the problem affects severely one of the services at T1's and compromises one of the activities on the site, a TEAM ticket with "Top Priority" or "Very Urgent" is recommended. We leave up to the GEOC to decide but also an entry in the e-logbook must be filed.
Changed:
<
<
  1. If the problem interests the production activity at other sites the GEOC or the shifter must open a TEAM ticket with a severity that ranges from "Less Urgent" to "Top Priority" depending on how the problem impacts the (T2) site. If just few jobs have problems and the rest is running happily (let's say less than 10%) it may be just a (few) WN problem (Less Urgent). If the site is acting as a black hole and compromise also the activities somewhere else by attracting and failing jobs that otherwise may reach other sites, the site must be banned and the TEAM ticket deserves a Top Priority level.
  2. Normal users can also get in touch with sites via Standard ticket. Severity is again matter of personal feelings. We discourage however to always think "my problem is always more important than any other else". In WLCG soon 5K users will start doing their activities.
>
>
  1. If the problem interests the production activity at other sites the GEOC or the shifter must open a TEAM ticket with a severity that ranges from "Less Urgent" to "Top Priority" depending on how the problem impacts the (T2) site. If just few jobs have problems and the rest is running happily (let's say less than 10%) it may be just a (few) WN problem (Less Urgent). If the site is acting as a black hole and compromise also the activities somewhere else by attracting and failing jobs that otherwise may reach other sites, the site must be banned and the TEAM ticket deserves a Top Priority level.
  2. Normal users can also get in touch with sites via Standard ticket. Severity is again matter of personal feelings. We discourage however to always think "my problem is always more important than any other else". In WLCG soon 5K users will start doing their activities.
  Ticket escalation:
Deleted:
<
<
 
Changed:
<
<
Since Jan 21st GGUS allows for an escalation of ticket slowly taken by the support units or unresponsive sites. Please read this escalation procedure document.
>
>
Since Jan 21st GGUS allows for an escalation of ticket slowly taken by the support units or unresponsive sites. Please read this escalation procedure document.
 
Changed:
<
<

Site Mail contacts

WLCG "conventional" site-support mailing list are available here.

>
>

Site Mail contacts

WLCG "conventional" site-support mailing list are available here.

 

Daily Shifter Checklist

Line: 488 to 497
 OK BAD MAYBE
Changed:
<
<
Usage: dirac-bookkeeping-setdataquality-run.py
>
>
Usage: dirac-bookkeeping-setdataquality-run.py
 
  • The following commands you can use to set the data quality flag:
Line: 503 to 511
 OK BAD MAYBE
Changed:
<
<
Usage: dirac-bookkeeping-setdataquality-run.py The data quality flag is case sensitive. Set data quality a given run:
>
>
Usage: dirac-bookkeeping-setdataquality-run.py

The data quality flag is case sensitive. Set data quality a given run:

 (DIRAC3-user) zmathe@pclhcb43 /scratch/zmathe/dirac[408]>dirac-bookkeeping-setdataquality-run 20716 'BAD' Quality flag has been updated!
Changed:
<
<
(DIRAC3-user) zmathe@pclhcb43 /scratch/zmathe/dirac[409]>
>
>
(DIRAC3-user) zmathe@pclhcb43 /scratch/zmathe/dirac[409]>
  dirac-bookkeeping-setdataquality-files
Line: 517 to 527
 (DIRAC3-user) zmathe@pclhcb43 /scratch/zmathe/dirac[413]> dirac-bookkeeping-setdataquality-files /lhcb/data/2009/RAW/EXPRESS/FEST/FEST/44026/044026_0000000002.raw 'BAD' ['/lhcb/data/2009/RAW/EXPRESS/FEST/FEST/44026/044026_0000000002.raw'] Quality flag updated!
Changed:
<
<
(DIRAC3-user) zmathe@pclhcb43 /scratch/zmathe/dirac[414]>
>
>
(DIRAC3-user) zmathe@pclhcb43 /scratch/zmathe/dirac[414]>
  Set the quality flag a list of file:
Line: 526 to 535
 (DIRAC3-user) zmathe@pclhcb43 /scratch/zmathe/dirac[416]> dirac-bookkeeping-setdataquality-files lfns.txt 'BAD' ['/lhcb/data/2009/RAW/EXPRESS/FEST/FEST/44026/044026_0000000002.raw', '/lhcb/data/2009/RAW/EXPRESS/FEST/FEST/43998/043998_0000000002.raw', '/lhcb/data/2009/RAW/EXPRESS/FEST/FEST/43995/043995_0000000002.raw', '/lhcb/data/2009/RAW/EXPRESS/FEST/FEST/43994/043994_0000000002.raw', '/lhcb/data/2009/RAW/EXPRESS/FEST/FEST/43993/043993_0000000002.raw', '/lhcb/data/2009/RAW/EXPRESS/FEST/FEST/43992/043992_0000000002.raw', '/lhcb/data/2009/RAW/EXPRESS/FEST/FEST/43989/043989_0000000002.raw', '/lhcb/data/2009/RAW/EXPRESS/FEST/FEST/43987/043987_0000000002.raw'] Quality flag updated!
Changed:
<
<
(DIRAC3-user) zmathe@pclhcb43 /scratch/zmathe/dirac[417]> The lfns.txt contains the following:
>
>
(DIRAC3-user) zmathe@pclhcb43 /scratch/zmathe/dirac[417]>

The lfns.txt contains the following:

 /lhcb/data/2009/RAW/EXPRESS/FEST/FEST/44026/044026_0000000002.raw /lhcb/data/2009/RAW/EXPRESS/FEST/FEST/43998/043998_0000000002.raw /lhcb/data/2009/RAW/EXPRESS/FEST/FEST/43995/043995_0000000002.raw
Line: 536 to 548
 /lhcb/data/2009/RAW/EXPRESS/FEST/FEST/43992/043992_0000000002.raw /lhcb/data/2009/RAW/EXPRESS/FEST/FEST/43989/043989_0000000002.raw /lhcb/data/2009/RAW/EXPRESS/FEST/FEST/43987/043987_0000000002.raw
Changed:
<
<
lfns.txt (END)
>
>
lfns.txt (END)
 

Web portal

Web portal stuck: how to restart it

First try to restart the Paster with runit:

Changed:
<
<
runsvctrl t runit/Web/Paster

>
>
runsvctrl t runit/Web/Paster

 
Deleted:
<
<
if this is not enough, then it will be necessary to get all Paster processes ('ps faux | grep -i web_paster') and do a 'kill -9' of them.
 
Added:
>
>
if this is not enough, then it will be necessary to get all Paster processes ('ps faux | grep -i web_paster') and do a 'kill -9' of them.
 

Documents

 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright & 2008-2019 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback