On 31.12.2014 10:59, Jude Nelson wrote: Hi,
> However, future entanglements with systemd and kdbus could make this > much harder, to the point that eudev has no choice but to diverge > from udev, thereby increasing the maintenance burden considerably. yeah, sooner or later there'll need to do a full fork. we should get in contact with them (I just posted a first mail onto their maillist). > This precarious situation is one motivating factor in my creating > vdev--we must have a drop-in replacement for udev beyond the > influence of the systemd developers that's ready to go in case > maintaining eudev suddenly becomes intractable. ACK. But I'm not sure whether that has to be an 100% drop-in replacement for now. Trying to do so carries the risk of just copying bad design decisions - for example, I dont think that tools like file managers should directly call the device manager. > I have a partial solution to this, though--I've written a filesystem > called runfs [1] that has the property that once a process dies, runfs > automatically unlinks all of the files it created in it. This way, > I can start a daemon and have it write a PID file to runfs, and then > I can check to see if the daemon is still running simply by stat'ing > the PID file (it will not be present if the daemon has died). It does > not need to use cgroups to work, and programs can benefit from runfs > without knowing that they're using it :) That's an interesting approach. OTOH, what happens when runfs process dies (or needs to be restarted for some reason) ? Several years ago, I patched portmap to keep its mapping table directly within the filesystem, so it can be restarted anytime (in fact, it doesn't even need to run permanently that way - can be started on-demand via inetd and die after some idle timeout). For the PID management, we IMHO can realy on procfs, maybe just having an little deamon which cleans up stale pidfiles from time to time, before a possible PID wraparound happens. Additionally, we could also just open an socket/fifo, which will get disconnected when the opening process dies. That stuff can be easily put into an small library, with some small command line tool. cu -- Enrico Weigelt, metux IT consulting +49-151-27565287 _______________________________________________ Dng mailing list [email protected] https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
