IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
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.
