<metaname="description"content="Every time my OpenResty package tries to update, I can't restart the service with weird errors that don't point exactly to the problem. Here's how I've learned to fix it.">
<metaproperty="og:description"content="Every time my OpenResty package tries to update, I can't restart the service with weird errors that don't point exactly to the problem. Here's how I've learned to fix it."/>
<metaname="twitter:title"content="QuickHits: OpenResty and Package Updates"/>
<metaname="twitter:description"content="Every time my OpenResty package tries to update, I can't restart the service with weird errors that don't point exactly to the problem. Here's how I've learned to fix it."/>
"headline": "QuickHits: OpenResty and Package Updates",
"name": "QuickHits: OpenResty and Package Updates",
"description": "Every time my OpenResty package tries to update, I can't restart the service with weird errors that don't point exactly to the problem. Here's how I've learned to fix it.",
"keywords": [
"quick hits", "selfhosted", "nginx"
],
"articleBody": "Turns out I wrote this back in November, but on a different machine and I never pushed my changes up to git. So here it is now!\nThe last two times I’ve run apt update \u0026\u0026 apt upgrade -y on my web server and OpenResty has an update to push out, I will get some errors including Openresty is not setup correctly. There are a few other errors in the systemctl status openresty output such as process 223478 [nginx] is still running. I might be slightly paraphrasing the errors, but that’s roughly what I’m finding.\nLike any debug session, I make sure nginx is disabling and not running (systemctl disable and systemctl stop), which I can confirm. Now, Openresty does use Nginx under the hood, so that errors makes me think it’s just conflicting services trying to run on top of each other.\nThe weirder part is when it warns me that OpenResty is not setup correctly. I didn’t change anything… so what is the update/upgrade trying to setup?\nNext, I’ll look through my config files (i.e. nginx.conf) - no changes there either and nothing that stands out as out of the ordinary.\nOne of my bad habits is that when doing this sort of debugging and running something like journalctl --since 21:45:00, I’ll look at the logs more closely with each try and fail. I should just look more closely from the beginning! But I digress.\nSince the nginx process and openresty setup errors are the most plentiful but yield nothing, I’ll look back through the logs for the single lines that I miss on my first few passes. That’s when I see it, buried between the other errors. A single line that says my pid file can’t be found.\nMy pid file for OpenResty and Nginx is stored in my /run directory, but for whatever reason, whenever OpenResty pushes out an update, it overwrites my systemd file and starts looking for the pid file under /usr/local/openresty/nginx/logs/nginx.pid. Why the file would be located under a logs directory is still beyond me, but a quick update to the systemd file, a systemctl daemon-reload and then systemctl start openresty and all my public facing services are back in action.\nAfter I fixed it for the second time, I realized I hadn’t written this down in my documentation. So I’ve now recorded it and thought I’d share it here in case it helps anyone else. I also did a bit of research after and found that even in this Digital Ocean post, it has OpenResty/Nginx’s PID file in a different location too. I couldn’t find OpenResty’s documentation on this yet, but Nginx’s Official Docs have the PID file in the same location as I am storing it. Perhaps this is just a mis-config between nginx coming natively on my linux distro and then OpenResty being installed on top of it?\nEither way - problem solved, and documentation captured. That’s a win for my day.\n",
Every time my OpenResty package tries to update, I can't restart the service with weird errors that don't point exactly to the problem. Here's how I've learned to fix it.
<divclass="post-content"><p>Turns out I wrote this back in November, but on a different machine and I never pushed my changes up to git. So here it is
now!</p>
<p>The last two times I’ve run <code>apt update && apt upgrade -y</code> on my web server and <ahref="https://openresty.org/">OpenResty</a> has an update to push out, I will
get some errors including Openresty is not setup correctly. There are a few other errors in the <code>systemctl status openresty</code>
output such as <code>process 223478 [nginx] is still running</code>. I might be slightly paraphrasing the errors, but that’s
roughly what I’m finding.</p>
<p>Like any debug session, I make sure nginx is disabling and not running (<code>systemctl disable</code> and <code>systemctl stop</code>), which I
can confirm. Now, Openresty does use Nginx under the hood, so that errors makes me think it’s just conflicting services
trying to run on top of each other.</p>
<p>The weirder part is when it warns me that OpenResty is not setup correctly. I didn’t change anything… so what is the
update/upgrade trying to setup?</p>
<p>Next, I’ll look through my config files (i.e. <code>nginx.conf</code>) - no changes there either and nothing that stands out as out of
the ordinary.</p>
<p>One of my bad habits is that when doing this sort of debugging and running something like <code>journalctl --since 21:45:00</code>, I’ll
look at the logs more closely with each try and fail. I should just look more closely from the beginning! But I digress.</p>
<p>Since the nginx process and openresty setup errors are the most plentiful but yield nothing, I’ll look back through the logs
for the single lines that I miss on my first few passes. That’s when I see it, buried between the other errors. A single line
that says my pid file can’t be found.</p>
<p>My pid file for OpenResty and Nginx is stored in my <code>/run</code> directory, but for whatever reason, whenever OpenResty pushes out
an update, it overwrites my systemd file and starts looking for the pid file under <code>/usr/local/openresty/nginx/logs/nginx.pid</code>.
Why the file would be located under a logs directory is still beyond me, but a quick update to the systemd file, a
<code>systemctl daemon-reload</code> and then <code>systemctl start openresty</code> and all my public facing services are back in action.</p>
<p>After I fixed it for the second time, I realized I hadn’t written this down in my documentation. So I’ve now recorded it and
thought I’d share it here in case it helps anyone else. I also did a bit of research after and found that even in this
d="M512 62.554 L 512 449.446 C 512 483.97 483.97 512 449.446 512 L 62.554 512 C 28.03 512 0 483.97 0 449.446 L 0 62.554 C 0 28.03 28.029 0 62.554 0 L 449.446 0 C 483.971 0 512 28.03 512 62.554 Z M 269.951 190.75 L 182.567 75.216 L 56 75.216 L 207.216 272.95 L 63.9 436.783 L 125.266 436.783 L 235.9 310.383 L 332.567 436.783 L 456 436.783 L 298.367 228.367 L 432.367 75.216 L 371.033 75.216 Z M 127.633 110 L 164.101 110 L 383.481 400.065 L 349.5 400.065 Z" />
</svg>
</a>
</li>
<li>
<atarget="_blank"rel="noopener noreferrer"aria-label="share QuickHits: OpenResty and Package Updates on linkedin"
