5402 2004-10-26 17:57:58 +0400 rsync --daemon sometimes hits its own RLIMIT_NPROC=1 setting 2005-07-13 15:46:58 +0400 1 1 4 Development Sisyphus rsync-server unstable all Linux CLOSED FIXED http://lists.altlinux.ru/pipermail/sisyphus/2004-September/046369.html P2 major --- 1 svgol placeholder glebfm ldv placeholder vt qa-sisyphus oldest_to_newest 19424 0 svgol 2004-10-26 17:57:58 +0400 Разбираясь с проблемой по ссылке, обнаружил, что в альтовском пакете rsync есть такие строчки, затрагивающие resource limits: -------------------------------------------------- /* Enforce resource limits. */ rlim.rlim_cur = rlim.rlim_max = 1; if (setrlimit (RLIMIT_NPROC, &rlim)) { -------------------------------------------------- Они добавляются патчем rsync-2.6.1-alt-setrlimit.patch. Опытным путем :-) установлено, что описанная по ссылке проблема разрешается, если указать -------------------------------------------------- rlim.rlim_cur = rlim.rlim_max = 45; -------------------------------------------------- или больше, и пересобрать пакет. Поскольку без этого патча все работает, а на тестовой программке, никак с rsync не связанной, наблюдается похожая проблема (при небольших значениях RLIMIT_NPROC fork возвращает ошибку EAGAIN), то решил повесить багу на ядро. 19425 1 vsu 2004-10-26 18:44:23 +0400 Так RLIMIT_NPROC - это как раз и есть средство для ограничения количества процессов ;) Ядро в данном случае ведёт себя совершенно правильно - запрещает fork(). А вот почему rsync в данном случае собирается делать fork() - это вопрос. Вероятно, предполагалось, что для rsync --daemon будет разрешено только чтение. Перевешиваю на rsync-server. 19426 2 ldv 2004-10-26 18:52:34 +0400 Действительно, зачем ему fork? 19427 3 svgol 2004-10-26 19:44:09 +0400 (In reply to comment #2) > Действительно, зачем ему fork? Этот fork находится в main.c в функции do_recv: ------------------------------------------ if ((pid = do_fork()) == 0) { ------------------------------------------ чтобы сэкономить вам время, потому что моей квалификации на разборку с этим не хватило, а рабочий rsync очень хочется :-). 19428 4 svgol 2004-10-26 19:46:39 +0400 (In reply to comment #1) > Так RLIMIT_NPROC - это как раз и есть средство для ограничения количества > процессов ;) Но оно должно поддаваться логике :-), а какая логика в том, что если я хочу зааплоудить файлик на rsync-сервер, то это у меня не получается ровно до тех пор, пока не проставлю эту константу >= 45? Сомневаюсь, что для такой простой операции rsync не хватает 44 процессов. К тому же, я написал маленький тест rlimit.c в аттаче. Но настаивать не буду, т.к. в RLIMITах не разбираюсь :-) > Ядро в данном случае ведёт себя совершенно правильно - запрещает fork(). А вот > почему rsync в данном случае собирается делать fork() - это вопрос. Вероятно, > предполагалось, что для rsync --daemon будет разрешено только чтение. более удобная замена ftp, scp, rcp - все они умеют аплоудить и не жалуются на лимиты ;-) > Перевешиваю на rsync-server. так я тестировал и без xinetd, чтобы исключить лишнее звено. Тогда уж на rsync. 19429 5 ldv 2004-10-26 21:25:34 +0400 Логика работы rsync в разных режимах разная, возможно, что в одном из них этот rlimit устанавливать нельзя. 19430 6 svgol 2004-10-26 21:38:16 +0400 (In reply to comment #0) Бог с ним с rsync - отвлечемся на небольшую программку: ----------------------------------------------------------- #include <stdio.h> #include <sys/time.h> #include <sys/resource.h> #include <sys/types.h> #include <sys/wait.h> #include <unistd.h> #include <errno.h> extern int errno; main() { int pid; int i; int err; struct rlimit rlim; i = 40; rlim.rlim_cur = rlim.rlim_max = i; setrlimit(RLIMIT_NPROC, &rlim); if ((pid = fork()) == 0) { printf("rlimit %i -- OK\n", i); _exit(0); } else if (pid == -1) { err = errno; if (err == EAGAIN) printf("rlimit %i -- FAILED\n", i); } else waitpid(pid, NULL, WUNTRACED); } --------------------------------------------------- в этом тесте тоже не форкается при i<41. Почему? В чем причина? 19431 7 ldv 2004-10-26 21:46:53 +0400 Сергей, прочтите setrlimit(2) и не задавайте больше детских вопросов. 19445 8 619 ldv 2004-10-27 15:57:32 +0400 Created attachment 619 rsync-2.6.3-alt-setrlimit.patch Потестируйте этот патч вместо rsync-2.6.1-alt-setrlimit.patch 19456 9 svgol 2004-10-27 19:55:34 +0400 Заработало. 19464 10 ldv 2004-10-27 20:33:20 +0400 Ok, fixed in rsync-server-2.6.3-alt2 19473 11 ldv 2004-10-28 15:56:31 +0400 http://lists.altlinux.ru/pipermail/errata/2004-October/000016.html 619 2004-10-27 15:57:32 +0400 2004-10-27 15:57:32 +0400 rsync-2.6.3-alt-setrlimit.patch rsync-2.6.3-alt-setrlimit.patch text/plain 2393 ldv ZGlmZiAtdXByay5vcmlnIHJzeW5jLTIuNi4zLm9yaWcvY2xpZW50c2VydmVyLmMgcnN5bmMtMi42 LjMvY2xpZW50c2VydmVyLmMKLS0tIHJzeW5jLTIuNi4zLm9yaWcvY2xpZW50c2VydmVyLmMJMjAw NC0wNy0zMSAyMzo1NTo0MiArMDQwMAorKysgcnN5bmMtMi42LjMvY2xpZW50c2VydmVyLmMJMjAw NC0xMC0yNyAxNTo1MzoxOCArMDQwMApAQCAtMjYsNiArMjYsNyBAQAogICoqLwogCiAjaW5jbHVk ZSAicnN5bmMuaCIKKyNpbmNsdWRlIDxzeXMvcmVzb3VyY2UuaD4KIAogZXh0ZXJuIGludCBhbV9z ZW5kZXI7CiBleHRlcm4gaW50IGFtX3NlcnZlcjsKQEAgLTIwNiw2ICsyMDcsMjEgQEAgaW50IHN0 YXJ0X2luYmFuZF9leGNoYW5nZShjaGFyICp1c2VyLCBjaAogfQogCiAKK2ludCBzZXRfcmxpbWl0 X25wcm9jIChpbnQgZl9vdXQpCit7CisJc3RydWN0IHJsaW1pdCBybGltOworCisJcmxpbS5ybGlt X2N1ciA9IHJsaW0ucmxpbV9tYXggPSAxOworCWlmIChzZXRybGltaXQgKFJMSU1JVF9OUFJPQywg JnJsaW0pKQorCXsKKwkJcnN5c2VyciAoRkVSUk9SLCBlcnJubywgInNldHJsaW1pdCglZCkgZmFp bGVkIiwgUkxJTUlUX05QUk9DKTsKKwkJaWYgKGZfb3V0ID49IDApCisJCQlpb19wcmludGYgKGZf b3V0LCAiQEVSUk9SOiBzZXRybGltaXQgZmFpbGVkXG4iKTsKKwkJcmV0dXJuIC0xOworCX0KKwly ZXR1cm4gMDsKK30KKwogCiBzdGF0aWMgaW50IHJzeW5jX21vZHVsZShpbnQgZl9pbiwgaW50IGZf b3V0LCBpbnQgaSkKIHsKQEAgLTM3NSw3ICszOTEsNyBAQCBzdGF0aWMgaW50IHJzeW5jX21vZHVs ZShpbnQgZl9pbiwgaW50IGZfCiAJCX0KICNpZmRlZiBIQVZFX1NFVEdST1VQUwogCQkvKiBHZXQg cmlkIG9mIGFueSBzdXBwbGVtZW50YXJ5IGdyb3VwcyB0aGlzIHByb2Nlc3MKLQkJICogbWlnaHQg aGF2ZSBpbmhlcmlzdGVkLiAqLworCQkgKiBtaWdodCBoYXZlIGluaGVyaXRlZC4gKi8KIAkJaWYg KHNldGdyb3VwcygxLCAmZ2lkKSkgewogCQkJcnN5c2VycihGTE9HLCBlcnJubywgInNldGdyb3Vw cyBmYWlsZWQiKTsKIAkJCWlvX3ByaW50ZihmX291dCwgIkBFUlJPUjogc2V0Z3JvdXBzIGZhaWxl ZFxuIik7CkBAIC0zODksNiArNDA1LDExIEBAIHN0YXRpYyBpbnQgcnN5bmNfbW9kdWxlKGludCBm X2luLCBpbnQgZl8KIAkJCXJldHVybiAtMTsKIAkJfQogCisJCWlmIChhbV9zZW5kZXIgfHwgbHBf cmVhZF9vbmx5KG1vZHVsZV9pZCkpIHsKKwkJCWlmIChzZXRfcmxpbWl0X25wcm9jKGZfb3V0KSkK KwkJCQlyZXR1cm4gLTE7CisJCX0KKwogCQlhbV9yb290ID0gKE1ZX1VJRCgpID09IDApOwogCX0K IApkaWZmIC11cHJrLm9yaWcgcnN5bmMtMi42LjMub3JpZy9tYWluLmMgcnN5bmMtMi42LjMvbWFp bi5jCi0tLSByc3luYy0yLjYuMy5vcmlnL21haW4uYwkyMDA0LTA5LTI5IDIxOjU4OjA3ICswNDAw CisrKyByc3luYy0yLjYuMy9tYWluLmMJMjAwNC0xMC0yNyAxNTo1MzoxOCArMDQwMApAQCAtNDg3 LDYgKzQ4Nyw3IEBAIHN0YXRpYyBpbnQgZG9fcmVjdihpbnQgZl9pbixpbnQgZl9vdXQsc3QKIAkJ Y2xvc2UoZXJyb3JfcGlwZVswXSk7CiAJCWlmIChmX2luICE9IGZfb3V0KQogCQkJY2xvc2UoZl9v dXQpOworCQlmX291dCA9IC0xOwogCiAJCS8qIHdlIGNhbid0IGxldCB0d28gcHJvY2Vzc2VzIHdy aXRlIHRvIHRoZSBzb2NrZXQgYXQgb25lIHRpbWUgKi8KIAkJY2xvc2VfbXVsdGlwbGV4aW5nX291 dCgpOwpAQCAtNDk0LDYgKzQ5NSw3IEBAIHN0YXRpYyBpbnQgZG9fcmVjdihpbnQgZl9pbixpbnQg Zl9vdXQsc3QKIAkJLyogc2V0IHBsYWNlIHRvIHNlbmQgZXJyb3JzICovCiAJCXNldF9tc2dfZmRf b3V0KGVycm9yX3BpcGVbMV0pOwogCisJCSh2b2lkKXNldF9ybGltaXRfbnByb2MoZl9vdXQpOwog CQlyZWN2X2ZpbGVzKGZfaW4sZmxpc3QsbG9jYWxfbmFtZSk7CiAJCWlvX2ZsdXNoKEZVTExfRkxV U0gpOwogCQlyZXBvcnQoZl9pbik7CmRpZmYgLXVwcmsub3JpZyByc3luYy0yLjYuMy5vcmlnL3By b3RvLmggcnN5bmMtMi42LjMvcHJvdG8uaAotLS0gcnN5bmMtMi42LjMub3JpZy9wcm90by5oCTIw MDQtMDktMjEgMTM6MTU6NTYgKzA0MDAKKysrIHJzeW5jLTIuNi4zL3Byb3RvLmgJMjAwNC0xMC0y NyAxNTo1NDowOCArMDQwMApAQCAtMjc0LDMgKzI3NCw0IEBAIGludCBfSW5zdXJlX3RyYXBfZXJy b3IoaW50IGExLCBpbnQgYTIsIGkKIHZvaWQgKl9uZXdfYXJyYXkodW5zaWduZWQgaW50IHNpemUs IHVuc2lnbmVkIGxvbmcgbnVtKTsKIHZvaWQgKl9yZWFsbG9jX2FycmF5KHZvaWQgKnB0ciwgdW5z aWduZWQgaW50IHNpemUsIHVuc2lnbmVkIGxvbmcgbnVtKTsKIGludCBzeXNfZ2V0dGltZW9mZGF5 KHN0cnVjdCB0aW1ldmFsICp0dik7CitpbnQgc2V0X3JsaW1pdF9ucHJvYyhpbnQgZl9vdXQpOwo=