لماذا يظهر تذكير VPN البالغ 23 ساعة للجلسة الخطأ
ينبغي أن يتبع إشعار الـ23 ساعة جلسةً واحدة، لا الحساب. اربط المؤقّت بالاتصال الذي بدأه، وعالِج السبات وإعادة الاتصال كحالتين منفصلتين.
ظهر الإشعار بعد عشرين دقيقة من الاتصال. وكان العدّاد أسفله يعمل منذ صباح اليوم السابق، أو منذ آخر مصادقة للحساب، ولم يقل شيء في التنبيه أيهما. هذا هو العَرَض: تذكير مربوط بشيء غير الاتصال الذي أمامك.
الحل ليس تنبيهًا أفضل. الحل هو تحديد أي ساعة يقصدها المتطلب، ثم ربط المؤقّت بكائن موجود في تلك الساعة.
ما الذي انطلق، وما الذي كان يعدّه
ثلاثة مصادر محتملة تنتج الرسالة نفسها. قاعدة تقويم تعمل في وقت محلي ثابت ولا تعرف شيئًا عن الأنفاق. وعدّاد في العميل يتراكم ما دام أي اتصال قائمًا ويصمد أمام إعادات الاتصال. وسياسة بوابة تُنهي الجلسة من جهة الخادم وتدفع تحذيرًا قبل ذلك.
المصدران الأخيران فقط يتعلقان بجلسة، وهما أيضًا لا يتفقان. عدّاد العميل يقيس ما لاحظته العملية المحلية؛ والبوابة تقيس ما صادقته وما حسبته. والسبات أو تغيّر الشبكة أو إعادة تشغيل المراقب يمكن أن يفصل بينهما بساعات، ولهذا ينحرف التنبيه عن الانتهاء المفروض.
ثلاث ساعات خلف متطلب واحد
ابدأ بكتابة الجملة التي تريدها فعلًا. التحذير قبل أن تُنهي البوابة هذا الاتصال ليس المتطلب نفسه الذي هو التذكير بعد يوم من وقت الاتصال. ولا هو نفسه الإبلاغ بأن هذه الجلسة قائمة منذ 23 ساعة. كل صيغة تسمّي حدثًا مختلفًا، وعلى مكوّن مختلف أن يجيب عنه.
ثم تحقق من وجود البيانات. طابع زمني محلي للبداية يمنحك عمر الجلسة دون أي اعتماد على الخادم. سياسة بوابة تمنحك العمر المتبقي، لكن فقط إذا كانت البوابة تكشف عنه. تقرير استخدام يمنحك المدة بعد وقوعها، وهذا لا يمكن أن يقود إشعارًا مسبقًا.
اربط المؤقّت بالجلسة، لا بالحساب
اختر الكائن أولًا. يمكن أن يحمل الحساب عدة أجهزة وعدة جلسات متزامنة، لذا لا يستطيع تذكير مربوط باسم المستخدم أن يحدد أي اتصال بلغ العمر. اربطه بالملف الشخصي مع ذلك التنشيط، وألغِ الإشعار المعلّق عندما ينتهي التنشيط.
| Evidence you can read | What it establishes | Where it misleads |
|---|---|---|
| Connection state changes to active | A session started now | Does not carry the gateway's own session identifier |
| Duration reported at disconnect | Total service time for that session | Arrives too late for any advance notice |
| Interim usage update | Time accounted up to that update | Staleness equals the update interval |
| Local timestamp taken at activation | Age of your observation | Resets whenever the observer restarts |
ذلك الجدول عقد لأداة الإشعار الخاصة بك، وليس وصفًا لواجهة رد نداء أي عميل. وأي شيء يوثّقه المنتج المثبّت عن حالة الاتصال هو المصدر الذي تربط به؛ وحيث لا يكشف إلا أحداث المصادقة، فقُل ذلك صراحة واقبل السلوك الأخشن بدلًا من استنتاج جلسة.
اختبره بعتبة قصيرة
لا تصلح أبدًا مؤقّتًا يمتد يومًا بانتظار يمتد يومًا. أضف عتبة قابلة للضبط، واضبطها على ثلاثين ثانية، ونفّذ أربعة انتقالات بالترتيب: اتصل، انتظر، افصل، أعد الاتصال. يجب أن ينتج كل انتقال تغيّر حالة واحدًا بالضبط، ويجب أن تجدول إعادة الاتصال موعدًا جديدًا بدلًا من أن ترث القديم.
# current connection state and profile identity
nmcli -f GENERAL.STATE,GENERAL.CONNECTION connection show work
# the notifier unit you wrote: does it restart the deadline or resume it?
journalctl --user -u vpn-timer.service --since "-5 min" -o catراقب الطوابع الزمنية لا الصياغة. الإشعار الذي يصل حاملًا وقت بداية الجلسة السابقة ربط الكائن الخطأ، والإشعار الذي يصل مرتين لموعد واحد يعني أن علامة الإرسال لم تُحفظ قط.
السبات وإعادة الاتصال والتسليم الفائت
السبات يكسر التصميمين الساذجين. العدّ التنازلي الرتيب يتوقف أثناء سبات الجهاز، والموعد المبني على ساعة الحائط يستمر في التقدم، والمؤقّت الذي ينطلق أثناء السبات يُسلَّم متأخرًا أو لا يُسلَّم أبدًا. قرر أي سلوك يحتاجه متطلبك، ثم أدخل الجهاز في السبات عبر العتبة وتأكد.
التسليم يستحق العناية نفسها. إذا تعذّر عرض الإشعار، فضعْه في قائمة انتظار، وأعد التحقق من أن الجلسة المستهدفة ما زالت موجودة قبل عرضه أخيرًا؛ وإلا حُذّر المستخدم من اتصال انتهى بالفعل. يبقى الفصل القسري وتجديد بيانات الاعتماد خارج هذا المسار، لأن تذكيرًا يغيّر مصير الاتصال بهدوء هو قرار سياسة يلبس ثوب إشعار.