VPS-এ live kernel patching নাকি reboot, কোনটি দরকার?

একটি VPS-এ live kernel patching কী করে

Live kernel patching চালু থাকা মেশিনে kernel-এর security fix প্রয়োগ করে। এতে reboot লাগে না এবং connection বিচ্ছিন্ন হয় না। সংশোধিত কোনো function-এর copy kernel module হিসেবে load হয়। এরপর পুরোনো function-এ করা প্রতিটি call নতুন copy-তে redirect করা হয়, আর server network traffic পরিবেশন করতে থাকে। এই প্রক্রিয়াই দেখায় live patching কোন কাজে কার্যকর এবং কোন কাজ এটি করতে পারে না।

এটি সময় দেয়। তবে reboot-এর প্রয়োজনীয়তা দূর করে না। কোনো server ছয় মাস ধরে live patched থাকলেও disk-এর পুরোনো kernel image দিয়েই boot করা থাকে। ওই সব patch কেবল memory-তেই থাকে।

Live patching-কে প্রায়ই managed plan-এর একটি feature হিসেবে বিক্রি করা হয়। unmanaged server-এ আপনি নিজেই দুটি command দিয়ে এটি enable করতে পারেন। তাই managed এবং unmanaged VPS-এর পার্থক্যের জন্য অতিরিক্ত অর্থ দেওয়ার আগে বিষয়টি জানা দরকার।

লাইভ kernel patching কীভাবে কাজ করে?

Kernel-এ একটি built-in live patching core রয়েছে, যা CONFIG_LIVEPATCH-এর সঙ্গে compile করা হয়। চলমান kernel-এ এটি আছে কি না পরীক্ষা করুন:

grep CONFIG_LIVEPATCH /boot/config-$(uname -r)

CONFIG_LIVEPATCH=y লেখা একটি line-এর অর্থ হলো, আপনি যে kernel চালাচ্ছেন সেটি এই core-সহ build করা হয়েছে। এটি না থাকলে ওই machine-এ কোনো live patching service কাজ করতে পারবে না।

এই redirection নিজেই kernel-এর function tracer ftrace ব্যবহার করে। বেশিরভাগ kernel function-এর একেবারে শুরুতে, argument বা stack ব্যবহৃত হওয়ার আগে, একটি call instruction compile করা থাকে। Ftrace এই call site-কে hook হিসেবে ব্যবহার করে। কোনো patch প্রয়োগ হলে live patching core target function-এ একটি ftrace handler register করে। এরপর handler execution-কে replacement function-এ পাঠায়। Kernel documentation বিষয়টি সরাসরি বলেছে: "Livepatching typically needs to redirect the code at the very beginning of the function entry before the function parameters or the stack are in any way modified."

এই বক্তব্য থেকে দুটি গুরুত্বপূর্ণ বিষয় বোঝা যায়। পরে উভয়টির প্রভাব দেখা যাবে। যে function-এ ftrace hook বসাতে পারে, শুধু সেটিই patch করা যায়। তাই entry call ছাড়া compile করা কোনো function একেবারেই patch করা যায় না। আর patching-এর unit হলো সম্পূর্ণ একটি function; কোনো function-এর ভেতরের একটি line নয়।

চলমান system নিরাপদে switch করাই কঠিন অংশ। Function বদলানোর সময় কোনো CPU-এর stack-এ যদি পুরোনো code চলতে থাকে, তাহলে পুরোনো ও নতুন আচরণের মিশ্রণ তৈরি হবে। Upstream Linux এটি per-task consistency model ব্যবহার করে সামলায়। Kernel documentation-এ এটিকে একটি hybrid model হিসেবে বর্ণনা করা হয়েছে: "it uses kGraft's per-task consistency and syscall barrier switching combined with kpatch's stack trace switching." Task-গুলো একবারে একটি করে নতুন code-এ যায়, এবং কেবল তখনই যায় যখন kernel নিশ্চিত করতে পারে যে task-টি বর্তমানে patched function-এর ভেতরে নেই। প্রতিটি task নতুন code-এ না যাওয়া পর্যন্ত patchটি transition অবস্থায় থাকে।

আপনি নিজেই ফলাফল দেখতে পারেন। প্রয়োগ করা patch-গুলো /sys/kernel/livepatch-এর অধীনে দেখা যায়। প্রতিটি patch-এর জন্য একটি directory থাকে এবং তার ভেতরে patched function-গুলোর তালিকা থাকে।

ls /sys/kernel/livepatch/

কোনো entry না থাকলে memory-তে কোনো live patch loaded নেই। নতুন server-এর ক্ষেত্রে এটিই স্বাভাবিক starting state।

লাইভ kernel patching যে সমস্যাগুলো সমাধান করতে পারে না

শুধু function body patch করা হয়। অন্য কিছু করা হয় না।

• পরিবর্তিত data structure। Upstream fix কোনো struct-এ নতুন field যোগ করলে বা বিদ্যমান field-এর অর্থ পরিবর্তন করলে আগে থেকেই বরাদ্দ করা এবং ব্যবহৃত object নিরাপদে পুনর্লিখনের কোনো উপায় নেই। kpatch project সমতুল্য বিষয়টি সরাসরি জানায়: "Patches which modify statically allocated data are not directly supported." Shadow variable এবং callback workaround হিসেবে ব্যবহার করা যায়, তবে প্রতিটি patch-এর জন্য এগুলো হাতে লিখতে হয়; স্বয়ংক্রিয়ভাবে তৈরি হয় না।
• একসঙ্গে একাধিক function-এ ছড়িয়ে থাকা fix। একাধিক function-এর মধ্যে lock ordering পরিবর্তন করা কোনো fix কার্যকর করতে হলে সব function-কে একসঙ্গে পরিবর্তন করতে হয়। এ ক্ষেত্রে পুরো machine-কে একই মুহূর্তে freeze না করে consistency model task পরিবর্তন করে।
• Initialisation code। __init দিয়ে চিহ্নিত function আপনার server চালু হওয়ার আগেই চলে এবং free হয়ে যায়। তাই redirect করার মতো কিছু অবশিষ্ট থাকে না।
• নতুন kernel version এবং নতুন feature। Live patching আপনাকে একটি kernel series-এর মধ্যে এক patch level থেকে অন্য patch level-এ নিয়ে যায়। এটি কখনও এক series থেকে অন্য series-এ নিয়ে যায় না এবং কোনো feature যোগ করে না। নতুন series-এর কোনো feature, যেমন Linux 7.1-এ যুক্ত হওয়া পরিবর্তনগুলো, প্রয়োজন হলে সেই kernel install করে boot করুন।
• Userspace। Canonical সীমাটি স্পষ্টভাবে জানায়: "Canonical Livepatch does not patch userspace libraries like OpenSSL or glibc, because that is the responsibility of unattended-upgrades or a systems management tool." পুরোনো OpenSSL-এর পাশে live patched kernel থাকলেই server patched হয় না। তাই একই box-এ userspace package সামলানোর দায়িত্ব unattended upgrades-কে দিন।

Ubuntu-এর service-এ severity-এরও একটি সীমা আছে। Canonical জানায়, এটি "patches kernel vulnerabilities with critical and high Common Vulnerability Scoring System (CVSS) and Ubuntu Priority ratings." একটি CVE (common vulnerabilities and exposures) identifier একটি flaw নির্দেশ করে, আর CVSS হলো সেই flaw-এর সঙ্গে যুক্ত score। Medium-rated kernel CVE disk-এর package-এ fix করা হয়, কিন্তু live patch করা হয় না। তাই এটি আপনার running kernel-এ পরবর্তী reboot-এর সময় প্রয়োগ হবে, তার আগে নয়।

লাইভ kernel patching-এর কী কী বিকল্প আছে?

সাধারণভাবে ব্যবহৃত তিনটি ধারার সমাধান আছে। এগুলো সব একই kernel machinery ব্যবহার করে।

Canonical Livepatch Ubuntu Pro-এর মাধ্যমে দেওয়া হয়। ব্যক্তিগত ব্যবহারের জন্য Ubuntu Pro বিনামূল্যে। Canonical-এর ভাষায়, এটি "is and always will be free for personal use on up to 5 physical machines"। Official Ubuntu Community সদস্যদের জন্য এই সীমা 50 machines পর্যন্ত। August 2026 অনুযায়ী এটিই নথিভুক্ত সীমা। বাণিজ্যিক ব্যবহারের জন্য paid subscription প্রয়োজন। Coverage প্রতিটি kernel series এবং flavour অনুযায়ী দেওয়া হয়। এতে supported long term support (LTS) release-এর general availability (GA) kernel এবং তাদের hardware enablement (HWE) kernel অন্তর্ভুক্ত থাকে। generic, aws, azure, gcp, oracle, ibm এবং lowlatency-এর মতো flavour-ও এর আওতায় পড়ে। কোনো kernel-এর ওপর নির্ভর করার আগে Canonical প্রকাশিত kernel list-এর সঙ্গে আপনার kernel মিলিয়ে দেখুন।

KernelCare, যা TuxCare-এর পণ্য, একটি commercial agent। এটি অনেক distribution সমর্থন করে, যার মধ্যে first-party service না থাকা distribution-ও আছে। নথিভুক্ত installation পদ্ধতিতে vendor script, curl -s -L https://kernelcare.com/installer | bash, চালাতে হয়। এরপর key-based licence-এর জন্য /usr/bin/kcarectl --register KEY ব্যবহার করতে হয়। Agent নিজস্ব schedule অনুযায়ী নতুন patch পরীক্ষা করে। /usr/bin/kcarectl --update ব্যবহার করলে তাৎক্ষণিকভাবে পরীক্ষা শুরু হয়। গুরুত্বপূর্ণ server-এ shell-এ pipe করার আগে installer-টি পড়ে নিন।

kpatch এবং kGraft হলো পূর্ববর্তী প্রকল্প। kGraft এসেছে SUSE থেকে এবং kpatch এসেছে Red Hat থেকে। বর্তমান upstream Linux-এর live patching core এই দুই ধারণার সমন্বয়। kpatch নিজে ধীরে ধীরে বন্ধ হয়ে যাচ্ছে। এর README-তে বলা হয়েছে, Linux 6.19 থেকে "the kpatch project is deprecated and in maintenance mode"। Upstream kernel-এ kpatch-build-এর পরিবর্তে klp-build ব্যবহার করা হচ্ছে। RHEL এবং তার rebuild-গুলোর ক্ষেত্রে নিজে patch তৈরি না করে distribution-এর নিজস্ব service ব্যবহার করুন।

আপনার distribution কী সমর্থন করে এবং আপনার licence কী অনুমতি দেয়, তার ভিত্তিতে পছন্দ করুন। প্রতিটি ক্ষেত্রেই kernel-level ফলাফল একই।

Ubuntu-তে Canonical Livepatch কীভাবে সক্রিয় করবেন

প্রথমে আপনার Ubuntu Pro account page থেকে একটি token নিন। নিচের দুটি command চালানোর জন্য কার্যকর outbound network access প্রয়োজন, কারণ client সংযুক্ত হতে এবং patch সংগ্রহ করতে Canonical-এর server-এর সঙ্গে যোগাযোগ করে।

sudo pro attach TOKEN
sudo pro status

কোনো token ছাড়া sudo pro attach চালালে browser-based flow শুরু হয় এবং Canonical-এর site-এ প্রবেশ করানোর জন্য একটি code দেখায়। Attach করার সময় প্রস্তাবিত service-গুলো স্বয়ংক্রিয়ভাবে সক্রিয় হয়। বর্তমান LTS release-এ এর মধ্যে Livepatch অন্তর্ভুক্ত থাকে। আপনি নিজে service বেছে নিতে চাইলে sudo pro attach --no-auto-enable ব্যবহার করুন।

Livepatch ইতিমধ্যে সক্রিয় না থাকলে:

sudo pro enable livepatch
sudo canonical-livepatch status

Service-টি canonical-livepatch snap থেকে চলে। তাই enable ধাপ সম্পূর্ণ হওয়ার জন্য snapd কার্যকর থাকতে হবে। pro status entitlement এবং status-সহ service-গুলোর একটি table দেখায়। canonical-livepatch status প্রতিটি kernel-এর বিস্তারিত তথ্য দেখায়। Canonical-এর documentation-এ এই ধরনের output দেখানো হয়েছে:

last check: 52 seconds ago
kernel: 5.4.0-216.236-generic
server check-in: succeeded
kernel state: ✓ kernel series 5.4 is covered by Livepatch
patch state: ✓ all applicable livepatch kernel modules applied
patch version: 113.1

দুটি line-ই উত্তর দেয়। kernel state দেখায় আপনি যে series চালাচ্ছেন, সেটি service দ্বারা আদৌ covered কি না। আপনি এমন কোনো kernel boot করলে, যেটি Livepatch support করে না, এই line-টির status ব্যর্থ দেখাবে। patch state দেখায় ওই kernel-এর জন্য প্রযোজ্য patch সত্যিই loaded হয়েছে কি না। Covered kernel-এ কোনো patch apply না হলে এটি client-এর সমস্যা। Uncovered kernel হলে এটি kernel-এর সমস্যা, এবং কোনো client setting দিয়ে তা ঠিক করা যায় না।

কীভাবে বুঝব যে reboot করা বাকি আছে?

Live patching জরুরি অবস্থা দূর করে। তাই reboot বাকি থাকলেও তা আর সহজে বোঝা যায় না। এটি খুঁজে দেখতে হবে।

ls -l /var/run/reboot-required
cat /var/run/reboot-required.pkgs

কোনো installed package কার্যকর করতে restart প্রয়োজন হলে package manager /var/run/reboot-required তৈরি করে। নতুন linux-image package ইনস্টল হলেও এটি তৈরি হয়। কোন package reboot চেয়েছে, তা .pkgs file-এ তালিকাভুক্ত থাকে। প্রথম command-এর উত্তর যদি No such file or directory হয়, তাহলে মেশিনটি শেষবার boot হওয়ার পর কোনো package reboot চায়নি। বর্তমান Ubuntu-তে /var/run হলো /run-এর symlink। তাই যেকোনো path ব্যবহার করলেই একই file পাওয়া যায়।

এই flag-টি একটি tmpfs-এ থাকে এবং প্রতিটি boot-এর সময় reset হয়। তাই kernel নিজে পরীক্ষা করে বিষয়টি নিশ্চিত করুন:

uname -r
dpkg -l 'linux-image-*' | grep ^ii

uname -r বর্তমানে ব্যবহৃত kernel দেখায়। দ্বিতীয় command-টি disk-এ installed kernel package-গুলোর তালিকা দেখায়। ওই তালিকায় uname -r যে kernel version দেখায়, তার চেয়ে নতুন কোনো linux-image থাকলে মেশিনটি পুরোনো kernel চালাচ্ছে। Livepatch-এর status যা-ই হোক, এই ফলাফলই গুরুত্বপূর্ণ। কারণ live patching-এর উদ্দেশ্য running kernel-কে নিরাপদ রাখা, তাকে সর্বশেষ version-এ নেওয়া নয়।

একই প্রশ্নের userspace অংশের জন্য, Ubuntu Server-এ needrestart defaultভাবে installed থাকে। এটি deleted library file এখনও ধরে রাখা running service-গুলোর তালিকা দেখায়।

sudo needrestart -r l

-r l flag pair-এর অর্থ হলো "শুধু তালিকা দেখাও"। তাই এটি শুধু তথ্য দেখায় এবং কোনো পরিবর্তন করে না।

রিবুট কেন কখনো এড়ানো যায় না

ডিস্কে থাকা kernel অপরিবর্তিত থাকে। Live patches চলমান kernel-এ লোড হয় এবং কখনো boot image-এ লেখা হয় না। তাই reboot করলে bootloader যে linux-image নির্বাচন করে, সেই kernel-এই সিস্টেম চালু হয়। এরপর Livepatch client প্রযোজ্য patch-গুলো আবার প্রয়োগ করে। এই দুই মুহূর্তের মধ্যে সিস্টেম unpatched code চালায়। পুরোনো kernel-এর বদলে বর্তমান kernel boot করার এটি আরও একটি কারণ।

Coverage প্রতিটি kernel series অনুযায়ী নির্ধারিত হয়, এবং series অবসরপ্রাপ্ত হয়। আপনার চলমান series supported list থেকে বাদ পড়লে kernel state line আর coverage দেখায় না। তখন একমাত্র সমাধান হলো নতুন kernel ব্যবহার করা। এর জন্য reboot করতে হয়। LTS release-এ নতুন series সাধারণত hardware enablement kernel হিসেবে 26.04.1-এর মতো একটি point release-এর মাধ্যমে আসে। ফলে replacement ইতিমধ্যে archive-এ থাকে। শুধু আপনার নির্ধারিত সময়ে boot করানো বাকি থাকে।

Medium এবং low severity-এর kernel fix কখনো live patched হয় না। এগুলো ডিস্কে থাকা package-এ থাকে এবং আপনি boot করার পরই কার্যকর হয়।

দীর্ঘ সময় চলা kernel এমন state-ও জমা করে, যা patching পরিষ্কার করে না। Canonical-এর নিজস্ব অবস্থানটি উদ্ধৃত করা উপযুক্ত, কারণ এটি স্পষ্ট: Livepatch “reboot করার বিকল্প নয়। এটি unscheduled reboot প্রতিরোধ করে আপনাকে আরও নিয়ন্ত্রণ দেওয়ার একটি tool।” এখানে মূল অর্থ বহনকারী শব্দটি হলো unscheduled। আপনাকে তবু reboot করতে হবে। শুধু কখন করবেন, তা আপনি নির্ধারণ করবেন।

পুনরায় চালুর সময় নির্ধারণ করে কীভাবে সিস্টেমকে সচল অবস্থায় ফিরিয়ে আনবেন

আপনি console-এ পৌঁছাতে না পারলে VPS reboot একমুখী হয়ে যায়। reboot টাইপ করার আগে নিশ্চিত করুন, মেশিন ফিরে না এলে কীভাবে আবার access করবেন।

• আপনার provider control panel-এ serial console বা VNC (virtual network computing) view দেয় কি না নিশ্চিত করুন। outage চলাকালে নয়, এখনই সেটি খুলে রাখুন।
• df -h /boot দিয়ে free space পরীক্ষা করুন। /boot পূর্ণ থাকলে kernel package তার initramfs (initial RAM filesystem) লেখার সময় ব্যর্থ হয়। এর ফলে bootloader এমন একটি image-এর দিকে নির্দেশ করতে পারে, যার লেখা সম্পূর্ণ হয়নি।
• অন্তত একটি আগে থেকে পরীক্ষা করা, কার্যকর পুরোনো kernel ইনস্টল রাখা উচিত। GRUB সেটি "Advanced options for Ubuntu"-এর অধীনে দেখায়। নতুন kernel ব্যর্থ হলে সেটি boot করাই দ্রুততম recovery পদ্ধতি।
• প্রয়োজনের আগে provider-এর rescue mode খুঁজে রাখুন। reboot-এর পরে console-এ initramfs prompt দেখা গেলে সেখানেই repair করতে হবে।

আপনি জেগে থাকবেন এমন সময়ে reboot নির্ধারণ করুন:

sudo shutdown -r +5 "Kernel update, back in a moment"

এটি পাঁচ মিনিট পরের জন্য reboot নির্ধারণ করে এবং logged-in user-দের একটি message পাঠায়। sudo shutdown -c এটি বাতিল করে। মেশিন ফিরে এলে উভয় দিক যাচাই করুন:

uname -r
sudo canonical-livepatch status

uname -r-এর output-এ এখন নতুন kernel দেখানো উচিত। status output-এ নতুন series covered হিসেবে দেখানো উচিত। মেশিন একেবারেই ফিরে না এলে fault প্রায় সবসময় network-এর বদলে boot path-এ থাকে। এ ক্ষেত্রে recovery-এর পদ্ধতি হলো kernel update-এর পরে boot না হওয়া VPS-এর নির্দেশিকা।

পুরোনো kernel এখনও পরিষ্কার করে সরাতে হয় কেন

Live patching সমস্যাটি কমানোর বদলে আরও বাড়ায়, কারণ linux-image package ইনস্টল হতে থাকলেও reboot করার তাগিদ কমে যায়। প্রতিটি kernel একটি boot image, একটি initramfs, একটি modules tree এবং সাধারণত একটি headers package ইনস্টল করে। কয়েকশ megabyte-এর আলাদা /boot partition থাকা ছোট VPS-এ তিন বা চারটি kernel-ই সেটি পূর্ণ করে ফেলে।

/boot সম্পূর্ণ পূর্ণ হয়ে গেলে পরবর্তী kernel install ব্যর্থ হয়। এভাবেই কোনো machine-এর প্রয়োজনীয় update-টিই আর ইনস্টল করা যায় না। apt autoremove path পুরোনো kernel eligible হলে সরিয়ে দেয়। কিন্তু যে box কখনও reboot হয় না, সেখানে সেগুলো সব সময় eligible হয় না। কারণ package manager আপনি যে kernel-এ এখনও চলছেন, সেটি সরিয়ে দেয় না।

তাই কোনগুলো ইনস্টল করা আছে তা পরীক্ষা করুন। বর্তমানে চলমান kernel এবং একটি পরিচিতভাবে কার্যকর fallback রাখুন। বাকি kernel-গুলো Ubuntu-তে পুরোনো kernel নিরাপদে সরানোর পদ্ধতি অনুসরণ করে সরিয়ে দিন। uname -r বর্তমানে যে kernel দেখাচ্ছে, সেটি কখনও সরাবেন না।

FAQ

লাইভ kernel patching করলে কি আমার VPS কখনও reboot করতে হবে না?

না। Live patch চলমান kernel-এ লোড হয়, কিন্তু boot image-এ লেখা হয় না। তাই ডিস্কে থাকা linux-image আপনি যে version boot করেছিলেন, সেই version-এই থাকে। Canonical বিষয়টি সরাসরি বলেছে: Livepatch "reboot করার বিকল্প নয়। এটি unscheduled reboot প্রতিরোধ করে আপনাকে আরও নিয়ন্ত্রণ দেওয়ার একটি tool।" আপনার kernel series অবসরপ্রাপ্ত হলে coverage-ও শেষ হয়। এছাড়া medium severity-এর kernel fix কখনও live patched হয় না। কোনো reboot জোর করে করানোর অপেক্ষা না করে, আপনার নির্ধারিত cadence অনুযায়ী maintenance reboot schedule করুন।

Live kernel patching সত্যিই patch প্রয়োগ করছে কি না কীভাবে পরীক্ষা করব?

sudo canonical-livepatch status চালিয়ে দুটি line দেখুন। kernel state জানায় আপনার চলমান kernel series serviceটির coverage-এর মধ্যে আছে কি না। patch state জানায় ওই kernel-এর patch লোড হয়েছে কি না। এছাড়া ls /sys/kernel/livepatch/ ব্যবহার করে সরাসরি kernel side-ও পরীক্ষা করতে পারেন। এটি লোড হওয়া প্রতিটি patch-এর জন্য একটি directory দেখায়। Listing খালি হলে client যা-ই বলুক, এই মুহূর্তে memory-তে কোনো patch প্রয়োগ করা নেই।

ব্যক্তিগত VPS-এ Ubuntu Pro কি free?

হ্যাঁ, তবে নথিভুক্ত একটি সীমার মধ্যে। Canonical-এর ভাষায়, Ubuntu Pro "ব্যক্তিগত ব্যবহারের জন্য সর্বদা free থাকবে, সর্বোচ্চ 5টি physical machine পর্যন্ত"। August 2026 অনুযায়ী, official Ubuntu Community member-দের জন্য সীমাটি 50টি machine। Commercial ব্যবহারের জন্য paid subscription প্রয়োজন। Ubuntu Pro account page থেকে পাওয়া token ব্যবহার করে sudo pro attach TOKEN দিয়ে machine attach করুন। এরপর sudo pro enable livepatch দিয়ে serviceটি enable করুন।

Livepatch চালানোর পরও kernel CVE কেন unfixed হিসেবে দেখানো হয়?

সাধারণত এর দুটি কারণের একটি থাকে। Fixটি severity threshold-এর নিচে থাকতে পারে। কারণ Canonical live patch "critical এবং high Common Vulnerability Scoring System (CVSS) এবং Ubuntu Priority rating-যুক্ত kernel vulnerability" patch করে। বাকি fix disk-এ থাকা package-এর ওপর ছেড়ে দেওয়া হয়। অথবা fixটি function body পরিবর্তন হিসেবে প্রকাশ করা সম্ভব নাও হতে পারে। যেমন upstream কোনো data structure পরিবর্তন করেছে। ইতিমধ্যে allocate করা object-এর ক্ষেত্রে live patching এটি নিরাপদে করতে পারে না। উভয় ক্ষেত্রেই সমাধান একই: updated kernel package install করুন এবং সেটিতে boot করুন।

Live kernel patching একেবারেই কী cover করে না?

Userspace। Canonical স্পষ্টভাবে বলেছে, Livepatch "OpenSSL বা glibc-এর মতো userspace library patch করে না, কারণ এটি unattended-upgrades বা কোনো systems management tool-এর দায়িত্ব।" এটি নতুন kernel version বা নতুন feature-ও দিতে পারে না। কারণ এটি শুধু আপনি বর্তমানে যে series চালাচ্ছেন, তার ভেতরের function body প্রতিস্থাপন করে। এছাড়া __init function-ও patch করতে পারে না। Server চালু হওয়ার সময়ের মধ্যে এসব function ইতিমধ্যে run করে memory থেকে free হয়ে যায়।