INNFEED(8) InterNetNews Documentation INNFEED(8)

innfeed, imapfeed - تغذیه‌کننده جریانی چندمیزبانه و چنداتصاله NNTP

innfeed [-ChmMvxyz] [-a spool-dir] [-b directory] [-c config-file] [-d log-level] [-e bytes] [-l logfile] [-o bytes] [-p pid-file] [-s command] [-S status-file] [file]

برنامه innfeed پروتکل NNTP را برای انتقال اخبار بین رایانه‌ها پیاده‌سازی می‌کند. این برنامه پروتکل استاندارد IHAVE و همچنین افزونه جریانی CHECK/TAKETHIS را مدیریت می‌کند. innfeed می‌تواند هم‌زمان هر تعداد میزبان دوردست را تغذیه کند و در صورت پیکربندی، چندین اتصال به هر میزبان باز خواهد کرد. تنها محدودیت‌ها، محدودیت‌های فرایند برای توصیف‌کننده‌های پرونده باز (file descriptors) و حافظه هستند.

به‌عنوان جایگزینی برای استفاده از NNTP، امکان ارسال خوراک اخبار INN به یک سرور IMAP نیز وجود دارد. این کار با استفاده از یک فایل اجرایی به نام imapfeed انجام می‌شود که به جز در فرایند تحویل، کاملاً مشابه innfeed است. نسخه جدید دارای دو نوع اتصال است: یک اتصال LMTP برای تحویل پیام‌های معمولی و یک اتصال IMAP برای مدیریت پیام‌های کنترلی.

در صورت استفاده به همراه delayer(8)، برنامه innfeed می‌تواند یک خوراک با تاخیر به همتایان دوردست یا به یک نمونه محلی دیگر از innd ارسال کند، به‌ویژه برای اینکه امکان رد هرزنامه‌ها قبل از رسیدن واقعی آن‌ها فراهم شود.

برنامه innfeed سه حالت عملیاتی دارد: کانال (channel)، فایل قیفی (funnel-file) و دسته‌ای (batch).

حالت کانال زمانی استفاده می‌شود که هیچ نام فایلی در خط فرمان مشخص نشده باشد، کلیدواژه input-file در فایل پیکربندی داده نشده باشد، و گزینه -x نیز داده نشده باشد. در حالت کانال، innfeed به‌گونه‌ای اجرا می‌شود که ورودی استاندارد (stdin) آن از طریق یک لوله (pipe) به innd متصل است. هر زمان که innd این لوله را ببندد (که در حین پردازش عادی به دلایل متعددی این کار را انجام می‌دهد)، innfeed خارج خواهد شد. این برنامه ابتدا سعی می‌کند پیش از صدور دستور QUIT، ارسال تمام مقالاتی را که در میانه انتقال آن‌ها بوده است به پایان برساند. این بدان معناست که بسته به کندی همتایان شما، خروج innfeed ممکن است کمی طول بکشد. این برنامه هرگز (یا بهتر بگوییم، تقریباً هرگز) اتصال را به صورت ناگهانی قطع نمی‌کند. بنابراین روش توصیه‌شده برای راه‌اندازی مجدد innfeed در صورت اجرا در حالت کانال این است که به innd بگویید لوله را ببندد و یک فرایند جدید innfeed ایجاد کند. این کار را می‌توان با دستور "ctlinnd flush feed" انجام داد که در آن feed نام خوراک کانال innfeed در فایل newsfeeds است.

حالت فایل قیفی (funnel-file) زمانی استفاده می‌شود که یک نام فایل به‌عنوان آرگومان داده شود یا کلیدواژه input-file در فایل پیکربندی قید شده باشد. در حالت فایل قیفی، فایل مشخص‌شده را برای اطلاعاتی با همان قالب‌بندی که innd در حالت کانال ارائه می‌داد می‌خواند. انتظار می‌رود که innd به طور مداوم در این فایل بنویسد، بنابراین وقتی innfeed به انتهای فایل می‌رسد، به صورت دوره‌ای اطلاعات جدید را بررسی می‌کند. برای جلوگیری از رشد بی‌رویه فایل قیفی، باید به صورت دوره‌ای فایل را کنار بگذارید (یا به سادگی آن را حذف کنید) و از innd بخواهید فایل را فلاش (flush) کند. سپس، پس از اینکه فایل توسط innd فلاش شد، می‌توانید یک سیگنال SIGALRM به innfeed ارسال کنید، و آن نیز فایل را بسته و فایل جدید ایجادشده توسط innd را باز خواهد کرد. چیزی شبیه به:

innfeed -p <pathrun in inn.conf>/innfeed.pid my-funnel-file &
while true; do
    sleep 43200
    rm -f my-funnel-file
    ctlinnd flush funnel-file-site
    kill -ALRM `cat <pathrun>/innfeed.pid`
done

حالت دسته‌ای زمانی استفاده می‌شود که گزینه -x به کار رود. در حالت دسته‌ای، innfeed ورودی استاندارد را نادیده می‌گیرد و صرفاً فایل‌های معوق (backlog) ایجادشده توسط یک innfeed در حال اجرای قبلی را پردازش می‌کند. این حالت معمولاً مورد نیاز نیست زیرا innfeed خودش پردازش فایل‌های معوق را بر عهده خواهد گرفت.

برنامه innfeed برای اجرای درست به چند مورد نیاز دارد: یک دایرکتوری که بتواند فایل‌های معوق (backlog) را در آن ذخیره کند، و یک فایل پیکربندی برای توصیف اینکه کدام همتایان را باید مدیریت کند.

فایل پیکربندی در innfeed.conf(5) شرح داده شده است. از گزینه -c می‌توان برای تعیین فایلی متفاوت، و از -b برای تعیین دایرکتوری متفاوتی برای فایل‌های معوق استفاده کرد. کلیدهای backlog-* در فایل پیکربندی رفتار نگهداری کارهای معوق را مشخص می‌کنند. برای هر همتا (مثلاً "foo")، برنامه innfeed تا ۴ فایل را در دایرکتوری معوق مدیریت می‌کند:

  • یک فایل foo.lock که مانع تداخل سایر نمونه‌های innfeed با این نمونه می‌شود.
  • یک فایل foo.input که حاوی اطلاعات مقاله‌های قدیمی است که innfeed برای پردازش مجدد در حال خواندن آن‌ها است.
  • یک فایل foo.output که در آن innfeed اطلاعات مربوط به مقالاتی را که امکان پردازش آن‌ها وجود نداشته است (معمولاً به دلیل کندی یا مسدود بودن یک همتا) می‌نویسد. هر backlog-rotate-period ثانیه یک‌بار، innfeed بررسی می‌کند که آیا خالی نیست، و اگر هیچ فایل foo وجود نداشته باشد و foo.input خالی باشد، نام foo.output را به foo.input تغییر می‌دهد و شروع به خواندن از آن می‌کند.
  • یک فایل foo که هرگز توسط innfeed ساخته نمی‌شود، اما اگر innfeed هنگام بررسی در هر backlog-newfile-period ثانیه متوجه حضور آن شود، در اولین فرصت (هر backlog-rotate-period ثانیه در صورتی که foo.input خالی باشد) نام آن را به foo.input تغییر می‌دهد و شروع به خواندن از آن می‌کند. این به شما امکان می‌دهد یک فایل دسته‌ای بسازید و آن را در جایی قرار دهید که innfeed آن را پیدا کند.

هرگز نباید فایل‌های foo.input یا foo.output یک فرایند innfeed در حال اجرا را دستکاری کنید. ساختار این سه فایل آخر یکی از موارد زیر است:

/path/to/article <message-id>
@token@ <message-id>

این دقیقاً مشابه دو فیلد اول خطوطی است که innd به innfeed تحویل می‌دهد، و مشابه دو فیلد اول خطوط فایل دسته‌ای است که اگر innfeed به هر دلیلی در دسترس نباشد، innd آن را می‌نویسد. هنگامی که innfeed فایل‌های دسته‌ای خود را پردازش می‌کند، هر چیزی را پس از دو فیلد اول که با فاصله جدا شده‌اند نادیده می‌گیرد؛ بنابراین انتقال فایل دسته‌ای ایجادشده توسط innd به مکان مناسب کار خواهد کرد، حتی اگر خطوط دارای فیلدهای اضافی باشند.

فیلد اول می‌تواند یک شناسه رابط ذخیره‌سازی (storage API token) نیز باشد. این دو نوع خط می‌توانند در هم آمیخته باشند؛ innfeed در صورت لزوم از مدیر ذخیره‌سازی استفاده خواهد کرد، و در غیر این صورت فیلد اول را به‌عنوان نام فایلی برای خواندن مستقیم در نظر می‌گیرد.

برنامه innfeed وضعیت فعلی خود را در فایل innfeed.status (یا فایلی که با گزینه -S مشخص شده) می‌نویسد. این فایل حاوی جزئیاتی در مورد کل فرایند و هر همتایی است که این نمونه از innfeed مدیریت می‌کند.

اگر به innfeed دستور داده شود مقاله‌ای را به میزبانی که مدیریت نمی‌کند ارسال کند، اطلاعات مقاله در فایلی مطابق با الگوی innfeed-dropped.* قرار می‌گیرد که بخشی از نام فایل با شناسه فرایند (PID) مربوط به فرایند innfeed که در آن می‌نویسد مطابقت دارد. innfeed این فایل را به جز برای نوشتن در آن پردازش نخواهد کرد. اگر چیزی در فایل نوشته نشود، در صورت خروج عادی innfeed حذف خواهد شد. در غیر این صورت، فایل باقی می‌ماند و پس از آن می‌توان procbatch را برای پردازش آن فراخوانی کرد.

به محض دریافت یک سیگنال SIGALRM، innfeed فایل قیفی مشخص‌شده در خط فرمان را می‌بندد و مجدداً آن را باز می‌کند (توضیحات فایل قیفی در بالا را ببینید).

برنامه innfeed سیگنال SIGINT را دریافت کرده و یک تصویر لحظه‌ای (snapshot) بزرگ برای اشکال‌زدایی از وضعیت سیستم در حال اجرا را در فایلی به نام innfeed.snapshot در pathlog می‌نویسد.

برنامه innfeed سیگنال SIGHUP را دریافت کرده و هم فایل پیکربندی و هم فایل‌های گزارش را دوباره بارگیری می‌کند. برای جزئیات بیشتر به innfeed.conf(5) مراجعه کنید.

برنامه innfeed سیگنال SIGCHLD را دریافت کرده و تمام فایل‌های معوق را بسته و مجدداً باز می‌کند.

برنامه innfeed سیگنال SIGTERM را دریافت کرده و یک خاموش‌سازی منظم را انجام می‌دهد.

به محض دریافت SIGUSR1، innfeed سطح اشکال‌زدایی را یک واحد افزایش می‌دهد؛ دریافت SIGUSR2 آن را یک واحد کاهش می‌دهد. سطح اشکال‌زدایی از صفر شروع می‌شود (مگر اینکه از گزینه -d استفاده شده باشد)، که در این صورت هیچ اطلاعات اشکال‌زدایی ارسال نمی‌شود. مقادیر بزرگتر برای این سطح به معنای اطلاعات اشکال‌زدایی بیشتر است. مقادیر تا ۵ در حال حاضر مفید هستند.

سه دسته مختلف از ورودی‌های syslog برای آمارها وجود دارد: میزبان (host)، اتصال (connection) و سراسری (global).

آمارهای میزبان برای یک همتای معین در فواصل زمانی منظم پس از برقراری اولین اتصال (یا در صورت غیرقابل دسترس بودن میزبان دوردست، پس از شروع ذخیره‌سازی در صف اسپول) تولید می‌شوند. آمارهای میزبان مقادیر مجموع را در تمام اتصالاتی که طی بازه زمانی مشخص‌شده فعال بوده‌اند نشان می‌دهند. برای مثال (که در اینجا برای تناسب با صفحه شکسته شده و "vixie" همتای مورد نظر است):

May 23 12:49:08 news innfeed[16015]: vixie checkpoint
    seconds 1381 offered 2744 accepted 1286 refused 1021
    rejected 437 missing 0 accsize 8506220 rejsize 142129
    spooled 990 on_close 0 unspooled 240 deferred 10/15.3
    requeued 25 queue 42.1/100:14,35,13,4,24,10

معانی این فیلدها عبارتند از:

زمان سپری‌شده از زمانی که innfeed به میزبان متصل شده یا از زمانی که آمارها توسط یک ورودی گزارش "final" بازنشانی شده‌اند.
تعداد دستورات IHAVE ارسال‌شده به میزبان، در صورتی که در حالت جریانی (streaming) نباشد. یا مجموع تعداد دستورات TAKETHIS ارسال‌شده در زمان فعال بودن حالت no-CHECK به علاوه تعداد دستورات CHECK ارسال‌شده در حالت جریانی (زمانی که حالت no-CHECK فعال نیست).
تعداد مقالاتی که به میزبان دوردست ارسال شده و توسط آن پذیرفته شده‌اند.
تعداد مقالاتی که به میزبان پیشنهاد شده و میزبان اعلام کرده که آن‌ها را نمی‌خواهد زیرا شناسه پیام (message-ID) را قبلاً دیده است. میزبان دوردست این موضوع را با ارسال پاسخ ۴۳۵ به دستور IHAVE یا پاسخ ۴۳۸ به دستور CHECK مشخص می‌کند.
تعداد مقالاتی که به میزبان منتقل شده‌اند اما آن را نپذیرفته است، زیرا تشخیص داده که یا قبلاً مقاله را داشته است یا به دلیل فیلدهای سرایند Newsgroups یا Distribution مقاله و غیره آن را نمی‌خواهد. میزبان دوردست رد کردن مقاله را با ارسال پاسخ ۴۳۷ یا ۴۳۹ پس از اینکه innfeed تمام مقاله را ارسال کرد، مشخص می‌کند.
تعداد مقالاتی که به innfeed گفته شده بود به میزبان پیشنهاد دهد اما در اسپول مقالات موجود نبودند. این مقالات احتمالاً پیش از اینکه innfeed بتواند آن‌ها را به میزبان عرضه کند، لغو شده یا منقضی شده بودند.
تعداد بایت‌های تمام مقالات پذیرفته‌شده که به میزبان منتقل شده‌اند.
تعداد بایت‌های تمام مقالات ردشده که به میزبان منتقل شده‌اند.
تعداد ورودی‌های مقالاتی که در فایل معوق .output نوشته شده‌اند، زیرا مقالات یا امکان ارسال به میزبان را نداشتند یا توسط آن رد شده بودند. مقالات عموماً به این دلیل در صف اسپول قرار می‌گیرند که مقالات جدید سریع‌تر از آن‌چه بتوان به میزبان عرضه کرد می‌رسند، یا به این دلیل که innfeed تمام اتصالات به میزبان را بسته و تمام مقالاتی را که در آن زمان در حال پردازش بودند به فایل معوق .output هدایت کرده است.
تعداد مقالاتی که در زمان بسته شدن تمام اتصالات به میزبان توسط innfeed به صف اسپول فرستاده شدند.
تعداد ورودی‌های مقالاتی که از فایل معوق .input خوانده شده‌اند.
عدد اول تعداد مقالاتی است که میزبان با ارسال پاسخ ۴۳۱ یا ۴۳۶ به innfeed اعلام کرده که بعداً دوباره امتحان کند. innfeed بلافاصله این مقالات را به انتهای صف برمی‌گرداند.

عدد دوم میانگین اندازه مقالات به تعویق‌افتاده در طول بازه زمانی گزارش‌گیری قبلی است.

تعداد مقالاتی که روی اتصالات در حال انجام بودند اما innfeed آن اتصالات را قطع کرد و مقالات را دوباره در صف قرار داد. این اتصالات ممکن است به دلیل یک مشکل شبکه‌ای قطع شده باشند یا بی‌پاسخ مانده باشند که باعث شده innfeed مهلت زمانی (timeout) آن‌ها را پایان دهد.
عدد اول میانگین اندازه صف در طول بازه زمانی گزارش‌گیری قبلی است. عدد دوم حداکثر اندازه مجاز صف است. عدد سوم درصد زمانی است که صف خالی بوده است. اعداد چهارم تا هفتم درصد زمانی است که صف بین >۰٪ تا ۲۵٪ پر، ۲۵٪ تا ۵۰٪ پر، ۵۰٪ تا ۷۵٪ پر، و ۷۵٪ تا <۱۰۰٪ پر بوده است. عدد آخر درصد زمانی است که صف کاملاً پر بوده است.

اگر از گزینه -z استفاده شود (پایین را ببینید)، هنگام ایجاد آمارهای همتا، هر اتصال نیز آمارهای خود را ثبت خواهد کرد. برای مثال، برای اتصال شماره صفر (از یک مجموعه پنج‌تایی):

May 23 12:49:08 news innfeed[16015]: vixie:0 checkpoint
    seconds 1381 offered 596 accepted 274 refused 225
    rejected 97 accsize 773623 rejsize 86591

اگر فقط حداکثر یک اتصال به یک سرور دوردست باز کنید، ارتباط نزدیکی بین شماره‌های اتصال و شماره‌های میزبان وجود خواهد داشت، اما به طور کلی نمی‌توانید این دو مجموعه اعداد را به روشی آسان یا چندان معنادار به یکدیگر پیوند دهید. وقتی یک اتصال بسته می‌شود، همیشه آمارهای خود را ثبت می‌کند.

اگر همه اتصالات برای یک میزبان با هم بسته شوند، آن میزبان آمارهای خود را به عنوان "final" ثبت کرده و شمارنده‌های خود را بازنشانی می‌کند. اگر خوراک آن‌قدر شلوغ باشد که همیشه حداقل یک اتصال باز و در حال اجرا وجود داشته باشد، پس از گذشت مدتی (که از طریق فایل پیکربندی تنظیم می‌شود)، آمارهای میزبان به‌عنوان نهایی (final) ثبت شده و بازنشانی می‌شوند. این کار برای آسان‌تر کردن تولید آمارهای سطح بالاتر از فایل‌های لاگ توسط سایر برنامه‌ها است.

یک ورودی لاگ وجود دارد که دقیقاً پس از بسته شدن آخرین اتصال یک میزبان و هنگامی که innfeed در حال آماده شدن برای خروج است، برای آن ارسال می‌شود. این ورودی حاوی شمارش‌ها در طول کل عمر فرایند است. فیلد "seconds" از اولین باری است که یک اتصال با موفقیت برقرار شد، یا اولین باری که ذخیره در صف اسپول شروع شد. اگر یک میزبان کاملاً بیکار بوده باشد، چنین ورودی گزارشی نخواهد داشت.

May 23 12:49:08 news innfeed[16015]: decwrl global
    seconds 1381 offered 34 accepted 22 refused 3 rejected 7
    missing 0 accsize 81277 rejsize 12738 spooled 0 unspooled 0

آخرین ورودی لاگ بلافاصله پیش از خروج ارسال می‌شود. این ورودی حاوی خلاصه‌ای از آمارها در طول کل عمر فرایند است.

Feb 13 14:43:41 news innfeed[22344]: ME global
    seconds 15742 offered 273441 accepted 45750 refused 222008
    rejected 3334 missing 217 accsize 93647166 rejsize 7421839
    spooled 10 unspooled 0

برنامه innfeed گزینه‌های زیر را می‌پذیرد.

فلگ -a برای تعیین شاخه اصلی درخت اسپول مقالات استفاده می‌شود. innfeed یک chdir(2) به این دایرکتوری انجام می‌دهد، بنابراین احتمالاً باید یک مسیر مطلق باشد. مقدار پیش‌فرض patharticles است که در inn.conf تنظیم شده است.
فلگ -b ممکن است برای تعیین دایرکتوری متفاوتی برای ذخیره و بازیابی فایل‌های معوق (backlog)، و همچنین برای فایل‌های قفل استفاده شود. اگر مسیر نسبی باشد، نسبت به pathspool تنظیم‌شده در inn.conf سنجیده می‌شود. پیش‌فرض "innfeed" است.

توصیه می‌شود از پارامتر backlog-directory در فایل پیکربندی برای تعریف یک دایرکتوری مشخص استفاده کنید، زیرا در غیر این صورت news.daily آن را دریافت نخواهد کرد و برخی از عملیات نگهداری روی دایرکتوری معوق انجام نخواهد شد.

فلگ -c می‌تواند برای تعیین یک فایل پیکربندی متفاوت از مقدار پیش‌فرض استفاده شود. اگر مسیر نسبی باشد، نسبت به pathetc تنظیم‌شده در inn.conf در نظر گرفته می‌شود. مقدار پیش‌فرض innfeed.conf است.

توجه داشته باشید که اگر از نامی غیر از نام پیش‌فرض استفاده کنید و تنظیمات پیش‌فرض log-file یا pid-file را نیز در فایل پیکربندی تغییر دهید، scanlogs نمی‌تواند فایل‌های لاگ اشکال‌زدایی را چرخش دهد (نام‌های آن‌ها در innfeed.conf و innfeed-delayed.conf جستجو می‌شود). همچنین سایر عملیات نگهداری انجام‌شده توسط news.daily نیز در صورتی که backlog-directory از حالت پیش‌فرض خود در یک فایل پیکربندی با نام متفاوت تغییر داده شود، انجام نخواهند شد.

فلگ -C برای این استفاده می‌شود که innfeed صرفاً فایل پیکربندی را بررسی کند، خطاها را گزارش دهد و سپس خارج شود.
فلگ -d می‌تواند برای تعیین سطح گزارش‌گیری اولیه استفاده شود. تمام پیام‌های اشکال‌زدایی به خروجی خطای استاندارد (stderr) ارسال می‌شوند (که ممکن است مورد نظر شما نباشد، فلگ -l در زیر را ببینید).
فلگ -e می‌تواند برای تعیین محدودیت اندازه (به بایت) برای فایل‌های معوق .output که innfeed ایجاد می‌کند استفاده شود. اگر حجم فایل خروجی بیش از ۱۰٪ بزرگتر از مقدار داده‌شده شود، innfeed فایل خروجی را با بخش انتهایی نسخه اصلی جایگزین می‌کند. مقدار پیش‌فرض "0" است که به معنای عدم وجود محدودیت است.
برای چاپ پیام راهنمای نحوه استفاده، از فلگ -h استفاده کنید.
فلگ -l می‌تواند برای تعیین یک فایل لاگ به جای stderr استفاده شود. از آنجا که innd برنامه innfeed را با اتصال stderr به /dev/null راه‌اندازی می‌کند، استفاده از این گزینه می‌تواند در ثبت پیام‌های خطای غیرعادی یا پیام‌های اشکال‌زدایی مفید باشد (تمام پیام‌های خطای «عادی» به syslog ارسال می‌شوند).

پیشنهاد می‌شود از پارامتر log-file در فایل پیکربندی برای تعریف یک نام فایل مشخص استفاده کنید، زیرا در غیر این صورت scanlogs آن را دریافت نمی‌کند و چرخش فایل گزارش انجام نمی‌شود.

فلگ -m برای فعال کردن ثبت گزارش تمام مقالات مفقود استفاده می‌شود. به طور معمول، اگر مقاله‌ای مفقود باشد، innfeed تعداد آن را نگه می‌دارد اما اطلاعات بیشتری ثبت نمی‌کند. وقتی از این فلگ استفاده می‌شود، جزئیات مربوط به شناسه‌های پیام و نام مسیرهای مورد انتظار گزارش می‌شوند.
اگر innfeed با پشتیبانی از mmap کامپایل شده باشد، فلگ -M استفاده از mmap() را خاموش می‌کند؛ در غیر این صورت، هیچ تأثیری ندارد.
فلگ -o مقداری را برای حداکثر تعداد بایت داده‌های مقاله‌ای که innfeed قرار است در حافظه نگه دارد تعیین می‌کند. این قابلیت هنوز به درستی کار نمی‌کند.
فلگ -p برای تعیین نام فایلی که شناسه فرایند (PID) در آن نوشته می‌شود به کار می‌رود. مسیر نسبی نسبت به pathrun تنظیم‌شده در inn.conf در نظر گرفته می‌شود. پیش‌فرض innfeed.pid است.

پیشنهاد می‌شود از پارامتر pid-file در فایل پیکربندی برای تعریف یک نام فایل مشخص استفاده کنید، زیرا در غیر این صورت scanlogs آن را پیدا نمی‌کند و فایل لاگ قبل از چرخش به درستی فلاش نمی‌شود.

فلگ -s نام دستوری را مشخص می‌کند که باید در یک زیرفرایند اجرا شود و اطلاعات مقاله از آن خوانده شود. این مشابه عملکرد حالت کانال است، با این تفاوت که command جایگاهی را که معمولاً توسط innd اشغال می‌شود می‌گیرد.
فلگ -S نام فایلی را مشخص می‌کند که وضعیت دوره‌ای در آن نوشته می‌شود. اگر مسیر نسبی باشد، نسبت به pathlog تنظیم‌شده در inn.conf سنجیده می‌شود. پیش‌فرض innfeed.status است.
وقتی فلگ -v داده شود، اطلاعات نسخه در خروجی خطای استاندارد (stderr) چاپ شده و سپس innfeed خارج می‌شود.
فلگ -x برای این به کار می‌رود که به innfeed اعلام کند هیچ اطلاعات مقاله‌ای از innd انتظار نداشته باشد، بلکه فقط هر فایل معوق موجود را پردازش کرده و سپس خارج شود.
فلگ -y برای اجازه دادن به اتصال پویا به همتایان استفاده می‌شود. اگر از این فلگ استفاده شود و اطلاعات مقاله‌ای از innd دریافت گردد که یک همتای ناشناخته را مشخص می‌کند، نام همتا به عنوان نام IP نیز در نظر گرفته شده و یک ارتباط با آن ایجاد می‌شود. با استفاده از این قابلیت، می‌توان فقط پیش‌فرض‌های سراسری را در فایل innfeed.conf قرار داد، به شرطی که نام همتای مورد استفاده توسط innd همان نام IP باشد.

توجه داشته باشید که استفاده از innfeed با گزینه -y و بدون همتا در innfeed.conf باعث بروز مشکلی می‌شود که در آن innfeed اولین مقاله را نادیده می‌گیرد و حذف می‌کند.

فلگ -z برای این استفاده می‌شود که در یک پیکربندی فید موازی، هر اتصال زمانی که کنترل‌کننده اتصالات آمارهای خود را چاپ می‌کند، آمارهای خود را گزارش دهد.

هنگام استفاده از گزینه -x، فیلد initial-connections مدخل فایل پیکربندی، بدون توجه به بزرگی فایل دسته‌ای و بدون توجه به مقدار مشخص‌شده در فیلد max-connections، تعداد کل اتصالات ایجادشده و استفاده‌شده خواهد بود. بنابراین مقدار "0" برای initial-connections به این معنی است که در حالت -x هیچ اتفاقی نخواهد افتاد.

برنامه innfeed به طور خودکار فایل را از pathoutgoing برنمی‌دارد. این کار باید با روش‌های خارجی برای آن آماده شود.

احتمالاً اشکالات بسیار بیشتری برای شمارش وجود دارد.

یک جایگزین برای innfeed می‌تواند innduct باشد که توسط Ian Jackson نگهداری می‌شود و در نشانی http://www.chiark.greenend.org.uk/ucgi/~ian/git-manpage/innduct.git/innduct.8 در دسترس است. هدف آن حل یک مشکل طراحی در شیوه کار innfeed است. در واقع، پروتکل فید برنامه که میان innd و innfeed ردوبدل می‌شود همراه با اتلاف است (lossy): اگر innfeed به طور غیرمنتظره‌ای متوقف شود، مقالاتی که innd در لوله به سمت innfeed نوشته است نادیده گرفته خواهند شد. innd هیچ راهی برای تشخیص اینکه آن مقالات کدام بوده‌اند ندارد، هیچ سابقه مفیدی ثبت نمی‌کند و هیچ تلاشی برای ارسال مجدد این مقالات انجام نمی‌دهد.

خودِ برنامه باینری.
فایل پیکربندی.
دایرکتوری فایل‌های معوق (backlog).

نوشته‌شده توسط James Brister <brister@vix.com> برای InterNetNews. تبدیل به POD توسط Julien Elie.

نسخه‌های قبلی innfeed (تا نسخه 0.10.1) به صورت جداگانه عرضه می‌شدند؛ اکنون innfeed بخشی از INN است و از همان شماره نسخه استفاده می‌کند.

ctlinnd(8), delayer(8), inn.conf(5), innfeed.conf(5), innd(8), procbatch(8).

2025-05-09 INN 2.7.4