| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Dangling symlinks in path components return -ENOENT. Do not retry
to create the file in a loop in such case.
|
|
commands
The previous patch was almost, but not quite, correct. Rather than
restoring the signal mask it actually tried to make an even more
restrictive signal mask (had SIGALRM been blocked when udevd started,
anyway).
Fix it harder.
Signed-off-by: Scott James Remnant <scott@ubuntu.com>
|
|
I'm not sure how likely it is for UTIL_PATH_SIZE to have an odd value
(maybe it has right now? :-), but I guess making this universally correct
doesn't hurt ...
|
|
|
|
External programs triggered by events (via RUN=) will inherit udev's
signal mask, which is set to block all but SIGALRM. For most utilities,
this is OK, but if we start daemons from RUN=, we run into trouble
(especially as SIGCHLD is blocked).
This change saves the original sigmask when udev starts, and restores it
just before we exec() the external command.
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
|
|
|
|
|
|
Based on a patch from: Florian Zumbiehl <florz@florz.de>
|
|
|
|
|
|
Suggested by Florian Zumbiehl <florz@florz.de>.
|
|
On Mon, Aug 24, 2009 at 19:50, Lennart Poettering<lennart@poettering.net> wrote:
> One little comment here: on POSIX getrnam_r() doesn't touch
> errno. Instead it returns the error value as return value.
|
|
Fix spelling in docbook comments, code comments, and a local variable
name. Thanks to "ispell -h" for docbook HTML and "scspell" for source
code.
Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
|
|
|
|
I have recently been getting the above message on fc11 and
I have traced it down to a bug in util_lookup_group.
As of 145 util_lookup_group reads:
gid_t util_lookup_group(struct udev *udev, const char *group)
{
char *endptr;
int buflen = sysconf(_SC_GETGR_R_SIZE_MAX);
char buf[buflen];
struct group grbuf;
struct group *gr;
gid_t gid = 0;
if (strcmp(group, "root") == 0)
return 0;
gid = strtoul(group, &endptr, 10);
if (endptr[0] == '\0')
return gid;
errno = 0;
getgrnam_r(group, &grbuf, buf, buflen, &gr);
if (gr != NULL)
return gr->gr_gid;
if (errno == 0 || errno == ENOENT || errno == ESRCH)
err(udev, "specified group '%s' unknown\n", group);
else
err(udev, "error resolving group '%s': %m\n", group);
return 0;
}
The errno value from getgrnam_r here is ERANGE which is documented as
"Insufficient buffer space supplied".
When I call get getgrnam_r with a large enough buffer everything
works. Indicating that the problem is that sysconf is returning
a value too small.
A quick google search tells me that sysconf(_S_GETGR_R_SIZE_MAX)
is documented as:
> sysconf(_S_GETGR_R_SIZE_MAX) returns either -1 or a good
> suggested starting value for buflen. It does not return the
> worst case possible for buflen.
In my case I have a group with about 50 users in /etc/group
and that is what triggered the problem in udev and caused
all of the udevs group lookups to fail.
The following patch which dynamically allocates the group member buffer
should fix this problem.
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
|
|
|
|
Persistent network rules write out new rules files. When rules change,
we need to kill all workers to update the in-memory copy of the rules.
We need to make sure, that a worker finshes its work for all device
messages it has accepted, before it exits after a SIGTERM from the main
process.
|
|
|
|
|
|
|
