<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Sqlite on /var/log/janio</title><link>https://devops.sarmento.org/en/tags/sqlite/</link><description>Recent content in Sqlite on /var/log/janio</description><generator>Hugo</generator><language>en</language><lastBuildDate>Sat, 11 Apr 2026 11:28:00 +0000</lastBuildDate><atom:link href="https://devops.sarmento.org/en/tags/sqlite/index.xml" rel="self" type="application/rss+xml"/><item><title>Monitoring Files and Folders on Linux with systemd path units (and inotifywait for those without root)</title><link>https://devops.sarmento.org/en/posts/monitoring-files-and-folders-on-linux-with-systemd-path-units-and-inotifywait/</link><pubDate>Fri, 17 Apr 2026 11:05:00 +0000</pubDate><guid>https://devops.sarmento.org/en/posts/monitoring-files-and-folders-on-linux-with-systemd-path-units-and-inotifywait/</guid><description>&lt;p&gt;In the &lt;a href="https://devops.sarmento.org/en/posts/monitoring-files-and-folders-with-launchd-watchpaths-in-practice/"&gt;previous post&lt;/a&gt;, macOS&amp;rsquo;s launchd watched files and directories with &lt;code&gt;WatchPaths&lt;/code&gt; to fire scripts automatically when something changed. The model is reactive — instead of running a backup every hour or a conversion every five minutes, the system watches the path on disk and only runs the job when it detects an actual modification. No polling, no waste, no vulnerability window between the change and the action.&lt;/p&gt;
&lt;p&gt;Linux has the same capability, but implemented differently and with more options. systemd offers path units — &lt;code&gt;.path&lt;/code&gt; files that monitor filesystem paths and automatically activate an associated service when the condition is met. It is the direct equivalent of launchd&amp;rsquo;s &lt;code&gt;WatchPaths&lt;/code&gt;, with the same declarative philosophy: you describe what to watch in a configuration file, the system handles the rest. For anyone working on servers or desktops with systemd, which at this point means practically every mainstream distribution, path units are the right tool.&lt;/p&gt;</description></item><item><title>Monitoring Files and Folders with launchd: WatchPaths in Practice</title><link>https://devops.sarmento.org/en/posts/monitoring-files-and-folders-with-launchd-watchpaths-in-practice/</link><pubDate>Thu, 26 Mar 2026 18:56:00 +0000</pubDate><guid>https://devops.sarmento.org/en/posts/monitoring-files-and-folders-with-launchd-watchpaths-in-practice/</guid><description>&lt;p&gt;In the &lt;a href="https://devops.sarmento.org/en/posts/scheduling-tasks-on-macos-with-launchd-no-cron-no-workarounds/"&gt;previous post about launchd&lt;/a&gt;, scheduling worked by time: &lt;code&gt;StartCalendarInterval&lt;/code&gt; defined &amp;ldquo;every day at 7 AM&amp;rdquo; and the system took care of the rest, including recovering missed executions when the Mac was asleep. For periodic tasks like sending a daily briefing or running a maintenance script, that model works perfectly — it is the functional equivalent of cron, but integrated into the macOS lifecycle.&lt;/p&gt;
&lt;p&gt;But not every automation makes sense tied to a clock. Some tasks only need to happen when something changes. A backup that runs every hour is wasting 23 executions per day if the database was only modified once. An image conversion that runs every 5 minutes has nothing to convert most of the time, and when it finally does, up to 5 minutes have passed since the file appeared. The time-based model works, but it is polling disguised as scheduling — and polling is almost always the least elegant solution to any synchronization problem.&lt;/p&gt;</description></item></channel></rss>