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