Lines Matching refs:it

22 from processing rules on it — and thus bar it from probing the device — by
24 `systemd-udevd` starts processing a block device it takes a `LOCK_SH|LOCK_NB`
28 returns `EAGAIN`), it refrains from processing the device. If it manages to take
29 the lock it is kept for the entire time the device is processed.
31 Note that `systemd-udevd` also watches all block device nodes it manages for
38 take an `LOCK_EX` lock on it. This has two effects: first of all, in case
39 `systemd-udevd` is still processing the device the tool will wait for it to
40 finish. Second, after the lock is taken, it can be sure that `systemd-udevd`
42 applications subscribed to it won't get device notifications from potentially
45 it implicitly releases the lock, so that `systemd-udevd` can process events on
46 the device node again. Secondly, it results an `IN_CLOSE_WRITE` event, which
48 changes the tool made — and notify subscribed clients about it.
52 is why it watches for `IN_CLOSE_WRITE` instead, i.e. for `close()` calls to
55 taken are implicitly released by `close()`. However, it should be noted that if
56 an application unlocks a device after completing its work without closing it,
68 `systemd-udevd` never writes to such block devices it only takes a `LOCK_SH`
87 during normal operation, i.e. while file systems on it are mounted for
93 for the use in scripts and similar. (Note though that it's typically preferable
97 Summarizing: it is recommended to take `LOCK_EX` BSD file locks when