Closed apiraino closed 1 week ago
Similar but not exactly the same problem here.
Change detected @ 2024-06-21 14:40:34
-> Content changed /home/XXX/site/content/bla/file.md
Checking all internal links with anchors.
> Successfully checked 0 internal link(s) with anchors.
-> Creating 31 pages (0 orphan) and 5 sections
Done in 101ms.
But Firefox (Snap Ubuntu 22.04 127.0) gives Not Found
right after saving file. Hitting F5 fixes the problem and gives back the page content.
Thanks for reporting this!
I'm not saying my commit is not at fault, but unfortunately I cannot reproduce this on macOS. I see you're both on Linux. I'll try that next. Regarding macOS:
Environment: macOS 14.4.1, Apple Silicon, Firefox 126.0. Attempt:
$ rustup update
$ rustc --version
rustc 1.79.0
$ git checkout 98843438c2f644c6cb9c3a00935abffb4c423bf8. # v1.9 + image patch commit
$ cargo clean
$ RUSTFLAGS=-g cargo build
$ ./target/debug/zola -r /my/personal/site serve
Modifications to the configuration, posts, and other pages are observed and reflected.
I also installed the latest release and ran the same tests (brew install zola; zola --version
).
I'm not sure if you folks are using the release or are building from source, but if you could by chance reproduce your issues using the test sites included in zola (test_site*
), that might help others debug the issue.
Using the release here. Will try to give a go at test_site*
asap.
Just tried on Ubuntu 20.04, Firefox 126.0, zola built from source as in my comment above and also the official Zola release downloadable from this repo. Unfortunately I was unable to reproduce. Changes are observed and reflected.
Again, not saying my commits aren't at fault, but I'll need a reproduction to go deeper.
But Firefox (Snap Ubuntu 22.04 127.0) gives Not Found right after saving file. Hitting F5 fixes the problem and gives back the page content.
I suspect this could happen if you apply a large number of changes across various content (themes, configuration, content) at once in the update debounce window, which is ~1 second if memory serves.
I'll be out this weekend unfortunately but can help more later if need be.
Content changes only. I can live with that small glitch for now, no hurry. Thanks a lot for your responsiveness :+1:
I can't reproduce it either on Mac
@apiraino , may I ask which Ubuntu [EDIT: or Debian, perhaps] version you're using?
Iwandrebeck is on 22.04 while I'm on 20.04. inotify-tools
is 3.14-8 on 20.04 and 3.22.1.0-2 on 22.04. Also glibc
is 2.31 on 20.04 and 2.35 on 22.04. I wonder if there is some behavioral difference there that might cause the issue reported here. I can set up a test in Docker, but I won't be able to do it until a few days from now.
I was able to reproduce this:
cd ~
wget https://github.com/getzola/zola/releases/download/v0.19.0/zola-v0.19.0-x86_64-unknown-linux-gnu.tar.gz
ungz zola-v0.19.0-x86_64-unknown-linux-gnu.tar.gz
git clone https://github.com/Jieiku/feeds
cd feeds
~/zola serve
echo "blahblahblah" >> templates/index.html
If I use Zola 0.18.0 instead then it detects the changes fine.
Here is my system info:
I can also reproduce this on Debian:
Linux 6.6.15-amd64 Debian 6.6.15-2 (2024-02-04) x86_64 GNU/Linux
@iamorphen thanks for the feedback and I agree no hurry to look into this. I use Debian/testing x86_64.
If you want to reproduce using a Docker container I think you can build Zola from the master branch using the Dockerfile included in this repo (it uses Debian):
$ git clone https://github.com/getzola/zola && cd zola
(I edit the Dockerfile to compile a debug build, takes less time)
$ docker build . -t zola-master
$ docker run -v $PWD:/data zola-master -r /data/test_site serve
Now, if I edit and save the file (example) ./test_site/content/posts/python.md
, zola in the docker container does not react. If I recompile the Docker image adding a git checkout v0.18.0
in the Dockerfile before compiling, I'm back at the working situation.
hope this helps!
Thanks all for your confirmations.
@apiraino , sorry to have you repeat yourself; I didn't realize Debian/testing was a version name!
Thank you for the MRE. I just built the image locally, compiled a debug build, and did some testing. Sadly, even in the container on my end, zola is observing and reacting to the changes. I made a simple oversight: inotifywatch
in the container is Debian's, but my host inotify-tools
version is the one sourcing all the fs event information because it's a kernel-level feature.
When I have time a couple days from now, I'll see about spinning up a VM or maybe just finally upgrading my Linux host to be able to reproduce on my end.
I also ran into this on Kubuntu 22.04 using zola 0.19.0 from snap after it autoupdated. 0.18 detected changes correctly.
To clarify, I don't see any "Change detected" messages so this is the same behavior as the original bug report, not the same as the other comment using snap.
Thanks for that confirmation. I had a little time to set up some reproduction environments today.
I have been trying to install Debian Test 2024-06-17 in a VM, but I think something is wrong with the current release artifacts, at least on my end. I've tried multiple ISOs (verified shas) and poked around for common and known issues but couldn't turn up anything related to my problem (bundled installer failing to find some of its own scripts), so maybe it's just me. Test is a weekly release, so the next should come out in 1 or 2 days. I'll give the next release a shot.
In the meantime I was able to install Ubuntu 24.04 and also Debian Stable 12.5.0 in VMs and was not able to reproduce. I'll give Kubuntu 22.04 a shot while waiting for the next Debian Testing release.
Strange, I have a clean install of Kubuntu 22.04 in a VM but am unable to reproduce the issue using snap-installed zola. Zola observes and reacts to changes (config, content/
, templates/
, etc.) in test_site
accordingly for me. I'll give the next Debian Test increment a whirl when it's out.
I'm also able to reproduce this on Fedora 39 with zola 0.19.0. 0.18.0 works.
❯ uname --all
Linux 6.9.5-100.fc39.x86_64 #1 SMP PREEMPT_DYNAMIC Sun Jun 16 15:57:19 UTC 2024 x86_64 GNU/Linux
One additional observation: zola 0.19.0
DOES recognize when files are added or deleted and rebuild, but it seems when I just edit a file, nothing happens.
I'll also note that the file's metadata (i.e., that shown by ls -la
) DOES show the right modification time, as expected. So that modification time changes on edit, but Zola doesn't do anything.
The following GIF shows this.
Some additional debugging information. I've cloned this repo and made the following dbg log
❯ git diff | cat -p
diff --git a/src/fs_utils.rs b/src/fs_utils.rs
index 1f70496c69d3..0c4b01657449 100644
--- a/src/fs_utils.rs
+++ b/src/fs_utils.rs
@@ -68,6 +68,7 @@ pub fn filter_events(
HashMap::default();
for event in events.iter() {
+ dbg!(&event);
let simple_kind = get_relevant_event_kind(&event.event.kind);
if simple_kind.is_none() {
continue;
Now, the events I actually see are as follows.
For the touch
[src/fs_utils.rs:71:9] &event = DebouncedEvent {
event: Event {
kind: Create(
File,
),
paths: [
"/home/lukehsiao/repos/github.com/lukehsiao/luke.hsiao.dev/content/blog/2024-06-23_new-thing.md",
],
attr:tracker: None,
attr:flag: None,
attr:info: None,
attr:source: None,
},
time: Instant {
tv_sec: 78258,
tv_nsec: 825293911,
},
}
[src/fs_utils.rs:71:9] &event = DebouncedEvent {
event: Event {
kind: Access(
Close(
Write,
),
),
paths: [
"/home/lukehsiao/repos/github.com/lukehsiao/luke.hsiao.dev/content/blog/2024-06-23_new-thing.md",
],
attr:tracker: None,
attr:flag: None,
attr:info: None,
attr:source: None,
},
time: Instant {
tv_sec: 78258,
tv_nsec: 825315611,
},
}
Change detected @ 2024-06-23 13:08:33
For the rm
[src/fs_utils.rs:71:9] &event = DebouncedEvent {
event: Event {
kind: Remove(
File,
),
paths: [
"/home/lukehsiao/repos/github.com/lukehsiao/luke.hsiao.dev/content/blog/2024-06-23_new-thing.md",
],
attr:tracker: None,
attr:flag: None,
attr:info: None,
attr:source: None,
},
time: Instant {
tv_sec: 78263,
tv_nsec: 453953197,
},
}
Change detected @ 2024-06-23 13:08:38
And for the echo "Hello world" >> ...
[src/fs_utils.rs:71:9] &event = DebouncedEvent {
event: Event {
kind: Modify(
Data(
Any,
),
),
paths: [
"/home/lukehsiao/repos/github.com/lukehsiao/luke.hsiao.dev/content/blog/2024-06-23_investing-in-interfaces.md",
],
attr:tracker: None,
attr:flag: None,
attr:info: None,
attr:source: None,
},
time: Instant {
tv_sec: 78269,
tv_nsec: 133481264,
},
}
[src/fs_utils.rs:71:9] &event = DebouncedEvent {
event: Event {
kind: Access(
Close(
Write,
),
),
paths: [
"/home/lukehsiao/repos/github.com/lukehsiao/luke.hsiao.dev/content/blog/2024-06-23_investing-in-interfaces.md",
],
attr:tracker: None,
attr:flag: None,
attr:info: None,
attr:source: None,
},
time: Instant {
tv_sec: 78269,
tv_nsec: 133499794,
},
}
Notably, if I move the dbg!
to line 99 instead (just before the config_path check added by @iamorphen), I do NOT see an event. So, it much be being filtered by one of the previous conditions.
By just poking around those conditions, I see that this event is being filtered by the first condition
let simple_kind = get_relevant_event_kind(&event.event.kind);
dbg!(&event, &simple_kind);
if simple_kind.is_none() {
continue;
}
I see
[src/fs_utils.rs:72:9] &event = DebouncedEvent {
event: Event {
kind: Modify(
Data(
Any,
),
),
paths: [
"/home/lukehsiao/repos/github.com/lukehsiao/luke.hsiao.dev/content/blog/2024-06-23_investing-in-interfaces.md",
],
attr:tracker: None,
attr:flag: None,
attr:info: None,
attr:source: None,
},
time: Instant {
tv_sec: 78544,
tv_nsec: 936740729,
},
}
[src/fs_utils.rs:72:9] &simple_kind = None
[src/fs_utils.rs:72:9] &event = DebouncedEvent {
event: Event {
kind: Access(
Close(
Write,
),
),
paths: [
"/home/lukehsiao/repos/github.com/lukehsiao/luke.hsiao.dev/content/blog/2024-06-23_investing-in-interfaces.md",
],
attr:tracker: None,
attr:flag: None,
attr:info: None,
attr:source: None,
},
time: Instant {
tv_sec: 78544,
tv_nsec: 936758269,
},
}
[src/fs_utils.rs:72:9] &simple_kind = None
These seems to confirm it is some sort of bug, but likely not related to @iamorphen's PR.
Given this, I've just opened a simple PR to treat any DataChange
as a modification.
Thanks so much! I did add the filtering logic, so I probably just missed a permutation. Notify v5/6 have much more fine-grained events than notify v4. In their own words
notify-debouncer-mini only reports an Any like event (named DebouncedEvent too), as relying on specific kinds (Write/Create/Remove) is very platform specific and https://github.com/notify-rs/notify/issues/261 https://github.com/notify-rs/notify/issues/187 https://github.com/notify-rs/notify/issues/272 to work, relying on a lot of assumptions.
We're definitely experiencing the platform-specific part hah. I'll take a look at the MR.
Environment
Zola version: 0.19, Debian/testing on Linux x86_64
Expected Behavior
When I save changes to a blog post the website should be rebuilt and the browser should refresh automatically
Current Behavior
Zola does not detect changes anymore (I don't see "Change detected @ ..." in the stdout). I need to restart zola.
Step to reproduce
Edit and save changes in a blog post in
./content
Unsure which changes impacted this, maybe #2498 ? cc @iamorphen