Apparently if people are adventurous enought to run Go programs in udev
rules they might run into problems with MemoryDenyWriteExecute=.
I am pretty sure the best way out is for the toolchain generating
programs incompatible with W^X to be fixed, but this still deserves
documentation.
This was forgotten for the 232 release, hence add it now, retroactively.
See: #5400
As per commit 25e773e "udev: switch to systemd logging functions"
Now log_set_max_level() in udev_new() overwites system wide log level.
Propagate the udev.conf setting to log_set_max_level()
only if udev_new() is called from within udevd or one of its helpers.
Introduce a UDEV_PROPAGATE_LOG macro that we set with -D on
the gcc command line for all udev binaries we build, but not
for any others. The log_set_max_level() call is guarded by an
ifdef check for that macro, so that it only effects the various
udev binaries.
closes: #4525
If the snippet aleady exists, don't do anything, as the file was already
installed then.
(This also reworks the code to create the file atomically)
Fixes: #5396
If our netlink input buffer overruns the kernel will send us ENOBUFS on
the next recvmsg(). Don't consider this a complete failure resulting in
closing of the netlink socket. Instead, simply continue (after debug
logging).
Of course, ideally we'd have a better strategy for this, and would have
a way to resync if this happens (as well as a scheme for cancelling all
ongoing asynchronous transactions), but for now let's at least not choke
fatally, and simply accept that we lost some messages and continue.
Note that if we lose messages when synchronously waiting for an
operation to complete, we'll still propagate the ENOBUFS up, to make the
individual transaction fail.
See: #5398
(This bug does not properly fix the issue, hence we should leave the bug
open.)
