Feature #230

Think about wrapper script or extension for spread daemon

Added by S. Wrede over 13 years ago. Updated almost 8 years ago.

Status:NewStart date:03/20/2011
Priority:NormalDue date:
Assignee:-% Done:

50%

Category:-
Target version:Robotics Service Bus - rsb-1.0

Description

If we further use Spread we should either write a wrapper script that removes /tmp/<port> or directly add this to the spread dameon's source code.

0001-Clean-up-socket-file-on-signals.patch Magnifier (1.18 KB) J. Wienke, 02/07/2014 12:13 PM

History

#1 Updated by J. Wienke about 12 years ago

Did anyone ever contact the spread list about this?

#2 Updated by J. Moringen almost 12 years ago

  • Status changed from New to Feedback
  • Target version set to rsb-0.9

We should decide on this issue for the 0.8 version.

#3 Updated by J. Moringen over 11 years ago

Is this still necessary?

#4 Updated by J. Wienke over 11 years ago

I didn't see a case where this was necessary recently. But probably mainly because we didn't do much work on shared computers. Anyways, we should contact the spread developers about the real problem of missing clean up. It might also be solved with 4.2?

#5 Updated by S. Wrede over 11 years ago

My assumption is that they don't consider this as a serious problem as their setups probably won't feature the kind of flexible starting / stopping of daemons deployed to different nodes. But as they seemed open to patches we could ask them if it is fixed in 4.2 and propose to make a patch directly to the daemon executable?

#6 Updated by J. Wienke over 11 years ago

  • Target version changed from rsb-0.9 to rsb-0.10

#7 Updated by J. Wienke almost 11 years ago

  • Project changed from Robotics Service Bus to Packaging

We could easily solve this with our own packaging of spread. Nothing really related to the rsb core.

#8 Updated by J. Moringen over 10 years ago

  • Target version changed from rsb-0.10 to rsb-0.11

#9 Updated by J. Wienke over 10 years ago

I have created a patch against the 4.4 beta release and sent it to the mailing list. It uses a signal handler to delete this file on termination.

#10 Updated by J. Wienke over 10 years ago

Should we include this patch in our packaging independent of the upstream progress?

#11 Updated by S. Wrede over 10 years ago

Maybe we wait for the feedback from the mailing list (if we get any) to check for side effects. If there aren't any negative ones, we should include the patch.

#12 Updated by J. Moringen over 9 years ago

  • Target version changed from rsb-0.11 to rsb-0.12

#13 Updated by J. Wienke over 8 years ago

No reaction from the mailing list and the list is dead since ages. Maybe we should just add the patch to our debian patches.

#14 Updated by J. Moringen over 8 years ago

  • Target version changed from rsb-0.12 to rsb-0.14

#15 Updated by J. Moringen about 8 years ago

  • Target version changed from rsb-0.14 to rsb-0.15

#16 Updated by J. Moringen about 8 years ago

  • Target version changed from rsb-0.15 to rsb-1.0

#17 Updated by J. Wienke almost 8 years ago

  • Status changed from In Progress to New
  • Assignee deleted (J. Wienke)

Also available in: Atom PDF