{"id":835,"date":"2026-09-19T17:04:02","date_gmt":"2026-09-19T17:04:02","guid":{"rendered":"https:\/\/www.vps.tc\/blog\/?p=835"},"modified":"2026-09-19T09:31:34","modified_gmt":"2026-09-19T09:31:34","slug":"linux-process-management-ps-top-kill","status":"publish","type":"post","link":"https:\/\/www.vps.tc\/blog\/en\/linux-process-management-ps-top-kill\/","title":{"rendered":"Linux Process Management: Using ps, top, and kill"},"content":{"rendered":"<div class=\"aiw-summary\" id=\"aiw-ozet\">\n<p class=\"aiw-summary-title\">Quick Summary &#8211; Linux Process Management<\/p>\n<p>Observe before intervening. Use ps for a snapshot, top for live resource use, and kill for a controlled signal after you have verified the process identity.<\/p>\n<ul>\n<li><strong>Verify identity<\/strong> \u2014 Check the PID, owner, full command line, parent process, and service manager before stopping anything.<\/li>\n<li><strong>Use ps for detail<\/strong> \u2014 Choose explicit columns and sort by CPU or memory to build a useful process snapshot.<\/li>\n<li><strong>Watch live pressure<\/strong> \u2014 Compare load, CPU, memory, swap, process state, and steal time instead of relying on one number.<\/li>\n<li><strong>Prefer SIGTERM<\/strong> \u2014 Give the application a chance to close connections and clean up before considering SIGKILL.<\/li>\n<li><strong>Inspect context<\/strong> \u2014 Read logs and check open files, sockets, parent processes, and service policies.<\/li>\n<li><strong>Automate carefully<\/strong> \u2014 Automate observation first and keep broad process termination behind explicit checks.<\/li>\n<\/ul>\n<\/div>\n<p class=\"aiw-lead\">When a VPS slows down, do not begin with a reboot. Use ps for a precise snapshot, top for live CPU and memory behavior, and kill for controlled signals. Before touching a PID, confirm its owner, command line, parent, and service manager; that short pause has saved me from more than one bad decision.<\/p>\n<div class=\"aiw-toc\" style=\"border:1px solid #dbe3ea;border-radius:8px;padding:16px 20px;margin:0 0 28px\">\n<p class=\"aiw-toc-head\"><strong>Table of Contents<\/strong><span class=\"aiw-toc-meta\"> \u00b7 13 min read<\/span><\/p>\n<ol style=\"margin:10px 0 0;padding-left:22px\">\n<li><a href=\"#why-i-check-processes-before-i-reboot\">Why I check processes before I reboot<\/a><\/li>\n<li><a href=\"#listing-processes-with-ps\">Listing processes with ps<\/a><\/li>\n<li><a href=\"#watching-live-usage-with-top\">Watching live usage with top<\/a><\/li>\n<li><a href=\"#what-cpu-memory-and-process-states-actually-tell-you\">What CPU, memory, and process states actually tell you<\/a><\/li>\n<li><a href=\"#trace-the-parent-process-and-inspect-its-files\">Trace the parent process and inspect its files<\/a><\/li>\n<li><a href=\"#choosing-a-signal-with-kill\">Choosing a signal with kill<\/a><\/li>\n<li><a href=\"#bulk-termination-needs-a-narrow-match\">Bulk termination needs a narrow match<\/a><\/li>\n<li><a href=\"#automate-observation-before-termination\">Automate observation before termination<\/a><\/li>\n<li><a href=\"#a-practical-order-when-a-vps-becomes-slow\">A practical order when a VPS becomes slow<\/a><\/li>\n<li><a href=\"#before-you-stop-a-linux-process\">Before You Stop a Linux Process<\/a><\/li>\n<li><a href=\"#frequently-asked-questions\">Frequently Asked Questions<\/a><\/li>\n<li><a href=\"#sources\">Sources<\/a><\/li>\n<\/ol>\n<\/div>\n<h2 id=\"why-i-check-processes-before-i-reboot\">Why I check processes before I reboot<\/h2>\n<p>A slow VPS creates a strong urge to type <code>reboot<\/code> and move on. I know that urge well. On my Debian ThinkPad, I once saw a worker stuck in <code>D<\/code> state and assumed it was simply misbehaving. It was waiting on storage, so repeated signals would not have fixed the real problem.<\/p>\n<p>When a web server stops responding or the load average rises, I first check which processes are running, who owns them, how much CPU and memory they use, and which parent process started them. Rebooting may hide the symptom for a few minutes. Process inspection gives me a chance to understand it.<\/p>\n<p><code>ps<\/code> gives me a snapshot, <code>top<\/code> shows live activity, and <code>kill<\/code> sends a signal rather than blindly forcing a process to disappear. Used together, these commands let you intervene with evidence.<\/p>\n<p><strong>My first rule:<\/strong> verify the PID, user, complete command line, and parent process before stopping anything.<\/p>\n<h2 id=\"listing-processes-with-ps\">Listing processes with <code>ps<\/code><\/h2>\n<p><code>ps<\/code> shows the processes that exist when you run it. Without options, it usually shows processes associated with your current terminal:<\/p>\n<pre><code>ps<\/code><\/pre>\n<pre><code>  PID TTY          TIME CMD\n 8421 pts\/0    00:00:00 bash\n 9134 pts\/0    00:00:00 ps<\/code><\/pre>\n<p><code>PID<\/code> is the process ID. <code>TTY<\/code> identifies the terminal, <code>TIME<\/code> shows accumulated CPU time, and <code>CMD<\/code> shows the command name. To view processes from all users, I commonly use one of these:<\/p>\n<pre><code>ps aux\nps -ef<\/code><\/pre>\n<p><code>ps aux<\/code> uses BSD-style options and puts CPU and memory percentages near the front. <code>ps -ef<\/code> uses UNIX-style options and includes the parent PID and start time. Do not casually mix the two forms: <code>ps aux<\/code> and <code>ps -aux<\/code> are not equivalent commands.<\/p>\n<h3>Finding one process<\/h3>\n<p>A long process list is easier to search, but the search itself needs care. The <code>grep<\/code> process can appear in its own output:<\/p>\n<pre><code>ps aux | grep '[n]ginx'\npgrep -a nginx\npidof nginx<\/code><\/pre>\n<p><code>pgrep -a<\/code> prints matching PIDs with their command lines. <code>pidof<\/code> is convenient when I only need the PIDs belonging to a service. When I am investigating a resource alert, I usually ask <code>ps<\/code> for specific columns:<\/p>\n<pre><code>ps -eo pid,ppid,user,%cpu,%mem,stat,lstart,cmd --sort=-%cpu | head -n 15<\/code><\/pre>\n<p><code>PPID<\/code> is the parent process ID, <code>STAT<\/code> describes the current state, and <code>LSTART<\/code> shows when the process started. The negative sort puts the highest CPU consumers first. Replace <code>--sort=-%cpu<\/code> with <code>--sort=-%mem<\/code> when memory is the concern.<\/p>\n<p>That one command is often my first useful snapshot. It is much better than guessing from a dashboard that only says &#8220;the server is slow.&#8221;<\/p>\n<h2 id=\"watching-live-usage-with-top\">Watching live usage with <code>top<\/code><\/h2>\n<p><code>top<\/code> refreshes the process list and keeps CPU, memory, load average, and active processes on one screen:<\/p>\n<pre><code>top<\/code><\/pre>\n<p>The three <code>load average<\/code> values represent runnable or waiting work over the last 1, 5, and 15 minutes. Compare them with the number of vCPUs. A load of 2.0 is not automatically alarming on an 8-vCPU VPS, while the same value means sustained pressure on a 1-vCPU VPS.<\/p>\n<p>These keys change the view while <code>top<\/code> is running:<\/p>\n<ul>\n<li><code>P<\/code> sorts by CPU usage.<\/li>\n<li><code>M<\/code> sorts by memory usage.<\/li>\n<li><code>1<\/code> shows individual CPU cores.<\/li>\n<li><code>c<\/code> toggles between the short name and full command line.<\/li>\n<li><code>H<\/code> shows or hides threads.<\/li>\n<li><code>k<\/code> opens the signal prompt for a PID.<\/li>\n<li><code>q<\/code> exits the program.<\/li>\n<\/ul>\n<p>CPU percentage is only one clue. If one process stays near the top, the bottleneck may be computation. If memory usage rises while <code>available<\/code> memory falls, I look for memory pressure. Swap deserves its own check:<\/p>\n<pre><code>free -h\nvmstat 1 5<\/code><\/pre>\n<p><code>free -h<\/code> reports memory in readable units. In <code>vmstat<\/code>, persistent non-zero <code>si<\/code> and <code>so<\/code> values mean the system is moving pages into and out of swap. A slow VPS is not always suffering from one CPU-hungry process.<\/p>\n<p>On a virtual machine, I also watch <code>st<\/code> in <code>top<\/code>. That is CPU time stolen by the hypervisor. If application processes look ordinary but the VPS remains slow, provider-side contention or a CPU limit may be involved.<\/p>\n<h2 id=\"what-cpu-memory-and-process-states-actually-tell-you\">What CPU, memory, and process states actually tell you<\/h2>\n<p>A process using 100 percent CPU generally occupies one logical processor completely, although tools present percentages differently. On a multi-core host, the number is not automatically the percentage of the entire machine.<\/p>\n<p>For memory, <code>RES<\/code> is the portion currently resident in RAM, <code>VIRT<\/code> is the virtual address space, and <code>SHR<\/code> is the shareable portion. A large <code>VIRT<\/code> value does not mean the process consumes the same amount of physical memory. I compare <code>RES<\/code> with system-wide <code>available<\/code> memory and swap activity.<\/p>\n<p>Process state adds another useful clue:<\/p>\n<ul>\n<li><code>R<\/code> means running or ready to run.<\/li>\n<li><code>S<\/code> means interruptible sleep.<\/li>\n<li><code>D<\/code> means uninterruptible sleep, commonly during I\/O.<\/li>\n<li><code>Z<\/code> means the process has exited but its parent has not collected its status.<\/li>\n<\/ul>\n<p>Use this to find processes in <code>D<\/code> or <code>Z<\/code> state:<\/p>\n<pre><code>ps -eo pid,stat,wchan:32,cmd | awk '$2 ~ \/^D\/ || $2 ~ \/^Z\/ {print}'<\/code><\/pre>\n<p>A process in <code>D<\/code> state may be waiting for a disk, a network filesystem, or another kernel-level I\/O operation. Repeatedly sending signals is usually not the answer. For a zombie, inspect its parent process; the zombie is often only the visible remainder of the problem.<\/p>\n<p>When I hit the stuck worker on my test machine, its name looked suspicious enough to kill. The <code>D<\/code> state changed my plan. I checked the storage path first, and that saved me from treating an I\/O problem as an application problem.<\/p>\n<div class=\"aiw-callout aiw-callout-example\">\n<p class=\"aiw-callout-label\">Example<\/p>\n<p>A process in D state is usually waiting in the kernel, often on storage or another I\/O operation. Repeated signals are less useful than finding the underlying I\/O delay.<\/p>\n<\/div>\n<h2 id=\"trace-the-parent-process-and-inspect-its-files\">Trace the parent process and inspect its files<\/h2>\n<p>Every process has a PID and, in normal circumstances, a parent PID. The process tree tells you why a service has several workers and whether a process is likely to return after it exits:<\/p>\n<pre><code>pstree -aps 9134\nps -o pid,ppid,user,lstart,cmd -p 9134<\/code><\/pre>\n<p><code>pstree -aps<\/code> shows the chain leading to the selected PID. The <code>ps -o<\/code> form prints only the columns I request, which keeps the output readable during an incident.<\/p>\n<p>To inspect files and sockets opened by a process:<\/p>\n<pre><code>lsof -p 9134\nls -l \/proc\/9134\/fd\ntr '\\0' ' ' &lt; \/proc\/9134\/cmdline; echo<\/code><\/pre>\n<p>The <code>\/proc<\/code> filesystem exposes process information through a kernel interface. Links under <code>\/proc\/PID\/fd<\/code> point to open files, sockets, and pipes. Access to another user&#8217;s process details may be restricted, so not every inspection requires root access.<\/p>\n<p>When I need to see which process owns a listening port, <code>ss<\/code> is usually enough:<\/p>\n<pre><code>ss -ltnp\nss -ltnp | grep ':8080'<\/code><\/pre>\n<p>The output can separate an application problem from a <a href=\"https:\/\/www.vps.tc\/blog\/en\/how-to-fix-502-bad-gateway-error\/\">reverse-proxy routing mistake<\/a>. Nginx listening on ports 80 and 443 while an application listens on <code>127.0.0.1:8080<\/code> is a normal design. It becomes a problem only when the proxy points somewhere else, or when nothing is listening on the upstream port.<\/p>\n<p>Before I stop an unfamiliar process, I record its owner, parent, full command line, open files, and listening sockets. That takes less time than explaining why the wrong service disappeared.<\/p>\n<div class=\"aiw-callout aiw-callout-field\">\n<p class=\"aiw-callout-label\">From the field<\/p>\n<p>I once followed a stuck worker on my Debian test machine and nearly treated it like a normal runaway process. Its D state pointed me toward storage waits instead, which reminded me to read process state before reaching for kill.<\/p>\n<\/div>\n<h2 id=\"choosing-a-signal-with-kill\">Choosing a signal with <code>kill<\/code><\/h2>\n<p>The command called <code>kill<\/code> sends a signal to a PID. It does not always force the process to close. With no signal specified, it sends <code>SIGTERM<\/code>, signal 15, which gives an application the opportunity to close connections and clean up:<\/p>\n<pre><code>kill 9134\nkill -TERM 9134\nkill -15 9134<\/code><\/pre>\n<p>These commands send the same signal. Check the result afterward:<\/p>\n<pre><code>kill -0 9134 &amp;&amp; echo 'PID exists or is accessible' || echo 'PID not found or permission denied'<\/code><\/pre>\n<p><code>kill -0<\/code> does not terminate anything. It checks whether the PID exists and whether you can send it a signal. A successful check does not prove that the application is healthy; it only confirms that the PID is present and accessible.<\/p>\n<p>If the process ignores <code>SIGTERM<\/code>, read the application and system logs before escalating. The last resort is <code>SIGKILL<\/code>:<\/p>\n<pre><code>kill -KILL 9134\nkill -9 9134<\/code><\/pre>\n<p><code>SIGKILL<\/code> cannot be caught or deferred. Cleanup code will not run, so open connections, temporary files, and application state may be left in an unexpected condition. I am especially careful with databases, file writers, and queue workers.<\/p>\n<p>For a process controlled by a service manager, use that interface instead of killing the PID directly:<\/p>\n<pre><code>sudo systemctl status nginx\nsudo systemctl stop nginx\nsudo systemctl restart nginx<\/code><\/pre>\n<p>If systemd is configured to restart the service, a directly killed process may return a few seconds later. That is often the service policy working as configured.<\/p>\n<p><strong>Order matters:<\/strong> send <code>SIGTERM<\/code>, verify the shutdown, and use <code>SIGKILL<\/code> only when graceful termination has failed and you understand the consequences.<\/p>\n<div class=\"aiw-callout aiw-callout-warn\">\n<p class=\"aiw-callout-label\">Caution<\/p>\n<p>SIGKILL cannot be caught and gives the application no chance to clean up. Use it only after graceful termination has failed and you understand what may be left behind.<\/p>\n<\/div>\n<h2 id=\"bulk-termination-needs-a-narrow-match\">Bulk termination needs a narrow match<\/h2>\n<p><code>pkill<\/code> and <code>killall<\/code> can stop multiple processes by name. That makes them useful, but dangerous when the match is broad:<\/p>\n<pre><code>pgrep -a worker\npkill -TERM -u appuser -f '\/opt\/app\/worker.py'<\/code><\/pre>\n<p><code>-u<\/code> limits the match to a user, while <code>-f<\/code> searches the complete command line instead of only the short process name. Run <code>pgrep -a<\/code> first and inspect every result. A matching substring can select a process you did not mean to touch.<\/p>\n<p>I keep long investigations inside <code>tmux<\/code>. An SSH disconnect should not erase the terminal where I am watching logs or waiting for a service to stop. A background process is not automatically a service, though; production workloads are easier to observe when systemd, Supervisor, or the application&#8217;s own service mechanism owns them.<\/p>\n<p>When you cannot identify a process, pause. Display its command line, check the user, find the parent, inspect files and sockets, and read the relevant logs. On <a href=\"https:\/\/www.vps.tc\/blog\/en\/install-wordpress-on-vps-step-by-step\/\">WordPress VPSs<\/a>, PHP-FPM workers, web requests, and database waits need to be considered together. Killing the worker with the highest CPU usage may only remove the most visible symptom.<\/p>\n<div class=\"aiw-callout aiw-callout-tip\">\n<p class=\"aiw-callout-label\">Tip<\/p>\n<p>Run pgrep -a before pkill. Seeing the exact command lines turns a broad pattern into a deliberate match.<\/p>\n<\/div>\n<h2 id=\"automate-observation-before-termination\">Automate observation before termination<\/h2>\n<p>If I repeat the same process check for a third time, I consider writing a small <a href=\"https:\/\/www.vps.tc\/blog\/en\/what-is-bash-scripting-linux-automation\/\">Bash Script<\/a>. The first version should report what it finds. Automatic termination should not be the default.<\/p>\n<pre><code>#!\/usr\/bin\/env bash\nset -u\n\npattern=\"\/opt\/app\/worker.py\"\n\nif ! pgrep -af -- \"$pattern\"; then\n  echo \"Process not found: $pattern\" &gt;&amp;2\n  exit 1\nfi\n\necho \"Verify the PID and command line first. No automatic kill was applied.\"<\/code><\/pre>\n<p><code>set -u<\/code> treats unset variables as errors. This script intentionally does not terminate anything. That restraint is useful: a mistaken pattern should produce a report, not a service outage.<\/p>\n<p>Ansible is useful when I need the same observation across several VPSs. For a one-time command on one host, opening a YAML file can be unnecessary ceremony. If monitoring reports process count, CPU, memory, and service state, include the PID, command name, and last restart time where they are available.<\/p>\n<h2 id=\"a-practical-order-when-a-vps-becomes-slow\">A practical order when a VPS becomes slow<\/h2>\n<p>I use this sequence instead of reaching for a reboot:<\/p>\n<ol>\n<li>Run <code>uptime<\/code> to see load average and uptime.<\/li>\n<li>Run <code>free -h<\/code> to check available RAM and swap.<\/li>\n<li>Use <code>top<\/code> or <code>ps<\/code> to find the leading CPU and memory consumers.<\/li>\n<li>Verify the process with <code>ps -o pid,ppid,user,stat,cmd -p PID<\/code>.<\/li>\n<li>Read <code>journalctl -u service-name<\/code> and the application logs.<\/li>\n<li>Check <code>systemctl status service-name<\/code> and the restart policy if systemd owns the service.<\/li>\n<li>Use <code>systemctl stop<\/code> or send <code>SIGTERM<\/code> before considering <code>SIGKILL<\/code>.<\/li>\n<li>Measure the system again after the process exits.<\/li>\n<\/ol>\n<p>Disk pressure can change process behavior too. If <code>\/var<\/code> is full, applications may fail to write logs, lock up, or stop creating workers. Check <code>df -h<\/code>, <code>ncdu<\/code>, and log rotation together. Killing a process does not make a full filesystem less full.<\/p>\n<table>\n<thead>\n<tr>\n<th>Tool<\/th>\n<th>Best use<\/th>\n<th>Watch for<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td><code>ps<\/code><\/td>\n<td>Detailed snapshot and custom columns<\/td>\n<td>It does not refresh live<\/td>\n<\/tr>\n<tr>\n<td><code>top<\/code><\/td>\n<td>Live CPU, memory, and load monitoring<\/td>\n<td>Values need system context<\/td>\n<\/tr>\n<tr>\n<td><code>kill<\/code><\/td>\n<td>Sending a signal to a specific PID<\/td>\n<td><code>SIGKILL<\/code> skips cleanup<\/td>\n<\/tr>\n<tr>\n<td><code>pgrep<\/code><\/td>\n<td>Searching for PIDs and command lines<\/td>\n<td>Keep the pattern narrow<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p>Safe process management is not about finding the largest number and killing it. Measure first, identify the process, inspect its context, choose the least destructive action, and measure again.<\/p>\n<p>The next time a VPS alarm wakes you up, give yourself one quiet minute before typing <code>reboot<\/code>. Start with the PID. It usually has more to say than the load average.<\/p>\n<h2 id=\"before-you-stop-a-linux-process\">Before You Stop a Linux Process<\/h2>\n<ul class=\"aiw-checklist\">\n<li>Run ps or top and record the suspicious PID.<\/li>\n<li>Confirm the process owner and complete command line.<\/li>\n<li>Find the parent PID and check whether a service manager owns it.<\/li>\n<li>Inspect process state, CPU, memory, open files, and sockets.<\/li>\n<li>Read the relevant application and system logs.<\/li>\n<li>Send SIGTERM or use systemctl stop before considering SIGKILL.<\/li>\n<li>Measure the system again after the process exits.<\/li>\n<\/ul>\n<div class=\"aiw-cta\">\n<p>Keep these commands close during the next VPS incident, but begin with evidence rather than a reboot. A careful PID check is usually faster than recovering from an unnecessary process kill.<\/p>\n<p class=\"aiw-cta-action\"><a href=\"https:\/\/www.vps.tc\/en\/vps\">Explore VPS plans<\/a><\/p>\n<\/div>\n<h2 id=\"frequently-asked-questions\">Frequently Asked Questions<\/h2>\n<div class=\"aiw-faq\">\n<details class=\"aiw-faq-item\" open>\n<summary>What is the difference between ps and top?<\/summary>\n<p>ps prints a snapshot at the moment you run it and is useful for custom columns, filtering, and scripts. top refreshes continuously and is better for watching changing CPU, memory, load, and process state. I often use top to notice a problem, then ps to capture the exact command line, parent PID, and start time.<\/p>\n<\/details>\n<details class=\"aiw-faq-item\">\n<summary>What does kill do in Linux?<\/summary>\n<p>kill sends a signal to a process ID; it does not always force the process to disappear. With no signal specified, it sends SIGTERM, allowing the application to shut down cleanly. kill -9 sends SIGKILL, which cannot be handled or delayed, so cleanup code will not run. Verify the result afterward.<\/p>\n<\/details>\n<details class=\"aiw-faq-item\">\n<summary>Is a high CPU process always the cause of a slow VPS?<\/summary>\n<p>No. It may be the cause, but it may also be a symptom of slow storage, repeated errors, a busy queue, or a downstream dependency. Compare process CPU with load average, available memory, swap activity, I\/O wait, logs, and process state. On a VPS, check CPU steal time because host contention can make ordinary processes appear slow.<\/p>\n<\/details>\n<details class=\"aiw-faq-item\">\n<summary>What does a process in D state mean?<\/summary>\n<p>A process in D state is in uninterruptible sleep, commonly waiting for disk or network-storage I\/O. Signals usually cannot make it exit until that kernel wait completes. Instead of repeatedly using kill, inspect storage latency, mounted filesystems, network storage, and kernel logs. If the condition persists, the underlying device or I\/O path needs attention.<\/p>\n<\/details>\n<details class=\"aiw-faq-item\">\n<summary>Why should I avoid kill -9 when stopping a service?<\/summary>\n<p>SIGKILL ends a process without giving it an opportunity to close connections, flush data, remove temporary files, or finish a transaction. A database or queue worker may leave recovery work behind. Try the service manager or SIGTERM first, wait for shutdown, inspect logs, and use SIGKILL only when graceful termination has genuinely failed.<\/p>\n<\/details>\n<details class=\"aiw-faq-item\">\n<summary>How can I safely kill processes by name?<\/summary>\n<p>Preview the match before terminating anything. Run pgrep -a name or a similarly narrow query, verify the user and complete command line, then use a restricted pkill pattern if necessary. The -f option matches the full command line and can select more processes than expected. For production services, prefer systemctl stop so the service policy remains visible.<\/p>\n<\/details>\n<\/div>\n<h2 id=\"sources\">Sources<\/h2>\n<ul class=\"aiw-sources\">\n<li><a href=\"https:\/\/docs.kernel.org\/filesystems\/proc.html\" target=\"_blank\" rel=\"noopener\">Linux Kernel Documentation &#8211; The \/proc Filesystem<\/a> \u2014 docs.kernel.org<\/li>\n<\/ul>\n","protected":false},"excerpt":{"rendered":"<p>Use ps, top, and kill to inspect Linux processes, understand CPU and memory pressure, trace parent processes, and stop services safely without rebooting first.<\/p>\n","protected":false},"author":2,"featured_media":833,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[5],"tags":[],"class_list":["post-835","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-linux"],"lang":"en","translations":{"en":835,"tr":834},"pll_sync_post":[],"_links":{"self":[{"href":"https:\/\/www.vps.tc\/blog\/wp-json\/wp\/v2\/posts\/835","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.vps.tc\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.vps.tc\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.vps.tc\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.vps.tc\/blog\/wp-json\/wp\/v2\/comments?post=835"}],"version-history":[{"count":1,"href":"https:\/\/www.vps.tc\/blog\/wp-json\/wp\/v2\/posts\/835\/revisions"}],"predecessor-version":[{"id":837,"href":"https:\/\/www.vps.tc\/blog\/wp-json\/wp\/v2\/posts\/835\/revisions\/837"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.vps.tc\/blog\/wp-json\/wp\/v2\/media\/833"}],"wp:attachment":[{"href":"https:\/\/www.vps.tc\/blog\/wp-json\/wp\/v2\/media?parent=835"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.vps.tc\/blog\/wp-json\/wp\/v2\/categories?post=835"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.vps.tc\/blog\/wp-json\/wp\/v2\/tags?post=835"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}