0

There is a utility application that, when launched, creates a lock file in a specific directory. Affect the name of this file or the path - it is not possible, the utility is proprietary and is supplied without source codes. The problem is that we want to run this utility on one server in several instances, but while 1 utility does not work 1 cycle of its work, all other copies of the utility are waiting until you can create a lock file. And the more you try to "pull" this utility, the more it becomes idle processes. at the same time, creating a lock file (the fact of its presence) does not affect anything. And from here it would be desirable to mount something like nullfs - a folder in which all contents at record there and then disappeared. Clean the lock file manually after running the utility - not an option, because this is not enough for the normal operation of multiple copies - they still have time to slow down due to the presence of a lock file. Use another version or other utility is impossible for legal reasons - this is the peculiarity of the task.

Tatiana
  • 1
  • 2
  • Have you verified that actually doing what you want is safe? I mean, the original developer of this program spent time implementing a feature specifically blocking this behavior, are you sure you're not just moving the problem forward? *- "First we had a block that prevented us, we circumvented that but now we find that the log file looks corrupted, what gives?"* – Lasse V. Karlsen Sep 11 '17 at 06:25
  • Does the utility place the lock file in a user- or system-related folder, or does it place the lock file together with the program? If the latter, could you make multiple copies of the program? – Lasse V. Karlsen Sep 11 '17 at 06:25
  • The utility puts the lock file not with the program. – Tatiana Sep 11 '17 at 07:36
  • Set up multiple virtual machines to be able to run the program in parallel. – Lasse V. Karlsen Sep 11 '17 at 07:39
  • The utility consumes 30-40 megabytes of memory at startup, the task involves running about 100 copies of this utility. Raise 100 virtual machines - not enough resources and inappropriate. – Tatiana Sep 11 '17 at 08:05
  • So your question is basically: How can we circumvent this lock? Not «how to do this safely»? – Lasse V. Karlsen Sep 11 '17 at 08:18
  • The question is, do these lok files not slow down the utility's work. – Tatiana Sep 11 '17 at 08:29
  • I doubt the utility is slowed down by having this lock but **obviously** *your* task is slowed down by the lock preventing your tasks to run in parallel. Please be very specific about what the question is here. Are you asking what the effect of this lock has on the program? That's not really answerable by anyone here. Are you asking how to get the utility to drop the lock, or remove the lock from the utility, so that you can run it in parallel? That *might* be answerable. Are you asking if it is safe of you do to so? That is *probably* answerable but the answer is most likely no. Be specific! – Lasse V. Karlsen Sep 11 '17 at 10:00
  • Why do you think the lock is slowing down the utility? – Lasse V. Karlsen Sep 11 '17 at 10:00
  • The utility slows down the work due to the fact that the lock files are not being discarded. What prevents them run in parallel. – Tatiana Sep 11 '17 at 10:37
  • **Please be specific about what your *question* is!** The utility *itself* is probably not being slowed down by the lock file, the problem is that you want to run several instances of this utility in parallel. **Obviously**, since the utility waits for the ability to create its own lock, it is going to be slowed down by the lock being held by a different instance **but this seems entirely by design**. – Lasse V. Karlsen Sep 11 '17 at 10:38
  • Specifically, the author of this program has said "you cannot run multiple instances of this utility at the same time". Again, **what is your question here?** – Lasse V. Karlsen Sep 11 '17 at 10:40
  • We want to run the utility many times, while resources allow. But the utility does not give us, because of the stupid lock file, which it creates for the time of the first copy. From the security point of view, we want to disregard this, even if the work of this utility is disrupted, i.e. we take this risk – Tatiana Sep 11 '17 at 13:17
  • If you're the administrator of the system, can't you forcibly delete the lock file? – Lasse V. Karlsen Sep 11 '17 at 13:26
  • yes, but manual cleaning is not suitable. This was written at the beginning of the question. – Tatiana Sep 11 '17 at 20:11
  • So what then is the question? – Lasse V. Karlsen Sep 11 '17 at 22:07
  • It is necessary to mount something like nullfs - a folder in which all the contents of the recording immediately disappeared. It means, as a folder - analog /dev/null – Tatiana Sep 12 '17 at 07:35
  • Then clarify your question, also consider whether the question is better served on [su], since though it is related to programming, it is not really a programming question. – Lasse V. Karlsen Sep 12 '17 at 07:38

0 Answers0