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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Since gtk-mkhtml is executed in a sub-directory of the build directory, and
make does not know of that, the $(buildir) variable will still be "." and
the $(srcdir) will not properly be found. For this reason, use the absolute
variants for the two functions, which won't be changing.
Instead of using multiple recursive Makefile.am files, use a single
Makefile.am that sets and builds all the basic suite of libraries and
binaries for udev. This reduces the number of files in the source tree, and
also reduces drastically the build time when using parallel-make.
With this setup, all the compile steps will be executed in parallel, and
just the linking stage will be (partially) serialised on the libraries
creation.
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>
Generally ALSA control devices should be the last ones to be processed
for ACL changes and similar operations because they can then be used as
indicators that ACL management finished for all device nodes of a
specific card.
This patch simple moves each controlC device behind all the pcmC devices
(and similar).
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.
On machines with many thousands of devices:
$ time find /sys -name uevent | wc -l
74876
real 0m33.171s
user 0m3.329s
sys 0m29.719s
the current udevtrigger spends minutes sorting the device list:
$ time /sbin/udevadm trigger --dry-run
real 4m56.739s
user 4m45.743s
sys 0m7.862s
with qsort() it looks better:
$ time udev/udevadm trigger --dry-run
real 0m6.495s
user 0m0.473s
sys 0m5.923s
