{"id":7164,"date":"2025-10-13T12:51:52","date_gmt":"2025-10-13T10:51:52","guid":{"rendered":"https:\/\/www.hostingtg.com\/blog\/?p=7164"},"modified":"2025-10-13T12:51:56","modified_gmt":"2025-10-13T10:51:56","slug":"comando-shutdown-linux-guia-practica","status":"publish","type":"post","link":"https:\/\/www.hostingtg.com\/blog\/comando-shutdown-linux-guia-practica\/","title":{"rendered":"Comando shutdown en Linux: gu\u00eda pr\u00e1ctica para apagar y reiniciar sin sustos"},"content":{"rendered":"\n

Por qu\u00e9 no conviene \u201capagar a las bravas\u201d (y qu\u00e9 hace realmente shutdown<\/code>)<\/h2>\n\n\n\n

He visto demasiadas veces el \u201cya est\u00e1, mantengo pulsado el bot\u00f3n y listo\u201d. Parece inocente\u2026 hasta que no lo es<\/strong>. Detr\u00e1s de un shutdown<\/code> hay una coreograf\u00eda: primero se avisa a los usuarios, se env\u00eda SIGTERM<\/strong> a los procesos para que cierren con orden, se detienen servicios, se sincroniza el disco<\/strong> (flush de cach\u00e9s<\/a>) y, si todo est\u00e1 limpio, se desmontan sistemas de archivos. Forzar el apagado corta esa secuencia: puedes corromper datos, dejar transacciones a medias o provocar una reparaci\u00f3n del sistema de archivos en el pr\u00f3ximo arranque.<\/p>\n\n\n\n

En mi d\u00eda a d\u00eda, trato el apagado como una muestra de respeto por el sistema y por mis datos. Si trabajas con contenedores, bases de datos o un servidor web<\/a>, hacerlo bien no es opcional: es la diferencia entre volver a arrancar sin dramas o pasarte la ma\u00f1ana reparando tablas y rascando logs para entender qu\u00e9 se rompi\u00f3.<\/p>\n\n\n\n

\"shutdown<\/a><\/figure>\n\n\n\n

Idea clave:<\/strong> Un apagado correcto minimiza el riesgo de corrupci\u00f3n silenciosa. Incluso en un port\u00e1til, dar unos minutos con shutdown -h +5<\/code> y un mensaje claro permite que todo cierre como debe.<\/p>\n\n\n\n

\n

Te dejo tambien nuestra gu\u00eda de comandos Linux<\/a><\/p>\n<\/blockquote>\n\n\n\n

\n\n\n\n

Sintaxis esencial de shutdown<\/code> (y equivalentes con systemd<\/code>)<\/h2>\n\n\n\n

La forma general es:<\/p>\n\n\n\n

shutdown [OPCIONES] [TIEMPO] [MENSAJE]\n<\/code><\/pre>\n\n\n\n
Opciones que usar\u00e1s a diario<\/strong><\/p>\n\n\n\n
    \n
  • -h<\/code> \u2192 Apagar (halt\/poweroff).<\/li>\n\n\n\n
  • -r<\/code> \u2192 Reiniciar.<\/li>\n\n\n\n
  • -P<\/code> \u2192 Apagar y cortar alimentaci\u00f3n (poweroff).<\/li>\n\n\n\n
  • -c<\/code> \u2192 Cancelar un apagado programado.<\/li>\n\n\n\n
  • -k<\/code> \u2192 Enviar aviso a los usuarios, sin apagar (\u00fatil para pruebas).<\/li>\n<\/ul>\n\n\n\n
    Tiempo<\/strong><\/p>\n\n\n\n
      \n
    • now<\/code> \u2192 inmediato.<\/li>\n\n\n\n
    • +m<\/code> \u2192 en \u201cm\u201d minutos (ej. +10<\/code>).<\/li>\n\n\n\n
    • hh:mm<\/code> \u2192 a una hora espec\u00edfica (24 h).<\/li>\n<\/ul>\n\n\n\n
      Equivalentes con systemd<\/code><\/strong><\/p>\n\n\n\n
        \n
      • systemctl poweroff<\/code> (apagar)<\/li>\n\n\n\n
      • systemctl reboot<\/code> (reiniciar)<\/li>\n\n\n\n
      • systemctl halt<\/code> (detener sin cortar alimentaci\u00f3n)<\/li>\n<\/ul>\n\n\n\n
        En servidores modernos con systemd<\/code>, uso mucho systemctl poweroff<\/code>\/reboot<\/code> por su integraci\u00f3n con unidades y dependencias; shutdown<\/code> sigue siendo perfecto cuando quiero programar<\/strong> y notificar en un solo comando.<\/p>\n\n\n\n
        \n\n\n\n
        Programar apagados y reinicios: now<\/code>, +m<\/code>, hh:mm<\/code>, mensajes a usuarios<\/h2>\n\n\n\n
        Programar te da margen para avisar, cerrar sesiones y terminar trabajos en curso.<\/p>\n\n\n\n
        Recetas r\u00e1pidas<\/strong><\/p>\n\n\n\n
          \n
        • Apagado inmediato y educado:<\/li>\n<\/ul>\n\n\n\n
          sudo shutdown -h now \"Apagando con seguridad\"\n<\/code><\/pre>\n\n\n\n
            \n
          • Apagar en 5 minutos con aviso:<\/li>\n<\/ul>\n\n\n\n
            sudo shutdown -h +5 \"El sistema se apagar\u00e1 en 5 minutos. Guarda tu trabajo.\"\n<\/code><\/pre>\n\n\n\n
              \n
            • Reiniciar a las 23:00 (mantenimiento nocturno):<\/li>\n<\/ul>\n\n\n\n
              sudo shutdown -r 23:00 \"Reinicio programado a las 23:00\"\n<\/code><\/pre>\n\n\n\n
              Buenas pr\u00e1cticas que me funcionan<\/strong><\/p>\n\n\n\n
                \n
              • Siempre incluyo un mensaje claro<\/strong>: reduce tickets y sorpresas.<\/li>\n\n\n\n
              • Si es un entorno multiusuario, dejo al menos 10\u201315 min<\/strong> y reviso sesiones activas (ver secci\u00f3n de servidores).<\/li>\n\n\n\n
              • Tras programar, anoto el evento en mi runbook o ticket para que quede trazabilidad.<\/li>\n<\/ul>\n\n\n\n
                \n\n\n\n
                4. Cancelar un apagado y comunicar con wall<\/code><\/h2>\n\n\n\n
                Si cambian los planes, cancelo y aviso:<\/p>\n\n\n\n
                sudo shutdown -c\necho \"Mantenimiento cancelado. No habr\u00e1 apagado.\" | sudo wall\n<\/code><\/pre>\n\n\n\n
                -c<\/code> detiene el temporizador de shutdown<\/code>. Con wall<\/code> env\u00edo un mensaje inmediato a todas las terminales de usuarios logados. Es una cortes\u00eda m\u00ednima que evita sustos.<\/p>\n\n\n\n
                \n\n\n\n
                5. Apagado seguro en servidores: web, contenedores y bases de datos<\/h2>\n\n\n\n
                Aqu\u00ed es donde m\u00e1s cuidado pongo. Mi checklist t\u00edpico antes de ejecutar el apagado:<\/p>\n\n\n\n
                Checklist express<\/strong><\/p>\n\n\n\n
                  \n
                • Drenar tr\u00e1fico<\/strong>: poner el servidor en mantenimiento (LB, reverse proxy o systemctl stop nginx<\/code>\/apache2<\/code>).<\/li>\n\n\n\n
                • Contenedores<\/strong>: parar con orden (docker compose down<\/code> o docker stop<\/code>), verificar que no quedan jobs cr\u00edticos.<\/li>\n\n\n\n
                • Bases de datos<\/strong>: cerrar conexiones y parar el servicio con su unidad (systemctl stop postgresql<\/code>\/mysqld<\/code>). Esperar a que el buffer se vac\u00ede.<\/li>\n\n\n\n
                • Jobs en background<\/strong>: revisar colas\/queues (ej. Sidekiq\/Celery\/cron en curso).<\/li>\n\n\n\n
                • Usuarios<\/strong>: avisar con wall<\/code> y dar margen.<\/li>\n\n\n\n
                • Sincronizar<\/strong> (opcional si hay mucha E\/S):<\/li>\n<\/ul>\n\n\n\n
                  sync\n<\/code><\/pre>\n\n\n\n
                    \n
                  • Apagar<\/strong>:<\/li>\n<\/ul>\n\n\n\n
                    sudo systemctl poweroff\n<\/code><\/pre>\n\n\n\n
                      \n
                    1. o programado con shutdown<\/code> si necesito ventana.<\/li>\n<\/ol>\n\n\n\n
                      Cuando prob\u00e9 a ignorar la coreograf\u00eda (sobre todo con BBDD), las probabilidades de que algo quedara \u201ca medio cerrar\u201d sub\u00edan. Desde que sigo esta secuencia, los reinicios post-mantenimiento son aburridos\u2026 como debe ser.<\/p>\n\n\n\n
                      \n\n\n\n
                      Uso diario en port\u00e1til y VPS: atajos que evitan problemas<\/h2>\n\n\n\n
                      En el port\u00e1til, si estoy con muchas ventanas y compilaciones, prefiero:<\/p>\n\n\n\n
                      sudo shutdown -h +5 \"Apagando con seguridad\"\n<\/code><\/pre>\n\n\n\n
                      Ese margen permite que editores, contenedores locales y procesos liberen recursos. En un VPS de un solo usuario hago algo similar, y si voy con prisa:<\/p>\n\n\n\n
                      sudo systemctl reboot\n<\/code><\/pre>\n\n\n\n
                      para reinicios r\u00e1pidos que respetan dependencias de systemd<\/code>. He visto equipos \u201csobrevivir\u201d a cortes de luz, pero esa falsa sensaci\u00f3n de seguridad pasa factura en el peor momento: la corrupci\u00f3n rara vez avisa al instante.<\/p>\n\n\n\n
                      \n\n\n\n
                      Automatizar con cron<\/code>, at<\/code> y timers de systemd<\/code><\/h2>\n\n\n\n
                      Con at<\/code><\/strong> (una sola vez):<\/p>\n\n\n\n
                      echo 'shutdown -h now \"Apagado planificado\"' | sudo at 23:00\n<\/code><\/pre>\n\n\n\n
                      Con cron<\/code><\/strong> (repetitivo, p. ej. domingos a las 23:30):<\/p>\n\n\n\n
                      sudo crontab -e\n30 23 * * 0 \/sbin\/shutdown -h now \"Mantenimiento semanal\"\n<\/code><\/pre>\n\n\n\n
                      Timers de systemd<\/code><\/strong> (mi favorito en sistemas modernos: logs nativos, dependencias y unidades):<\/p>\n\n\n\n
                        \n
                      • Unidad de servicio: \/etc\/systemd\/system\/maintenance-shutdown.service<\/code><\/li>\n<\/ul>\n\n\n\n
                        [Unit]\nDescription=Apagado planificado\n\n[Service]\nType=oneshot\nExecStart=\/sbin\/shutdown -h now \"Ventana de mantenimiento\"\n<\/code><\/pre>\n\n\n\n
                          \n
                        • Timer: \/etc\/systemd\/system\/maintenance-shutdown.timer<\/code><\/li>\n<\/ul>\n\n\n\n
                          [Unit]\nDescription=Programa el apagado semanal\n\n[Timer]\nOnCalendar=Sun 23:30\nPersistent=true\n\n[Install]\nWantedBy=timers.target\n<\/code><\/pre>\n\n\n\n
                            \n
                          • Activar:<\/li>\n<\/ul>\n\n\n\n
                            sudo systemctl daemon-reload\nsudo systemctl enable --now maintenance-shutdown.timer\n<\/code><\/pre>\n\n\n\n
                            Cron vs Timer<\/strong><\/p>\n\n\n\n
                              \n
                            • Cron<\/em>: sencillo y universal.<\/li>\n\n\n\n
                            • Timer systemd<\/em>: mejor integraci\u00f3n, reintentos y registro; ideal en distros modernas.<\/li>\n<\/ul>\n\n\n\n
                              \n\n\n\n
                              Errores comunes y c\u00f3mo evitarlos<\/h2>\n\n\n\n
                                \n
                              • Apagar con prisas<\/strong>: no revisar servicios ni usuarios. \u2192 Soluci\u00f3n: checklist y mensajes wall<\/code>.<\/li>\n\n\n\n
                              • Confiar en \u201csobrevivi\u00f3 una vez\u201d<\/strong>: esa es la trampa. \u2192 Soluci\u00f3n: shutdown<\/code>\/systemctl<\/code> siempre.<\/li>\n\n\n\n
                              • No cancelar a tiempo<\/strong>: olvidas -c<\/code>. \u2192 Soluci\u00f3n: alias \u00fatil: alias sd-c='sudo shutdown -c && echo Cancelado | sudo wall'<\/code>.<\/li>\n\n\n\n
                              • Cerrar BBDD a las malas<\/strong>: riesgo de corrupci\u00f3n. \u2192 Soluci\u00f3n: parar con su servicio y esperar confirmaci\u00f3n.<\/li>\n\n\n\n
                              • No usar hora local clara<\/strong>: confusiones con hh:mm<\/code>. \u2192 Soluci\u00f3n: documentar zona horaria y preferir +m<\/code> para ventanas cortas.<\/li>\n<\/ul>\n\n\n\n
                                \n\n\n\n
                                Ejemplos r\u00e1pidos listos para copiar<\/h2>\n\n\n\n
                                  \n
                                • Apagar ya:<\/li>\n<\/ul>\n\n\n\n
                                  sudo shutdown -h now \"Apagando con seguridad\"\n<\/code><\/pre>\n\n\n\n
                                    \n
                                  • Reiniciar en 10 minutos:<\/li>\n<\/ul>\n\n\n\n
                                    sudo shutdown -r +10 \"Reinicio programado\"\n<\/code><\/pre>\n\n\n\n
                                      \n
                                    • Apagar a las 23:00:<\/li>\n<\/ul>\n\n\n\n
                                      sudo shutdown -h 23:00 \"Apagado nocturno\"\n<\/code><\/pre>\n\n\n\n
                                        \n
                                      • Cancelar:<\/li>\n<\/ul>\n\n\n\n
                                        sudo shutdown -c\n<\/code><\/pre>\n\n\n\n
                                          \n
                                        • Avisar manualmente:<\/li>\n<\/ul>\n\n\n\n
                                          echo \u00abEl sistema se apagar\u00e1 en breve. Guarda tu trabajo.\u00bb | sudo wall<\/p>\n\n\n\n
                                          FAQs sobre shutdown<\/code><\/h2>\n\n\n\n
                                          \u00bfQu\u00e9 hace shutdown<\/code> que no hace el bot\u00f3n f\u00edsico?<\/strong>
                                          Orquesta cierre limpio: se\u00f1ales a procesos, parada ordenada de servicios, sincronizaci\u00f3n de discos y desmontaje seguro.<\/p>\n\n\n\n
                                          \u00bfshutdown -h<\/code> vs poweroff<\/code> vs systemctl poweroff<\/code>?<\/strong>
                                          Todos apagan; systemctl poweroff<\/code> integra dependencias\/unidades de systemd<\/code>. Uso shutdown<\/code> cuando quiero programar\/aprobar mensajes; systemctl<\/code> para apagar ahora dentro del ecosistema systemd<\/code>.<\/p>\n\n\n\n
                                          \u00bfC\u00f3mo aviso a usuarios antes de apagar?<\/strong>
                                          Mensaje en el propio shutdown<\/code> y, si hace falta, wall<\/code>. Deja margen (\u226510\u201315 min) en sistemas multiusuario.<\/p>\n\n\n\n
                                          \u00bfC\u00f3mo programo a las 23:00 y lo cancelo?<\/strong>
                                          shutdown -h 23:00 \"Mensaje\"<\/code> y, si cambias de idea, shutdown -c<\/code> + wall<\/code> para avisar.<\/p>\n\n\n\n
                                          \u00bfQu\u00e9 precauciones con BBDD\/containers?<\/strong>
                                          Parar servicios con orden, esperar a que vac\u00eden buffers\/colas, y luego apagar. Esa disciplina evita ma\u00f1anas de p\u00e1nico.<\/p>\n\n\n\n
                                          \n\n\n\n
                                          Importante sobre shutdown<\/h3>\n\n\n\n
                                          Apagar bien no es burocracia: es seguridad operativa<\/strong>. En mi experiencia, tratar el apagado como una coreograf\u00eda (avisar, drenar, parar servicios, sincronizar, apagar) es lo que separa un mantenimiento rutinario de una guerra con los logs. Con shutdown<\/code> y systemd<\/code> tienes todo lo necesario para hacerlo limpio, predecible y sin sustos<\/strong>.<\/p>\n\n\n\n
                                          Opini\u00f3n Personal<\/strong><\/p>\n\n\n\n
                                          Hay costumbres que parecen inocentes\u2026 hasta que no lo son. \u201cMantengo pulsado el bot\u00f3n y arreando\u201d. Lo he visto demasiadas veces. Y, s\u00ed, muchas m\u00e1quinas \u201csobreviven\u201d al maltrato; justo por eso nace la falsa sensaci\u00f3n de seguridad. Pero detr\u00e1s de un simple shutdown<\/code> hay una coreograf\u00eda que merece respeto: servicios que deben detenerse con orden, procesos que necesitan liberar recursos, cach\u00e9s que hay que vaciar y sistemas de archivos que han de quedar consistentes. Ignorar esa coreograf\u00eda es como irte de casa sin cerrar la puerta: puede no pasar nada hoy, pero el d\u00eda que pase, te acordar\u00e1s.<\/p>\n\n\n\n
                                          Para m\u00ed, un buen apagado no es burocracia; es cultura operativa. Cuando trabajas con contenedores, bases de datos o un servidor web, no es opcional. Es la diferencia entre arrancar sin dramas o pasarte la ma\u00f1ana reparando tablas y persiguiendo corrupci\u00f3n silenciosa. He estado en ambos lados y, cr\u00e9eme, prefiero el lado aburrido en el que todo cae con elegancia y vuelve con la misma elegancia.<\/p>\n\n\n\n
                                          Me molesta la \u00e9pica del \u201cno tengo tiempo\u201d. \u00bfDe verdad no tienes 30 segundos para escribir shutdown -h now \"Apagando con seguridad\"<\/code> o programar un -h +5<\/code> para dar margen a los procesos? Si tu tiempo vale oro, m\u00e1s raz\u00f3n para no desperdiciarlo arreglando lo que se rompe por pereza. Un apagado ordenado es como lavarte las manos en cocina: no luce, nadie aplaude, pero evita problemas que cuestan dinero.<\/p>\n\n\n\n
                                          Tambi\u00e9n me he cruzado con la excusa del \u201ces un port\u00e1til, \u00bfqu\u00e9 m\u00e1s da?\u201d. Da. Porque el port\u00e1til de hoy es el repo que ma\u00f1ana no compila, el VM que pierde una transacci\u00f3n, el contenedor que arranca raro y te roba una hora de vida. Si sigues una m\u00ednima disciplina \u2014avisar, esperar, cerrar servicios\u2014 la probabilidad de susto baja radicalmente. En mi experiencia, programar el apagado con unos minutos de colch\u00f3n me ha ahorrado m\u00e1s disgustos de los que puedo contar.<\/p>\n\n\n\n
                                          Hablemos de servidores. Un cierre a las bravas no solo es mala educaci\u00f3n t\u00e9cnica: es una falta de respeto al trabajo de tu equipo. Drenar tr\u00e1fico, parar contenedores con orden, cerrar conexiones de base de datos, sincronizar discos, avisar a usuarios con un wall<\/code>. No es ciencia ficci\u00f3n; son cinco pasos que puedes convertir en rutina. El d\u00eda que haya una incidencia, agradecer\u00e1s haber hecho \u201clo correcto\u201d cien veces antes: los sistemas bien tratados fallan menos y, cuando fallan, lo hacen de forma comprensible.<\/p>\n\n\n\n
                                          No defiendo el ritualismo vac\u00edo ni el perfeccionismo. Defiendo la profesionalidad. Y la profesionalidad se demuestra en los detalles invisibles: en no vender prisa por eficiencia; en preferir un systemctl poweroff<\/code> con dependencias claras antes que un \u201czas\u201d de bot\u00f3n; en documentar un apagado programado para que nadie se lleve un susto. He aprendido que el tiempo invertido en hacer las cosas con cari\u00f1o se recupera multiplicado cuando toca mantener o escalar.<\/p>\n\n\n\n
                                          Mi postura es simple: apagar bien es un acto de respeto. Respeto por tus datos, por tu tiempo futuro, por las personas que dependen de ese servicio y, sobre todo, por tu propio criterio profesional. No hace falta convertirlo en un dogma, pero s\u00ed en un h\u00e1bito. Uno que, como todos los buenos h\u00e1bitos, apenas se nota cuando funciona\u2026 y se nota much\u00edsimo cuando falta.<\/p>\n\n\n\n
                                          Si tienes que quedarte con una idea, que sea esta: no apagues para salir del paso; apaga para poder volver sin sustos<\/strong>. Ese peque\u00f1o cambio de mentalidad separa a quien sobrevive del que opera con calma, previsibilidad y oficio.<\/p>\n\n\n\n
                                          \n\n\n\n
                                          \u00bfT\u00fa c\u00f3mo lo haces? \u00bfEres de \u201capago y ya\u201d o tienes tu propia coreograf\u00eda? D\u00e9jame tus comentarios abajo<\/strong>: me interesa leer tus trucos, tus sustos y tus mejores pr\u00e1cticas.<\/p>\n","protected":false},"excerpt":{"rendered":"
                                          Por qu\u00e9 no conviene \u201capagar a las bravas\u201d (y qu\u00e9 hace realmente shutdown) He visto demasiadas veces el \u201cya est\u00e1, mantengo pulsado el bot\u00f3n y listo\u201d. Parece inocente\u2026 hasta que no lo es. Detr\u00e1s de un shutdown hay una coreograf\u00eda: primero se avisa a los usuarios, se env\u00eda SIGTERM a los procesos para que cierren […]<\/p>\n","protected":false},"author":1,"featured_media":7165,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"site-sidebar-layout":"default","site-content-layout":"","ast-site-content-layout":"default","site-content-style":"default","site-sidebar-style":"default","ast-global-header-display":"","ast-banner-title-visibility":"","ast-main-header-display":"","ast-hfb-above-header-display":"","ast-hfb-below-header-display":"","ast-hfb-mobile-header-display":"","site-post-title":"","ast-breadcrumbs-content":"","ast-featured-img":"","footer-sml-layout":"","ast-disable-related-posts":"","theme-transparent-header-meta":"","adv-header-id-meta":"","stick-header-meta":"","header-above-stick-meta":"","header-main-stick-meta":"","header-below-stick-meta":"","astra-migrate-meta-layouts":"set","ast-page-background-enabled":"default","ast-page-background-meta":{"desktop":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"ast-content-background-meta":{"desktop":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"footnotes":""},"categories":[952],"tags":[1097,1094,910,785,779,1143,1142,848,745],"class_list":["post-7164","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-guias","tag-almalinux","tag-centos","tag-comandos","tag-kernel","tag-linux","tag-reiniciar","tag-shutdown","tag-ssh","tag-windows"],"_links":{"self":[{"href":"https:\/\/www.hostingtg.com\/blog\/wp-json\/wp\/v2\/posts\/7164","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.hostingtg.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.hostingtg.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.hostingtg.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.hostingtg.com\/blog\/wp-json\/wp\/v2\/comments?post=7164"}],"version-history":[{"count":3,"href":"https:\/\/www.hostingtg.com\/blog\/wp-json\/wp\/v2\/posts\/7164\/revisions"}],"predecessor-version":[{"id":7169,"href":"https:\/\/www.hostingtg.com\/blog\/wp-json\/wp\/v2\/posts\/7164\/revisions\/7169"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.hostingtg.com\/blog\/wp-json\/wp\/v2\/media\/7165"}],"wp:attachment":[{"href":"https:\/\/www.hostingtg.com\/blog\/wp-json\/wp\/v2\/media?parent=7164"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.hostingtg.com\/blog\/wp-json\/wp\/v2\/categories?post=7164"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.hostingtg.com\/blog\/wp-json\/wp\/v2\/tags?post=7164"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}