Unhappy with #DockerDesktop on #macOS? Give #Colima a try!
It's a free and open #container runtime for macOS. It now supports the macOS #virtualization framework, #virtiofs for fast volume mounts and forwarding #inotify events for hot/live reloading. It can even provide a #containerd, #kubernetes or #incus runtime.
https://github.com/abiosoft/colima
(I would've preferred #podman, as that's what I'm mostly using in production, but it still doesn't support forwarding inotify events on macOS)
#syslog_ng 4.8.0 improved the wildcard-file() source on #FreeBSD and #MacOS. Version 4.9.0 will do the same for #Linux by using #inotify for file and directory monitoring, resulting in faster performance while using significantly less resources. https://www.syslog-ng.com/community/b/blog/posts/testing-the-new-syslog-ng-wildcard-file-source-options-on-linux
@feld @pertho Doesn't feel like something I'd like to try though. It would be pretty much #FreeBSD-specific, but worse than that, you shouldn't rely on dtrace availability, as it's an optionally loadable profiling tool (so, it would also be a "misuse" regarding purpose). Related to that, I'm pretty sure it requires superuser privileges for everything, which would be another issue for some general-purpose application software.
No, the "canonical" solution for filesystem watching on a BSD system is indeed #kqueue. And unfortunately, it does fall short a bit compared to #Linux' #inotify. For my #xmoji tool, I wanted notifications about any change on the runtime configuration file, and additionally to the pure #POSIX solution of periodically calling stat() (which is stupid, but still works for a single file), I implemented backends for both inotify and kqueue. For just a single file, kqueue's requirement of having an open file descriptor is just a minor annoyance, but you can deal with that. Note it's not as simple as it sounds in any case, e.g. when the file is deleted, you want to watch the directory of course, so you learn when it's re-created ... which with kqueue requires opendir() 🙈 ... still doable. But for scenarios where you want to watch a whole tree with potentially lots of files and directories, this is really bad and #inotify really shines.
@pertho The only little drawback compared to epoll is the lack of atomic signal mask setting, so you need a bit more code and a thoughtful structure to handle signals in the same loop. Apart from that, indeed much better than #epoll.
Unfortunately, it's not beter than inotify (for a completely different purpose, #file #monitoring ... kqueue covers them all). With #inotify, you can for example set a #watch by path, while #kqueue requires opened file descriptors. 😞
/* We found an mark in the idr at the right wd, but it's not the mark we were told to remove. eparis seriously fucked up somewhere. */
https://elixir.bootlin.com/linux/v6.13.3/source/fs/notify/inotify/inotify_user.c#L481-L485
is there a low-power "detect the computer is idle" api in #linux? i've attempted to use #inotify against input devices (following the example of https://aur.archlinux.org/packages/brightd) but that's somewhat cpu intensive ...
i could do tricks by sleeping say 25 sec and then set up the inotify and select on it with a 5 sec timer, or so... then it's low power for 25 sec and the user has to be active in the 5 sec...
this tradeoff between the "resolution" of idle detection and the power usage seems regrettable
Today's lesson is that #inotify is a Linux 🐧 construct and in BSD land 👹 monitoring the file system is part of #kqueues turf. Oh man there sure are alot of man pages and long docs to read ... or are there. Thank you watchdog (https://github.com/gorakhargosh/watchdog) and thank you Mickaël Schoentgen and Yesudeep Mangalapilly
#Python to the rescue 🐍 🐍 🐍
https://python-watchdog.readthedocs.io/en/stable/api.html
Podman 下的 inotify 問題
手上有個前端專案的開發環境是在 Linux container 上跑起來，有支援修改時 auto reload，我在 Linux Desktop 上面跑起來沒有問題，但在 MacBook (M 系列) 上開發就發現不會 auto reload，這樣改起來頗麻煩...
馬上有在猜是不是 inotify 的問題，先翻了一下資料，發現 inotify 在 Podman 上沒有被完整支援：「file changes not registered by inotifywait inside podm
#Computer #Linux #MacOS #Murmuring #OS #Software #container #docker #inotify #linux #mac #macos #podman
Side effect of my work on #inotify support for #Xmoji: Even more virtual desktop choices in my personal #guacamole dashboard! 😎
hastur – Windows Server 2022, in bhyve
miranda – Linux (Debian), in bhyve
greg – FreeBSD, in a VNET jail
All hosted on the same physical #FreeBSD server. #bhyve and #jails just rock 👍
Found and fixed, the issue was with my compiler tests, compiling to stdout fails with GCC 🤯
https://github.com/Zirias/xmoji/commit/15a6f1a2d018b6bab14b4a623f7f4f02e5ab69ff
Now my CI build on github fails, and that's expected because #inotify is finally enabled in the build while most of the implementation is still missing 😂
Finally, my new virtual #Linux desktop seems to work, so I can tackle implementing the #inotify backend for #Xmoji.
First surprising issue: It doesn't even detect inotify so far 🙈
minor news on my #Xmoji (#X11 #emoji #keyboad): The #kqueue backend for watching the config file now works on #FreeBSD (as far as I can tell, hard to test every possible edge case).
I also want to add #inotify for #Linux. I just realized I'll need a Linux machine to properly do that. So, installing Debian in bhyve. Joined my samba domain, mounted my #kerberos-encrypted #NFS homedirs, couldn't login, no idea where to find diagnostic output with dreaded systemd ... but right now I found the solution to the problem:
# ln -s /usr/bin/zsh /usr/local/bin/zsh
😂🤪
Finally some progress again with #Xmoji (#X11 #emoji #keyboard): Added the history tab!
History is persisted in a config file that should also hold other runtime config later and is watched for changes. For now, I only implemented the naive portable "watching" method periodically calling #stat ... backends for #FreeBSD #kqueue and #Linux #inotify will (hopefully!) follow 😉
General thoughts about configuration of "modern" X11 desktop apps:
Next step for my #Xmoji #X11 #emoji #keyboard will be adding runtime configuration. Sending fake key-press events has some parameters (how long to wait before restoring the keymap, which hacks/workarounds to enable for sending the events ...) that should be configurable at runtime. A history of recently used emojis should be available and persisted. There may be more things to add here later (allow multiple instances? show and use a "tray icon"?).
I already have configurations for rendering and appearance aspects. For these, I use classic #Xresources. Even if they aren't that popular any more nowadays, they're IMHO the perfect place for such things: The configuration is tied to the currently running X server. They also offer a fine-grained scheme to match settings to classes and instances (e.g. individual widgets). So, learn about them and enjoy! 😄
Runtime configuration is a different beast. Back in the days, you had these dialogs with the typical three buttons, "apply" made changes effective without persisting them, "ok" persisted them and "cancel" reverted anything not persisted yet. There was also often some action available to re-load the currently persisted configuration.
Well, not any more. Nowadays, the predominant user experience is applying and persisting any change instantly. This is nice, but it creates an interesting issue, which most applications choose to just ignore. If either multiple instances of the same app are allowed to run for the same user on the same host, or the configuration is stored on some network share used by multiple hosts, inconsistencies are easily possible, with multiple instances of the app having a different idea about the "current" configuration and just persisting that on any change, overwriting what a different instance might have changed.
I came to the conclusion that I shouldn't ignore that issue for Xmoji. At least for persisting the emoji history, it would be unacceptable.
So, the obvious solution is that the configuration file must be monitored, so that any "remote" change can also be applied immediately in every running instance. The naive and portable solution for monitoring is to periodically stat() the file to check the modification timestamp. On network filesystems, that's the only thing that will work. I'll probably start with implementing just that.
For local files, there are platform-specific ways to obtain notifications from the OS (or kernel), which is better (immediate notification) and more efficient. #Linux has #inotify, #FreeBSD has #kqueue. I'm currently exploring docs and doing a few pocs for these interfaces as well ... this might really take a while, let's see. 🙈
Please comment with your thoughts about that if you have any! 😉
Отслеживание изменений в директории с помощью Inotify
Столкнулся с задачей, где необходимо было отслеживать в ОС Linux изменение файла в директории на чистом С++. Так как чистый С++, QtCreator с его QFileSystemWatcher сразу отпадал, из-за того что необходимо было подключать QObject . В итоге решил пользоваться линуксовой функцией Inotify.
When I take a picture on my phone, #syncthing puts it on the network storage where #inotify sees it and signals #incrond to run 'index' for #photoprism
in other words:
in less then ten seconds every picture taken with my phone is available in my photo-library application and backed up, all using free and open source software.
