[LU-6080] Posix copytool should unregister FIFO on signal Created: 05/Jan/15  Updated: 18/Jun/15  Resolved: 15/Feb/15

Status: Resolved
Project: Lustre
Component/s: None
Affects Version/s: None
Fix Version/s: Lustre 2.7.0

Type: Bug Priority: Minor
Reporter: Bruno Faccini (Inactive) Assignee: Bruno Faccini (Inactive)
Resolution: Fixed Votes: 0
Labels: None
Environment:

All


Issue Links:
Related
Severity: 3
Rank (Obsolete): 16918

 Description   

Original text/report from J.Nemeth (SGI) :

If the ct_run() routine (copytool daemon) terminates normally, it calls llapi_hsm_unregister_event_fifo() as well as llapi_hsm_copytool_unregister(). If the daemon is terminated via signal, the signal handler calls llapi_hsm_copytool_unregister(), but does NOT call llapi_hsm_unregister_event_fifo().

This leaves the FIFO file in place, and any subsequent invocation of the copytool with -f and the same FIFO path will fail to open the FIFO file with an EEXIST error.

The signal() handler routine should call llapi_hsm_unregister_event_fifo() the same way that ct_run() does on normal termination.


 Comments   
Comment by Gerrit Updater [ 05/Jan/15 ]

Faccini Bruno (bruno.faccini@intel.com) uploaded a new patch: http://review.whamcloud.com/13236
Subject: LU-6080 utils: copytool to also unregister FIFO upon signal
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: b2d83d203f28fc5f41820455f65cdca13e9dabac

Comment by Bruno Faccini (Inactive) [ 05/Jan/15 ]

Master patch to also call llapi_hsm_unregister_event_fifo() (which closes the fifo, and also unlink it only if it has been created, as per LU-5252 specs), upon termination signal handling in handler() routine, is at http://review.whamcloud.com/13236.

Comment by Gerrit Updater [ 07/Jan/15 ]

Oleg Drokin (oleg.drokin@intel.com) merged in patch http://review.whamcloud.com/13236/
Subject: LU-6080 utils: copytool to also unregister FIFO upon signal
Project: fs/lustre-release
Branch: master
Current Patch Set:
Commit: 02121ce3e801684b4b5602a55ca313c661471df7

Generated at Sat Feb 10 01:57:02 UTC 2024 using Jira 9.4.14#940014-sha1:734e6822bbf0d45eff9af51f82432957f73aa32c.