نام (NAME)

pmcd - دیمن گردآورنده معیارهای کارایی

خلاصه دستور (SYNOPSIS)

pmcd [-AfFQSv?] [-c config] [-C nctx] [-D debug] [-H hostname] [-i ipaddress] [-l logfile] [-L bytes] [-M nmetric] [-[n|N] pmnsfile] [-p port[,port ...]] [-q timeout] [-s sockname] [-t timeout] [-T traceflag] [-U username] [-x file]

توضیحات (DESCRIPTION)

دستور pmcd گردآورنده‌ای است که توسط Performance Co-Pilot (نگاه کنید به PCPIntro(1)) برای گردآوری معیارهای کارایی روی یک سیستم استفاده می‌شود. به‌عنوان یک قاعده، برای اینکه هرگونه معیار کارایی در دسترس PCP قرار گیرد، باید یک نمونه از pmcd روی سیستم در حال اجرا باشد.

دستور pmcd اتصال‌های برنامه‌های کلاینت را که روی همان ماشین یا به‌صورت از راه دور در حال اجرا هستند می‌پذیرد و معیارها و سایر اطلاعات مربوطه را از ماشینی که pmcd روی آن اجرا می‌شود در اختیار آنها قرار می‌دهد. pmcd بخش عمده‌ای از پاسخ‌گویی به این درخواست‌ها را به مجموعه‌ای از Performance Metrics Domain Agents (یا به‌طور خلاصه عامل‌ها) واگذار می‌کند؛ جایی که هر عامل مسئول گروه خاصی از معیارها است که به‌عنوان حوزه (domain) آن عامل شناخته می‌شود. برای نمونه، عامل postgresql مسئول گزارش اطلاعات مربوط به پایگاه‌داده PostgreSQL است، مانند تعداد تراکنش‌ها و پرس‌وجوها، آمارهای نمایه‌سازی و همگام‌سازی، و غیره.

عامل‌ها می‌توانند فرایندهایی باشند که توسط pmcd شروع شده‌اند، فرایندهای مستقل باشند یا اشیاء اشتراکی پویا (DSOها، نگاه کنید به dlopen(3)) باشند که به فضای آدرس pmcd پیوست شده‌اند. بخش پیکربندی در ادامه نحوه تعیین اتصال‌ها به عامل‌ها را شرح می‌دهد.

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

می‌توان کنترل دسترسی به pmcd را بر اساس کاربران، گروه‌ها و میزبان‌ها تعیین کرد. این قابلیت به شما امکان می‌دهد تا کاربران، گروه‌های کاربری و میزبان‌های خاصی را از دسترسی به معیارهای ارائه‌شده توسط pmcd منع کنید، که با جزئیات بیشتر در بخش کنترل دسترسی در ادامه توضیح داده شده است.

گزینه‌ها (OPTIONS)

گزینه‌های خط فرمان موجود عبارتند از:

-A: غیرفعال کردن اعلان سرویس (service advertisement). به‌طور پیش‌فرض، pmcd حضور خود را در شبکه با استفاده از هر سازوکار در دسترسی اعلان می‌کند تا به ابزارهای پایش از راه دور در یافتن آن کمک کند. این سازوکارها با این گزینه غیرفعال می‌شوند.
-c config, --config=config: در هنگام راه‌اندازی، pmcd از یک فایل پیکربندی از متغیر پیکربندی $PCP_PMCDCONF_PATH در /etc/pcp.conf یا یک متغیر محیطی با همین نام استفاده می‌کند. با این حال، با استفاده از این گزینه می‌توان این مقادیر را با config بازنویسی کرد. قالب این فایل پیکربندی در زیر توضیح داده شده است.
-C nctx, --maxctx=nctx: هر کلاینتِ pmcd می‌تواند یک یا چند زمینه (context) ایجاد کند. تعداد زمینه‌ها به‌ازای هر کلاینت به‌طور پیش‌فرض به حداکثر ۶۴ محدود شده است تا در برابر حملات منع سرویس (DoS) از طریق تهی‌سازی حافظه و توصیف‌گرهای فایل محافظت شود. از گزینه -C می‌توان برای تغییر این حداکثر به nctx زمینه استفاده کرد.
-f, --foreground: به‌طور پیش‌فرض pmcd به‌عنوان یک دیمن راه‌اندازی می‌شود. گزینه -f مشخص می‌کند که باید در پیش‌زمینه اجرا شود. این حالت هنگام تلاش برای عیب‌یابی مشکلات ناشی از رفتارهای نادرست عامل‌ها بسیار مفید است.
-F, --managed: به‌طور پیش‌فرض pmcd به‌عنوان یک دیمن راه‌اندازی می‌شود. گزینه -F مشخص می‌کند که توسط یک سرویس سیستمی مانند launchd(1) یا systemd(1) مدیریت خواهد شد.
-H hostname, --hostname=hostname: این گزینه می‌تواند برای تنظیم نام میزبانی که pmcd برای بازنمایی این نمونه از خود استفاده خواهد کرد، به کار رود. این مورد توسط ابزارهای کلاینت مانند pmlogger(1) هنگام گزارش‌گیری از میزبان (احتمالاً دوردست) استفاده می‌شود. اگر این گزینه تنظیم نشود، معیار pmcd.hostname با مقداری که توسط pmhostname(1) برگردانده می‌شود مطابقت خواهد داشت. برای جزئیات کامل درباره نحوه ارزیابی نام میزبان، به صفحه راهنمای آن ابزار مراجعه کنید.
-i ipaddress, --interface=ipaddress: این گزینه معمولاً فقط روی میزبان‌هایی با بیش از یک رابط شبکه استفاده می‌شود. اگر هیچ گزینه -i مشخص نشود، pmcd اتصال‌های برقرارشده با هر یک از آدرس‌های IP (پروتکل اینترنت) میزبان خود را می‌پذیرد. از گزینه -i برای مشخص کردن صریح یک آدرس IP که اتصال‌ها باید روی آن پذیرفته شوند استفاده می‌شود. ipaddress باید در قالب استاندارد نقطه‌دار باشد (مانند 100.23.45.6). گزینه -i می‌تواند چندین بار برای تعریف فهرستی از آدرس‌های IP استفاده شود. اتصال‌های برقرارشده با هر آدرس IP دیگری که میزبان دارد رد خواهند شد. این می‌تواند برای محدود کردن اتصال‌ها به یک رابط شبکه در صورتی که میزبان یک دروازه شبکه (gateway) باشد استفاده شود. همچنین اگر میزبان، آدرس IP میزبان دیگری را که از کار افتاده تحویل بگیرد، مفید خواهد بود. در چنین شرایطی فقط باید آدرس‌های IP استاندارد میزبان داده شود (نه آدرس‌های به ارث رسیده از میزبان از کار افتاده). این به برنامه‌های PCP اجازه می‌دهد متوجه شوند میزبان از کار افتاده است، به‌جای اینکه به میزبانی متصل شوند که هویت میزبان از کار افتاده را به خود گرفته است.
-l logfile, --log=logfile: به‌طور پیش‌فرض یک فایل گزارش به نام pmcd.log در دایرکتوری $PCP_LOG_DIR/pmcd نوشته می‌شود. گزینه -l باعث می‌شود که فایل گزارش به‌جای مقدار پیش‌فرض در logfile نوشته شود. اگر فایل گزارش نتواند ایجاد شود یا قابل نوشتن نباشد، خروجی به‌جای آن در خطای استاندارد نوشته می‌شود..TP -L bytes, --maxbytes=bytes PDUهای دریافتی توسط pmcd از کلاینت‌های پایش به‌طور پیش‌فرض به بیشینه اندازه ۶۵۵۳۶ بایت محدود شده‌اند تا در برابر حملات منع سرویس (Denial of Service) محافظت به عمل آید. از گزینه -L می‌توان برای تغییر بیشینه اندازه PDU ورودی استفاده کرد.
-M nmetric, --maxmetric=nmetric: هر عملیات fetch دریافتی توسط pmcd از کلاینت‌های پایش به‌طور پیش‌فرض به حداکثر ۳۲۷۶۸ معیار محدود شده است تا در برابر حملات منع سرویس از طریق اتمام حافظه محافظت شود. از گزینه -M می‌توان برای تغییر این حداکثر به nmetric معیار استفاده کرد.
-n pmnsfile, --namespace=pmnsfile: در حالت عادی pmcd فضای نام معیارهای کارایی (PMNS) پیش‌فرض را از $PCP_VAR_DIR/pmns/root بارگذاری می‌کند، اما اگر گزینه -n مشخص شود، یک فضای نام جایگزین از فایل pmnsfile بارگذاری می‌گردد.
-N pmnsfile, --uniqnames=pmnsfile: عملکردی مشابه -n دارد، به‌جز در نحوه مدیریت شناسه‌های تکراری معیارهای کارایی (PMIDها) در pmnsfile - نام‌های تکراری با -n مجاز هستند، اما با -N مجاز نمی‌باشند.
-p port, --port=port: پورتی را که باید به آن گوش فرا داده شود مشخص می‌کند. به‌طور پیش‌فرض از پورت 44321 استفاده می‌شود.
-q timeout: پروتکل تبادل نسخه بین pmcd و عامل (جدید در PCP 2.0 - معرفی‌شده برای حفظ سازگاری رو به عقب) از این مهلت زمانی استفاده می‌کند تا مشخص کند pmcd چقدر باید پیش از فرض این‌که پاسخی مبنی بر نسخه از سوی عامل ارسال نمی‌شود، منتظر بماند. اگر این مهلت زمانی به پایان برسد، فرض می‌شود که عامل از پروتکل PCP 2.0 پشتیبانی نمی‌کند. بازه زمانی پیش‌فرض مهلت سه ثانیه است، اما گزینه -q امکان تعیین یک مهلت زمانی جایگزین (که باید بزرگ‌تر از صفر باشد) را فراهم می‌سازد. واحد timeout ثانیه است. همچنین اگر از -q استفاده نشود، می‌توان از متغیر محیطی PMCD_CREDS_TIMEOUT برای تعیین این بازه زمانی مهلت استفاده کرد.
-Q, --remotecert: الزام می‌کند که تمام اتصالات کلاینت‌های راه دور، یک گواهی (certificate) ارائه دهند.
-s sockname, --socket=sockname: مسیر یک سوکت محلی unix domain را مشخص می‌کند (تنها برای بسترهایی که از این خانواده سوکت پشتیبانی می‌کنند). مقدار پیش‌فرض $PCP_RUN_DIR/pmcd.socket است.
-S, --reqauth: الزام می‌کند که تمام اتصالات کلاینت‌ها، اعتبارنامه کاربر را ارائه دهند. این بدان معناست که تنها سوکت‌های unix domain یا اتصالات احراز هویت‌شده مجاز هستند (نیازمند پشتیبانی از سوکت‌های امن). اگر الزامات کنترل دسترسی کاربر یا گروهی در فایل پیکربندی pmcd مشخص شده باشد، این حالت عملکرد به‌طور خودکار فعال می‌شود؛ چه پرچم -S مشخص شده باشد و چه نشده باشد.
-t timeout: برای جلوگیری از متوقف شدن کل سامانه جمع‌آوری معیارهای کارایی (PMCS) توسط کلاینت‌ها یا عامل‌های بدرفتار، pmcd در تبادلات PDU با کلاینت‌ها و عامل‌هایی که به عنوان فرایند اجرا می‌شوند، از مهلت زمانی (timeout) استفاده می‌کند. به‌طور پیش‌فرض بازه زمانی مهلت پنج ثانیه است. گزینه -t امکان تعیین یک بازه زمانی مهلت جایگزین به ثانیه را فراهم می‌سازد. اگر timeout صفر باشد، مهلت‌های زمانی غیرفعال می‌شوند. استفاده تعاملی از اشکال‌زدا (debugger) بر روی یک عامل تقریباً غیرممکن است مگر اینکه مهلت‌های زمانی برای فرایند والد آن یعنی pmcd غیرفعال شده باشند.

پس از اجرای pmcd، می‌توان این مهلت زمانی را با ذخیره یک مقدار عدد صحیح (مهلت زمانی به ثانیه) در معیار pmcd.control.timeout از طریق pmstore(1) به‌طور پویا تغییر داد.

-T traceflag, --trace=traceflag: برای کمک به تشخیص خطای عامل‌ها و/یا کلاینت‌های pmcd که عملکرد درستی ندارند، یک سازوکار داخلی ردگیری رویداد در pmcd پشتیبانی می‌شود. مقدار traceflag به عنوان یک فیلد بیتی با عملکردهای کنترلی زیر تفسیر می‌شود:

1: فعال‌سازی ردگیری اتصال کلاینت
2: فعال‌سازی ردگیری PDU
256: ردگیری بدون بافر رویدادها

به‌طور پیش‌فرض، ردگیری رویدادها با استفاده از یک بافر دایره‌ای بافرگذاری می‌شود که با ثبت رویدادهای جدید بازنویسی می‌گردد. اندازه پیش‌فرض بافر، ۲۰ رویداد آخر را در خود نگه می‌دارد؛ هرچند این مقدار را می‌توان با استفاده از pmstore(1) جهت ویرایش معیار pmcd.control.tracebufs تغییر داد.

به همین ترتیب، پس از اجرای pmcd، کنترل ردگیری رویداد می‌تواند با ذخیره ۱ (فعال) یا ۰ (غیرفعال) در معیارهای pmcd.control.traceconn، pmcd.control.tracepdu و pmcd.control.tracenobuf به‌طور پویا تغییر داده شود. این معیارها به فیلدهای بیتی مرتبط با آرگومان traceflag برای گزینه -T نگاشت می‌شوند.

هنگام کار در حالت بافرشده، هر زمان که اتصال عاملی توسط pmcd پایان یابد، یا مقداری در معیار pmcd.control.dumptrace از طریق pmstore(1) ذخیره شود، بافر ردگیری رویداد تخلیه خواهد شد.

در حالت بدون بافر، هر رویداد به محض رخ دادن گزارش خواهد شد.

-U username, --username=USER: حساب کاربری که pmcd تحت آن اجرا می‌شود. پیش‌فرض در نسخه‌های کنونی PCP، حساب کاربری غیرممتاز «pcp» است، اما در نسخه‌های قدیمی‌تر از حساب کاربری مدیر سیستم («root») به‌طور پیش‌فرض استفاده می‌شد.
-v, --verify: بررسی صحت فایل پیکربندی pmcd، گزارش هرگونه خطا و سپس خروج با وضعیتی که نشان‌دهنده موفقیت یا شکست در اعتبارسنجی است.
-x file: پیش از آنکه logfile مربوط به pmcd بتواند باز شود، ممکن است pmcd با یک خطای مهلک مواجه شود که مانع از شروع به کار آن گردد. به‌طور پیش‌فرض، خروجی توصیف‌کننده این خطا به /dev/tty ارسال می‌شود، اما می‌تواند به file هدایت گردد..TP -?، --help نمایش پیام راهنما و خروج.

پیکربندی (CONFIGURATION)

در هنگام راه‌اندازی، pmcd به دنبال فایل پیکربندی به نام $PCP_PMCDCONF_PATH می‌گردد. این فایل مشخص می‌کند کدام عامل‌ها چه دامنه‌هایی از معیارهای کارایی را پوشش می‌دهند و چگونه pmcd باید با عامل‌ها ارتباط برقرار کند. یک بخش اختیاری برای تعیین کنترل‌های دسترسی ممکن است پس از داده‌های پیکربندی عامل بیاید.

هشدار: pmcd معمولاً به عنوان بخشی از توالی بوت آغاز به کار می‌کند و در ابتدا با دسترسی root اجرا می‌شود. فایل پیکربندی ممکن است شامل دستورات شلی برای ایجاد عامل‌ها باشد که توسط root اجرا خواهند شد. برای جلوگیری از رخنه و آسیب‌پذیری‌های امنیتی، فایل پیکربندی باید تنها توسط root قابل نوشتن باشد. همچنین استفاده از نام‌های مسیر مطلق توصیه می‌شود.

بزرگی و کوچکی حروف کلمات رزرو شده در فایل پیکربندی اهمیتی ندارد، اما در سایر بخش‌ها، وضعیت بزرگی و کوچکی حروف حفظ می‌شود.

خطوط خالی و کامنت‌ها در فایل پیکربندی مجاز هستند (حتی توصیه می‌شوند). یک کامنت با نویسه «#» آغاز می‌شود و در انتهای خط پایان می‌یابد. یک خط می‌تواند با قرار دادن نویسه «\» (بک‌اسلش) به عنوان آخرین نویسه در خط ادامه یابد. یک کامنت در یک خط ادامه‌دار، در پایان همان خط ادامه‌دار خاتمه می‌یابد. فاصله‌ها را می‌توان با قرار دادن کل عنصر در علامت‌های نقل‌قول جفتی، درون عناصر واژگانی گنجاند. یک نقل‌قول جفتی که قبل از آن بک‌اسلش آمده باشد، همواره به عنوان یک نقل‌قول لفظی در نظر گرفته می‌شود. یک «#» درون نقل‌قول‌های جفتی یا پس از یک بک‌اسلش، به جای یک جداکننده کامنت، به صورت یک نویسه عادی تفسیر می‌شود. عناصر واژگانی و جداکننده‌ها در بخش‌های بعدی بیشتر شرح داده شده‌اند.

پیکربندی عامل (AGENT CONFIGURATION)

هر خط از بخش پیکربندی عامل در فایل پیکربندی شامل جزئیات نحوه اتصال pmcd به یکی از عامل‌های خود است و مشخص می‌کند عامل با کدام دامنه از معیارها سر و کار دارد. یک عامل ممکن است به عنوان یک DSO، از طریق یک سوکت، یا یک جفت لوله (pipe) متصل شود.

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

هر مشخصه عامل باید با یک برچسب متنی (رشته) آغاز شود و به دنبال آن یک عدد صحیح در محدوده ۱ تا ۵۱۰ بیاید. برچسب، شناسه‌ای است که برای ارجاع به عامل استفاده می‌شود و عدد صحیح، دامنه‌ای را که عامل برای آن داده ارائه می‌دهد مشخص می‌کند. این شناسه دامنه با بخش دامنه‌ی PMIDهای مدیریت‌شده توسط عامل مطابقت دارد. هر عامل باید یک برچسب و شناسه دامنه یکتا داشته باشد.

برای عامل‌های DSO خطی به شکل زیر:

: label domain-no dso entry-point path

باید درج شود. که در آن،

label: رشته‌ای است که عامل را مشخص می‌کند
domain-no: یک عدد صحیح بدون علامت در محدوده ۱ تا ۵۱۰ است که دامنه عامل را تعیین می‌کند
entry-point: نام تابع مقداردهی اولیه‌ای است که هنگام بارگذاری DSO فراخوانی می‌شود
path: مکان DSO را مشخص می‌کند و انتظار می‌رود یک نام مسیر مطلق باشد. pmcd تنها قادر است عامل‌های DSOای را بارگذاری کند که دارای همان simabi (مدل رابط زیربرنامه ABI، یا قواعد فراخوانی) یکسان با خودش باشند (یعنی تنها یکی از نسخه‌های simabi قابل اعمال خواهد بود). نسخه simabi یک pmcd در حال اجرا را می‌توان با واکشی pmcd.simabi تعیین کرد. همچنین، دستور file(1) می‌تواند برای تشخیص نسخه simabi از فایل اجرایی pmcd استفاده شود.

: برای یک path نسبی، متغیر محیطی PMCD_PATH فهرستی از دایرکتوری‌ها را که با دو‌نقطه (:) جدا شده‌اند، برای جستجو هنگام یافتن DSO عامل مشخص می‌کند. مسیر جستجوی پیش‌فرض $PCP_SHARE_DIR/lib:/usr/pcp/lib است.

برای عامل‌هایی که اتصالات سوکت فراهم می‌کنند، خطی به شکل زیر:

: label domain-no socket addr_family address [ command ]

باید درج شود. که در آن،

label: رشته‌ای است که عامل را مشخص می‌کند
domain-no: یک عدد صحیح بدون علامت در محدوده ۱ تا ۵۱۰ است که دامنه عامل را تعیین می‌کند
addr_family: مشخص می‌کند که آیا سوکت در دامنه AF_INET، AF_INET6 یا AF_UNIX است، و مقادیر متناظر برای این پارامتر به ترتیب inet، ipv6 و unix هستند.
address: آدرس سوکت را در addr_family تعیین‌شده قبلی مشخص می‌کند. برای سوکت‌های unix، آدرس باید نام سوکت یک عامل روی میزبان محلی باشد (یک آدرس معتبر برای دامنه UNIX). برای سوکت‌های inet و ipv6، آدرس می‌تواند یک شماره درگاه یا نام درگاهی باشد که جهت اتصال به عامل در میزبان محلی به کار می‌رود. هیچ ساختاری برای مشخص کردن عامل روی یک میزبان راه دور وجود ندارد زیرا pmcd تنها با عامل‌های موجود در همان رایانه کار می‌کند.
command: یک پارامتر اختیاری است که برای تعیین خط فرمانی جهت شروع عامل در هنگام مقداردهی اولیه pmcd به کار می‌رود. اگر command وجود نداشته باشد، pmcd فرض می‌کند که عامل مشخص‌شده از قبل ایجاد شده است. دستور command از اولین نویسه غیرفاصله پس از آدرس سوکت آغاز شده و در سطر جدید بعدی که قبل از آن بک‌اسلش نیامده باشد پایان می‌یابد. پس از یک fork(2) دستور command به طور دست‌نخورده به execve(2) ارسال می‌شود تا عامل نمونه‌سازی شود.

برای عامل‌هایی که از طریق stdin/stdout با pmcd تعامل دارند، خطی به شکل زیر:

: label domain-no pipe protocol command

باید درج شود. که در آن،.TP 14 label رشته‌ای است که عامل را مشخص می‌کند

domain-no: یک عدد صحیح بدون علامت است که دامنهٔ عامل را مشخص می‌کند
protocol: مقدار این پارامتر باید binary باشد.

: علاوه‌براین، protocol می‌تواند شامل کلیدواژهٔ notready باشد تا نشان دهد که عامل باید به‌عنوان آماده‌نبودن برای پردازش درخواست‌ها از pmcd علامت‌گذاری شود. عامل هنگامی که برای پردازش درخواست‌ها آماده باشد، با ارسال یک PDU از نوع PM_ERR_PMDAREADY به‌طور صریح به pmcd اطلاع می‌دهد. برای جزئیات بیشتر دربارهٔ این پروتکل، از جمله شرحی از پارامترهای IPC که می‌توان در یک اسکریپت Install مربوط به PMDA با پارامتر ipc_prot مشخص کرد، بخش مربوطه را در PMDA(3) ببینید.

command: خط فرمانی را برای راه‌اندازی عامل هنگام مقداردهی اولیهٔ pmcd مشخص می‌کند. توجه داشته باشید که command برای عامل‌های مبتنی بر پایپ الزامی است. در نظر گرفته می‌شود که command از نخستین نویسهٔ غیرفاصله پس از پارامتر protocol آغاز شده و در خط جدید بعدی که قبل از آن بک‌اسلش نیامده باشد خاتمه می‌یابد. پس از یک fork(2) پارامتر command به‌صورت دست‌نخورده به execve(2) ارسال می‌شود تا عامل را نمونه‌سازی کند.

پیکربندی کنترل دسترسی (ACCESS CONTROL CONFIGURATION)

بخش کنترل دسترسی فایل پیکربندی اختیاری است، اما در صورت وجود باید پس از داده‌های پیکربندی عامل قرار گیرد. بزرگی و کوچکی حروف در کلمات کلیدی رزروشده نادیده گرفته می‌شود، اما در سایر بخش‌ها حفظ می‌شود. عناصر واژگانی در بخش کنترل دسترسی با فاصله‌های خالی یا نویسه‌های جداکنندهٔ ویژه از یکدیگر جدا می‌شوند: براکت‌ها (``['' و ``]'')، آکولادها (``{'' و ``}'')، دونقطه (``:'')، نقطه‌ویرگول (``;'') و ویرگول (``,''). با این نویسه‌های ویژه در بخش پیکربندی عامل مانند نویسه‌های معمولی رفتار می‌شود. عناصر واژگانی در صورت نیاز می‌توانند داخل گیومه (نقل‌قول دوگانه) قرار گیرند.

بخش کنترل دسترسی فایل باید با خطی به این شکل آغاز شود:

[access]

علاوه بر (یا به‌جای) بخش access در فایل پیکربندی pmcd، مشخصات کنترل دسترسی همچنین از فایلی با همان نام فایل پیکربندی pmcd که پسوند '.access' به انتهای نام آن اضافه شده است خوانده می‌شود. این فایل اختیاری نباید حاوی کلیدواژهٔ [access] باشد.

فاصله‌های خالی ابتدا و انتها می‌توانند در اطراف و درون براکت‌ها قرار گیرند و بزرگی یا کوچکی حروف کلیدواژهٔ access نادیده گرفته می‌شود. هیچ متن دیگری به جز یک توضیح (کامنت) پایانی نمی‌تواند در این خط قرار گیرد.

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

دو نوع عملیات وجود دارد که از طریق pmcd رخ می‌دهد:

fetch: امکان بازیابی اطلاعات را از pmcd فراهم می‌کند. این ممکن است اطلاعاتی دربارهٔ یک متریک (مانند توضیحات، دامنهٔ نمونه، برچسب‌ها یا متن راهنما) یا مقداری برای یک متریک باشد. برای اطلاعات بیشتر pminfo(1) را ببینید.
store: امکان استفاده از pmcd را برای ذخیرهٔ مقادیر متریک در عامل‌هایی که عملیات ذخیره‌سازی را مجاز می‌دانند فراهم می‌کند. این ممکن است مقدار واقعی متریک باشد (مانند بازنشانی یک شمارنده به صفر). از طرف دیگر، ممکن است مقداری باشد که توسط PMDA برای اعمال تغییر در جنبه‌ای از پایش آن متریک استفاده می‌شود (مانند فیلتر کردن رویدادها در سمت سرور) - احتمالاً حتی فقط برای ابزار کلاینت فعالی که عملیات store را انجام می‌دهد، و نه سایرین. برای اطلاعات بیشتر pmstore(1) را ببینید.

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

نام‌های کاربری و نام‌های گروه با استفاده از فایل‌های محلی /etc/passwd و /etc/groups (یا یک سرویس دایرکتوری جایگزین) و با استفاده از روال‌های getpwent(3) و getgrent(3) تأیید خواهند شد.

میزبان‌ها ممکن است با نام، آدرس IP، آدرس IPv6 یا با مشخصه‌های ویژهٔ میزبان ``"unix:"'' یا ``"local:"'' شناسایی شوند. عبارت ``"unix:"'' به سوکت دامنهٔ یونیکس در pmcd روی پلتفرم‌های پشتیبانی‌شده اشاره دارد. عبارت ``"local:"'' معادل مشخص کردن هم‌زمان ``"unix:"'' و ``localhost`` است.

نویسه‌های عام (wildcard) را می‌توان با پایان دادن شناسهٔ میزبان با تک‌نویسهٔ عام ``*'' به‌عنوان آخرین مؤلفهٔ ارائه‌شده برای یک آدرس نیز مشخص کرد. نویسهٔ عام ``".*"'' به تمام آدرس‌های inet (IPv4) اشاره دارد. نویسهٔ عام ``":*"'' به تمام آدرس‌های IPv6 اشاره دارد. اگر یک نویسهٔ عام IPv6 شامل مؤلفهٔ ``::'' باشد، آنگاه ``*'' پایانی تنها به ۱۶ بیت پایانی آدرس اشاره می‌کند، در غیر این صورت به بیت‌های مشخص‌نشدهٔ باقی‌ماندهٔ آدرس اشاره دارد.

نویسهٔ عام ``*'' به همهٔ کاربران، گروه‌ها یا آدرس‌های میزبان، از جمله ``"unix:"'' اشاره دارد. نام‌های کاربران، گروه‌ها یا میزبان‌ها نمی‌توانند شامل نویسهٔ عام باشند.

موارد زیر همگی شناسه‌های میزبان معتبر هستند:

boing
localhost
giggle.melbourne.sgi.com
129.127.112.2
129.127.114.*
129.*
.*
fe80::223:14ff:feaf:b62c
fe80::223:14ff:feaf:*
fe80:*
:*
"unix:"
"local:"
*

موارد زیر شناسه‌های میزبان معتبر نیستند:

*.melbourne
129.127.*.*
129.*.114.9
129.127*
fe80::223:14ff:*:*
fe80::223:14ff:*:b62c
fe80*

مثال اول مجاز نیست زیرا فقط آدرس‌های IP (عددی) می‌توانند حاوی نویسهٔ عام باشند. مثال‌های دوم و پنجم نامعتبر هستند زیرا بیش از یک نویسهٔ عام در آن‌ها وجود دارد. مثال‌های سوم و ششم حاوی یک نویسهٔ عام در میانهٔ آدرس هستند، و مثال‌های چهارم و هفتم دارای نویسهٔ عامی هستند که آخرین مؤلفهٔ آدرس نیست (آخرین مؤلفه‌ها به ترتیب 127* و fe80* هستند).

با نام localhost به‌طور ویژه‌ای برخورد می‌شود تا رفتار استفاده از نویسه‌های عام میزبان سازگار باشد. به جای این‌که 127.0.0.1 و ::1 باشد، به آدرس‌های اصلی inet و IPv6 مرتبط با نام میزبانی که pmcd روی آن در حال اجرا است نگاشت می‌شود. هنگام اجرای pmcd روی میزبان‌های دارای چند رابط شبکه (multi-homed) مراقبت این نکته باشید..PP دسترسی برای کاربران، گروه‌ها یا میزبان‌ها با مشخص کردن عبارت‌هایی به این شکل مجاز یا غیرمجاز اعلام می‌شود:

: allow users userlist : operations ;
disallow users userlist : operations ;
allow groups grouplist : operations ;
disallow groups grouplist : operations ;
allow hosts hostlist : operations ;
disallow hosts hostlist : operations ;
list: userlist، grouplist و hostlist فهرست‌هایی جداشده با کاما از یک یا چند شناسهٔ کاربر، گروه یا میزبان هستند.
operations: فهرستی جداشده با کاما از انواع عملیات شرح‌داده‌شده در بالا، all (که همهٔ عملیات را مجاز/غیرمجاز می‌کند)، یا all except operations (که همهٔ عملیات را به جز موارد ذکرشده مجاز/غیرمجاز می‌کند) است.

استفاده از شکل جمع یا مفرد کلیدواژه‌های users، groups و hosts مجاز است. اگر این کلیدواژه حذف شود، مقدار پیش‌فرض hosts استفاده خواهد شد. این رفتار فقط برای سازگاری با گذشته است و ترجیح داده می‌شود که به‌صورت صریح مشخص گردد.

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

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

عبارت‌هایی با سطح یکسان از نویسه‌های عام (wildcarding) که میزبان‌های یکسانی را مشخص می‌کنند نباید با یکدیگر در تناقض باشند. به عنوان مثال، اگر میزبانی به نام clank دارای آدرس آی‌پی 129.127.112.2 باشد، تعیین دو قاعدهٔ زیر نادرست خواهد بود:

allow host clank : fetch, store;
disallow host 129.127.112.2 : all except fetch;

زیرا هر دو به یک میزبان اشاره دارند، اما در مورد اینکه آیا عملیات fetch از آن میزبان مجاز است یا خیر، اختلاف نظر دارند.

عبارت‌های حاوی مشخصات میزبانِ دقیق‌تر، عبارات کمتر مشخص را با توجه به سطح نویسه‌های عام باطل (override) می‌کنند. برای مثال، قاعده‌ای به شکل:

allow host clank : all;

این عبارت را لغو (override) می‌کند:

disallow host 129.127.112.* : all except fetch;

زیرا عبارت اول شامل یک نام میزبان مشخص (معادل یک آدرس آی‌پی کاملاً مشخص) است، در حالی که دومی دارای نویسهٔ عام است. به نوبهٔ خود، عبارت دوم نیز این عبارت را باطل می‌کند:

disallow host * : all;

محدود کردن تعداد اتصالات از یک کاربر، گروه یا میزبان به pmcd امکان‌پذیر است. این کار را می‌توان با افزودن بندی به شکل

: maximum n connections

به فهرست operations یک عبارت allow انجام داد. چنین بندی نباید در یک عبارت disallow استفاده شود. در اینجا، n حداکثر تعداد اتصالاتی است که از کاربر، گروه یا میزبان منطبق با شناسه‌(های) استفاده‌شده در عبارت پذیرفته خواهد شد.

یک عبارت کنترل دسترسی با فهرستی از شناسه‌های کاربر، گروه یا میزبان، معادل مجموعه‌ای از عبارت‌های کنترل دسترسی است که هر کدام یکی از شناسه‌های موجود در فهرست را مشخص می‌کنند و همگی دارای کنترل‌های دسترسی یکسان (هم مجوزها و هم محدودیت‌های اتصال) هستند. اگر می‌خواهید کاربران در یک محدودیت اتصال مشترک سهیم باشند، باید از یک گروه استفاده شود. اگر می‌خواهید میزبان‌ها در یک محدودیت اتصال مشترک سهیم باشند، باید از نویسهٔ عام استفاده شود.

هنگامی که یک کلاینت جدید درخواست اتصال می‌دهد و pmcd تشخیص می‌دهد که کلاینت اجازهٔ اتصال دارد، در فهرست عبارت‌های کنترل دسترسیِ منطبق جستجو می‌کند تا دقیق‌ترین تطابق حاوی محدودیت اتصال را پیدا کند. برای اختصار، این عبارت «عبارت محدودکننده» نامیده می‌شود. اگر عبارت محدودکننده‌ای وجود نداشته باشد، به کلاینت اجازهٔ اتصال داده می‌شود. اگر عبارت محدودکننده‌ای وجود داشته باشد و تعداد کلاینت‌های pmcd با شناسه کاربری (user ID)، شناسه گروهی (group ID) یا آدرس‌های آی‌پی منطبق بر شناسه در عبارت محدودکننده کمتر از سقف اتصال در آن عبارت باشد، اتصال مجاز خواهد بود. در غیر این صورت، سقف محدودیت اتصال پر شده است و از اتصال کلاینت ممانعت به عمل می‌آید.

کنترل دسترسی گروهی و نویسه‌های عام در شناسه‌های میزبان به این معناست که وقتی pmcd اتصالی را از یک کلاینت بپذیرد، این اتصال ممکن است در شمارش اتصالات فعلیِ بیش از یک عبارت کنترل دسترسی سهیم باشد - میزبان کلاینت ممکن است با بیش از یک عبارت کنترل دسترسی مطابقت داشته باشد و به همین ترتیب شناسه کاربری نیز ممکن است در بیش از یک گروه عضو باشد. این موضوع ممکن است برای درخواست‌های اتصال بعدی حائز اهمیت باشد.

توجه داشته باشید که pmcd به محض اضافه شدن یک بخش کنترل دسترسی کاربر یا گروه به پیکربندی، وارد حالتی می‌شود که در عمل با سطح بالاتری از امنیت اجرا می‌گردد. در این حالت فقط اتصالات احراز هویت‌شده مجاز هستند - چه از طریق یک اتصال احراز هویت‌شده با SASL، و چه از طریق یک Unix domain socket (که به صورت ضمنی اعتبارنامه‌های کلاینت را ارسال می‌کند). این همان حالتی است که می‌توان با استفاده صریح از گزینهٔ -S نیز وارد آن شد. با فرض مجاز بودن دسترسی، می‌توان با استعلام مقدار متریک pmcd.feature.creds_required تشخیص داد که آیا pmcd در این حالت در حال اجرا است یا خیر.

همچنین توجه داشته باشید که به دلیل استفاده از معناشناسیِ «دقیق‌ترین تطابق» در بررسی محدودیت اتصال، برای حالت کنترل دسترسی مبتنی بر میزبان، اولویت به کلاینت‌هایی با شناسه‌های میزبان خاص‌تر داده می‌شود. همچنین ممکن است در برخی شرایط از محدودیت‌های اتصال فراتر رفت. موارد زیر را در نظر بگیرید:

: allow host clank : all, maximum 5 connections;
allow host * : all except store, maximum 2 connections;

این عبارت بیان می‌کند که در هر زمان تنها ۲ اتصال کلاینت برای همهٔ میزبان‌ها به جز "clank" مجاز است که خود مجاز به ۵ اتصال می‌باشد. اگر ابتدا کلاینتی از میزبان "boing" به pmcd متصل شود، اتصال آن با عبارت دوم بررسی می‌شود (که دقیق‌ترین تطابق با یک سقف اتصال است). از آنجا که کلاینت دیگری وجود ندارد، اتصال پذیرفته شده و تنها در سقف عبارت دوم در بالا محاسبه می‌شود. اگر کلاینت بعدی از "clank" متصل شود، اتصال آن با سقف عبارت اول سنجیده می‌شود. هیچ اتصال دیگری از "clank" وجود ندارد، بنابراین اتصال پذیرفته می‌شود. به محض پذیرش این اتصال، به دلیل اینکه "clank" با شناسهٔ میزبان در هر دو عبارت مطابقت دارد، در سقف هر دو عبارت محاسبه می‌شود. به یاد داشته باشید که تصمیم‌گیری برای پذیرش اتصال جدید تنها بر اساس خاص‌ترین عبارت کنترل دسترسی منطبق که دارای محدودیت اتصال است انجام می‌گیرد. اکنون، محدودیت اتصال برای عبارت دوم تکمیل شده است. هرگونه اتصال از میزبان‌هایی غیر از "clank" رد خواهد شد.

اگر در عوض، pmcd بدون هیچ کلاینتی شاهد سه اتصال متوالی از "boing" بود، دو اتصال اول پذیرفته شده و سومی رد می‌شد. پس از آن، اگر درخواستی برای اتصال از سوی "clank" ارسال می‌شد، پذیرفته می‌شد؛ چرا که با عبارت اول مطابقت دارد که خاص‌تر از دومی است، بنابراین محدودیت اتصال در عبارت اول برای تعیین اینکه آیا کلاینت حق اتصال دارد یا خیر استفاده می‌شود. اکنون ۳ اتصال در محدودیت اتصال عبارت دوم سهیم هستند. حتی با وجود اینکه از سقف اتصال عبارت دوم فراتر رفته است، اتصالات پیشین از "boing" حفظ می‌شوند. محدودیت اتصال تنها در زمان تلاش کلاینت برای اتصال بررسی می‌شود، نه اینکه با هر بار اتصال یک کلاینت جدید به pmcd، مجدداً مورد ارزیابی قرار گیرد..PP این طرح منعطف به گونه‌ای طراحی شده است که اعمال محدودیت‌های معقول را بر اساس اولویت ورود (نوبت) و با استثناهای مشخص امکان‌پذیر سازد.

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

حصاربندی عامل (AGENT FENCING)

جلوگیری از نمونه‌برداری در طول حیات یک PMDA گاهی مطلوب است، برای مثال اگر آن نمونه‌برداری بر فازهای حساس یک کار زمان‌بندی‌شده تأثیر بگذارد. در چنین شرایطی می‌توان یک «حصار» موقت ایجاد کرد تا دسترسی تمام کلاینت‌های PMAPI را به یک یا چند عامل مسدود کند. این قابلیت توسط PMDA داخلی PMCD و دستور pmstore(1) ارائه می‌شود، مانند

# pmstore -i nfsclient,kvm pmcd.agent.fenced 1

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

# pmstore -i nfsclient,kvm pmcd.agent.fenced 0

برداشتن هم‌زمان حصار برای تمام PMDAها با استفاده از دستور زیر انجام می‌شود

# pmstore pmcd.agent.fenced 0

برای ذخیره مقدار در معیار pmcd.agent.fenced مجوزهای ارتقایافته (مدیر سیستم) مورد نیاز است. برای اطلاعات بیشتر، متن راهنمای مربوط به این معیار را ببینید که با استفاده از گزینه -T, --helptext در pminfo(1) قابل دسترسی است.

پیکربندی مجدد PMCD (RECONFIGURING PMCD)

اگر فایل پیکربندی تغییر کرده باشد یا عاملی به دلیل خاتمه یافتن پاسخ ندهد یا PMNS تغییر کرده باشد، pmcd می‌تواند با ارسال سیگنال SIGHUP مجدداً پیکربندی شود، مانند

# pmsignal -a -s HUP pmcd

هنگامی که pmcd یک SIGHUP دریافت می‌کند، فایل پیکربندی را برای تغییرات بررسی می‌نماید. اگر فایل تغییر کرده باشد، مجدداً تجزیه شده و محتویات آن به پیکربندی جدید تبدیل می‌شود. در صورت وجود خطا در فایل پیکربندی، همان پیکربندی قبلی حفظ شده و محتویات فایل نادیده گرفته می‌شود. خطاها در فایل لاگ pmcd گزارش می‌شوند.

همچنین فایل PMNS و هرگونه فایل برچسب‌ها را برای تغییرات بررسی می‌کند. اگر هر یک از این فایل‌ها تغییر کرده باشند، PMNS و/یا برچسب‌های زمینه دوباره بارگیری می‌شوند. استفاده از tail(1) روی فایل لاگ در هنگام پیکربندی مجدد pmcd توصیه می‌شود.

اگر پیکربندی یک عامل تغییر کرده باشد (هر پارامتری به جز برچسب عامل متفاوت باشد)، آن عامل دوباره راه‌اندازی می‌شود. عامل‌هایی که پیکربندی آن‌ها تغییر نکرده است دوباره راه‌اندازی نمی‌شوند. هر عامل موجودی که در پیکربندی جدید وجود نداشته باشد، خاتمه می‌یابد. هر عامل از کار افتاده‌ای که هنوز در فهرست باشد، مجدداً راه‌اندازی می‌شود.

گاهی اوقات راه‌اندازی مجدد عاملی که هنوز در حال اجراست اما دچار اختلال شده، ضروری است. به سادگی عامل را متوقف کنید (مثلاً با استفاده از SIGTERM از pmsignal(1))، سپس یک SIGHUP به pmcd ارسال کنید که باعث راه‌اندازی مجدد عامل خواهد شد.

راه‌اندازی و توقف PMCD (STARTING AND STOPPING PMCD)

به طور معمول، pmcd به صورت خودکار هنگام بالا آمدن سیستم راه‌اندازی شده و هنگام خاموش شدن سیستم متوقف می‌شود. تحت شرایط خاصی، راه‌اندازی یا توقف دستی pmcd لازم است. برای این کار باید دسترسی مدیر سیستم (superuser) را به دست آورده و برای شروع pmcd فرمان زیر را وارد کنید

# $PCP_RC_DIR/pmcd start

یا برای متوقف ساختن pmcd:

# $PCP_RC_DIR/pmcd stop

راه‌اندازی pmcd در حالی که از قبل در حال اجراست، همانند توقف و سپس راه‌اندازی دوباره آن است.

گاهی اوقات ممکن است راه‌اندازی مجدد pmcd در فاز دیگری از فرآیند بوت لازم باشد. بخش‌های زمان‌بر فرآیند بوت اغلب در پس‌زمینه قرار داده می‌شوند تا سیستم زودتر در دسترس قرار گیرد (مانند سوار کردن پایگاه‌های داده حجیم). اگر عاملی که توسط pmcd اجرا می‌شود نیازمند تکمیل چنین وظیفه‌ای قبل از اجرای صحیح خود باشد، لازم است پس از تکمیل کار، pmcd راه‌اندازی مجدد یا دوباره پیکربندی شود. برای مثال، مورد سوار کردن یک پایگاه داده در پس‌زمینه را هنگام بوت در نظر بگیرید. اگر PMDA که معیارهای مربوط به پایگاه داده را ارائه می‌دهد نتواند تا زمان سوار شدن و در دسترس قرار گرفتن پایگاه داده عمل کند، اما pmcd پیش از آماده شدن پایگاه داده اجرا شود، PMDA شکست خواهد خورد (با این حال pmcd همچنان به درخواست‌های معیارها از دامنه‌های دیگر پاسخ خواهد داد). اگر پایگاه داده با اجرای یک شل‌اسکریپت مقداردهی اولیه شود، اضافه کردن یک خط به انتهای اسکریپت برای پیکربندی مجدد pmcd (از طریق ارسال SIGHUP به آن) باعث راه‌اندازی مجدد PMDA خواهد شد (در صورتی که به دلیل عدم توانایی در اتصال به پایگاه داده خارج شده باشد). اگر PMDA در چنین شرایطی خارج نشده باشد، راه‌اندازی مجدد pmcd ضروری خواهد بود زیرا اگر PMDA هنوز در حال اجرا باشد، pmcd آن را دوباره راه‌اندازی نخواهد کرد.

به طور معمول pmcd روی پورت شماره 44321 پروتکل TCP/IP به اتصالات کلاینت گوش می‌دهد (ثبت‌شده در http://www.iana.org). می‌توان از متغیر محیطی PMCD_PORT یا گزینه خط فرمان -p برای مشخص کردن شماره پورت(های) جایگزین در هنگام شروع pmcd استفاده کرد؛ در هر حالت، مشخص‌سازی به صورت فهرستی از یک یا چند شماره پورت عددی جداشده با کاما است. در صورتی که از هر دو روش استفاده شود یا چندین گزینه -p در خط فرمان ظاهر شود، pmcd به اجتماع مجموعه پورت‌های مشخص‌شده از طریق تمام گزینه‌های -p و متغیر محیطی PMCD_PORT گوش فرا خواهد داد. اگر پورت‌های غیرپیش‌فرض برای pmcd استفاده می‌شوند، باید دقت شود تا اطمینان حاصل گردد که PMCD_PORT در محیط هر برنامه کلاینتی که قرار است به pmcd متصل شود نیز تنظیم شده باشد، یا اینکه از ساختار نحوی گسترش‌یافته مشخص‌سازی میزبان استفاده شود (برای جزئیات بیشتر به PCPIntro(1) مراجعه کنید)..SH "هشدارها (CAVEATS)" pmcd فرزندان خود (عامل‌ها یا agents) را به‌طور صریح خاتمه نمی‌دهد، بلکه فقط لوله‌های (pipes) آن‌ها را می‌بندد. اگر عاملی هرگز بسته شدن لوله را بررسی نکند، ممکن است خاتمه نیابد.

تجزیه‌کنندهٔ فایل پیکربندی تنها خطوط با کمتر از ۱۲۰۰ نویسه را می‌خواند. هدف از این کار جلوگیری از بروز حوادث ناخواسته با فایل‌های باینری است.

مهلت‌های زمانی کنترل‌شده توسط گزینهٔ -t بر ارتباطات بین‌فرایندی (IPC) میان pmcd و PMDAهایی که ایجاد می‌کند، اعمال می‌شوند. این موضوع مستقل از تنظیمات متغیرهای محیطی PMCD_CONNECT_TIMEOUT و PMCD_REQUEST_TIMEOUT است (ببینید PCPIntro(1)) که می‌توانند به ترتیب برای کنترل مهلت‌های زمانی برنامه‌های کلاینت در تلاش برای اتصال به pmcd و تلاش برای دریافت اطلاعات از pmcd استفاده شوند.

خطاها (DIAGNOSTICS)

اگر pmcd از قبل در حال اجرا باشد، پیام “Error: OpenRequestSocket bind: Address may already be in use” ظاهر خواهد شد. این پیام همچنین ممکن است زمانی ظاهر شود که pmcd در حالی که یک درخواست معلق از سوی کلاینت وجود داشته است، متوقف شده باشد. در این حالت، یک سوکت درخواست در وضعیت TIME_WAIT باقی مانده است و تا زمانی که سیستم آن را نبندد (پس از سپری شدن دورهٔ مهلت زمانی)، اجرای مجدد pmcd امکان‌پذیر نخواهد بود.

علاوه بر پرچم‌های استاندارد اشکال‌زدایی PCP، ببینید pmdbg(1)، pmcd در حال حاضر از این گزینه‌ها استفاده می‌کند: appl0 برای ردگیری I/O و خاتمه یافتن عامل‌ها، appl1 برای ردگیری کنترل دسترسی و appl2 برای ردگیری پویشگر و تجزیه‌کنندهٔ فایل پیکربندی.

فایل‌ها (FILES)

$PCP_PMCDCONF_PATH: فایل پیکربندی پیش‌فرض
$PCP_PMCDCONF_PATH.access: فایل اختیاری مشخصات کنترل دسترسی
$PCP_PMCDOPTIONS_PATH: گزینه‌های خط فرمان برای pmcd هنگامی که از طریق $PCP_RC_DIR/pmcd راه‌اندازی می‌شود. تمام خطوط گزینه‌های خط فرمان باید با یک خط‌تیره (-) به عنوان نویسهٔ اول آغاز شوند.
$PCP_SYSCONFIG_DIR/pmcd: متغیرهای محیطی که هنگام اجرای pmcd تنظیم خواهند شد. تنها تنظیماتی با قالب “PMCD_VARIABLE=value” یا “PCP_VARIABLE=value” پذیرفته می‌شوند.
$PCP_SYSCONF_DIR/labels.conf: تنظیمات مربوط به برچسب‌های استفاده‌شده به‌طور سراسری در سرتاسر PMCS.
$PCP_SYSCONF_DIR/labels: دایرکتوری فایل‌های حاوی برچسب‌های سراسری متریک که برای هر context کلاینت ایجاد شده توسط pmcd تنظیم خواهند شد. نام فایل‌هایی که با “.” شروع می‌شوند نادیده گرفته می‌شوند، و فایل‌هایی که به “.json” ختم می‌شوند، جفت‌های name:value با قالب “JSONB” هستند. مجموعهٔ ادغام‌شده را می‌توان از طریق متریک pmcd.labels پرس‌وجو کرد. برچسب‌های context به‌صورت سراسری بر روی تمام متریک‌ها اعمال می‌شوند.
$PCP_SYSCONF_DIR/labels/optional: دایرکتوری فایل‌های حاوی برچسب‌های سراسری متریک که برای هر context کلاینت ایجاد شده توسط pmcd تنظیم خواهند شد، اما به‌عنوان اختیاری نشانه‌گذاری شده‌اند. این برچسب‌ها دقیقاً همانند سایر برچسب‌های context هستند، به جز اینکه در محاسبات شناسهٔ سری‌های زمانی استفاده نمی‌شوند.
./pmcd.log: (یا $PCP_LOG_DIR/pmcd/pmcd.log هنگامی که به‌طور خودکار راه‌اندازی شود)
تمام پیام‌ها و گزارش‌های عیب‌یابی به اینجا هدایت می‌شوند.
$PCP_RUN_DIR/pmcd.pid: شامل یک نمایش ده‌دهی اسکی از شناسهٔ فرایند (PID) pmcd، در زمان اجرای آن است.
/etc/pcp/tls.conf: فایل اطلاعات پیکربندی گواهی OpenSSL، مورد استفاده برای اتصالات اختیاری لایه سوکت امن (Secure Socket Layer).
/etc/passwd: نام‌های کاربری، شناسه‌های کاربری و شناسه‌های گروه اصلی، مورد استفاده برای مشخصات کنترل دسترسی
/etc/groups: نام‌های گروه، شناسه‌های گروه و اعضای گروه، مورد استفاده برای مشخصات کنترل دسترسی

محیط (ENVIRONMENT)

متغیرهای زیر در $PCP_SYSCONFIG_DIR/pmcd تنظیم می‌شوند.

علاوه بر متغیرهای محیطی PCP شرح داده شده در بخش PCP ENVIRONMENT در زیر، متغیر PMCD_PORT نیز به عنوان درگاه TCP/IP برای اتصالات ورودی شناخته می‌شود (پیش‌فرض 44321)، و متغیر PMCD_SOCKET نیز به عنوان مسیری که باید برای سوکت دامنه یونیکس استفاده شود، شناسایی می‌شود.

در صورت تنظیم روی مقدار 1، متغیر محیطی PMCD_LOCAL باعث می‌شود که pmcd در یک حالت عملیاتی فقط-localhost اجرا شود، به‌طوری که تنها به رابط loopback متصل (bind) می‌شود. متریک pmcd.feature.local را می‌توان پرس‌وجو کرد تا مشخص شود آیا pmcd در این حالت در حال اجرا است یا خیر.

متغیر PMCD_MAXPENDING را می‌توان برای مشخص کردن حداکثر طولی که صف اتصالات معلق کلاینت ممکن است رشد کند، تنظیم کرد.

متغیر PMCD_ROOT_AGENT کنترل می‌کند که آیا pmcd یا pmdaroot (در صورت در دسترس بودن)، PMDAهای بعدی را راه‌اندازی کنند یا خیر. هنگامی که روی یک مقدار غیر صفر تنظیم شود، pmcd انتخاب می‌کند که راه‌اندازی و توقف PMDAها توسط pmdaroot انجام شود.

متغیر PMCD_RESTART_AGENTS رفتار pmcd را در مواجهه با PMDAهای فرزندی که خروج آن‌ها مشاهده شده است مشخص می‌کند (این یک واکنش معمول در هنگام تأخیرهای بسیار بزرگ PDU است که معمولاً ناشی از دامنه هستند). هنگامی که روی مقداری غیر صفر تنظیم شود، pmcd تلاش خواهد کرد تا چنین PMDAهایی را یک بار در هر دقیقه بازراه‌اندازی کند. هنگامی که روی صفر تنظیم شود، از رفتار اصلی مبنی بر صرفاً ثبت گزارش خرابی استفاده می‌کند..SH "محیط PCP (PCP ENVIRONMENT)" متغیرهای محیطی با پیشوند PCP_ برای پارامتریک‌سازی نام فایل‌ها و دایرکتوری‌های مورد استفاده توسط PCP به کار می‌روند. در هر نصب، فایل /etc/pcp.conf حاوی مقادیر محلی برای این متغیرها است. متغیر $PCP_CONF ممکن است برای تعیین یک فایل پیکربندی جایگزین استفاده شود، همان‌طور که در pcp.conf(5) شرح داده شده است.

برای متغیرهای محیطی مؤثر بر ابزارهای PCP، به pmGetOptions(3) مراجعه کنید.

گزینه‌های اشکال‌زدایی (DEBUGGING OPTIONS)

گزینهٔ -D یا --debug خروجی اطلاعات عیب‌یابی اضافی را در stderr برای کمک به تفکیک و بررسی مشکلات فعال می‌کند، اگرچه این اطلاعات گاهی مبهم بوده و در درجهٔ اول برای ارائهٔ راهنمایی به توسعه‌دهندگان در نظر گرفته شده‌اند تا کاربران نهایی. مقدار debug یک فهرست جداشده با کاما از گزینه‌های اشکال‌زدایی است؛ از pmdbg(1) با گزینهٔ -l برای دریافت فهرستی از گزینه‌های اشکال‌زدایی موجود و معانی آن‌ها استفاده کنید.

گزینه‌های اشکال‌زدایی مخصوص pmcd به شرح زیر هستند:

گزینه	توضیحات
appl0	عملیات در سطح PDU
appl1	مشخصات کنترل دسترسی از فایل پیکربندی
appl2	پویشگر واژگانی در تجزیه‌کنندهٔ فایل پیکربندی
appl3	اتصال‌ها و قطع اتصال‌های کلاینت
appl4	برچسب‌های زمانی برای تجزیهٔ فایل پیکربندی
appl5	عملیات ویژگی‌ها (attribute)
appl6	تغییرات وضعیت سراسری و PMDA

همچنین ببینید (SEE ALSO)

PCPIntro(1)، pmdbg(1)، pmerr(1)، pmgenmap(1)، pminfo(1)، pmrep(1)، pmstat(1)، pmstore(1)، pmval(1)، getpwent(3)، getgrent(3)، labels.conf(5)، pcp.conf(5)، pcp.env(5) و PMNS(5).