hmm, Mike reported something very similiar, that goes down to: file change notification does not work (for ~/Desktop in mike's case).

Anyway, I can't reproduce your very problem here. Please strace kpdf while you rebuild your pdf and attach the log file here

Created attachment 73021 [details]
strace of kpdf

well, there's the strace ... hope it helps

please attach $KDEHOME/share/config/kpdfrc

Created attachment 73056 [details]
kpdfrc

please test the package from

/mounts/mbuild/oldboy-dmueller/1718/*/kdegraphics3-pdf*rpm

(substitute your arch as necessary)

/mounts/mbuild/oldboy-dmueller/1718 -> /work/built/mbuild/oldboy-dmueller-1718

doesn't work :(

strangely I can reproduce that on your machine but not on mine ;(

but it seems it even happens if you don't have FAM running. STRANGE. 

ok, I was tricked a bit. it only happens with fam, and it seems fam is broken: 

fileschanged -f /tmp/testfile&

touch /tmp/testfile

*watch that nothing happens*

works fine with 10.0

and works fine with famd disabled on 10.1

actually famd from 10.0 fails too, and running via -v -d indicates that it uses dnotify in both cases, but the 10.1 kernel does not send any dnotify events. 

therefore: kernel bug.

famd does a fcntl(F_SETSIG, 0x22), but it seems SIGRT2 simply doesn't get
delivered.

so you can reproduce it? 

Interestingly though, if I build the debian package for 10.1 (which is based on FAM 2.7.0 and has different dnotify patches), it works just fine. the package source is under http://w3.suse.de/~dmueller/fam/ if anyone is interested. 

*** Bug 151653 has been marked as a duplicate of this bug. ***

Do you have a comment regarding the FAM 2.7.0 package (version upgrade), which apparently seems to work fine? Would that be an acceptable workaround in case the issue with the kernel can't be fixed?

Raising severity.  Olaf, do you think this is a kernel bug - or a fam bug?

I hate that combo box

Yes, update would be fine - if done today.

Jana, can you try if with the new FAM package you experience any problems?

/mounts/mbuild/oldboy-dmueller-1769/

I think there's a problem with FAM here.

Looking at the code in autobuild, it does this:

            act.sa_sigaction = signal_handler;
            sigemptyset(&act.sa_mask);
            act.sa_flags = SA_SIGINFO;
            sigaction(SIGRTMIN, &act, NULL);

            // When the RT queue overflows we get a SIGIO
            act.sa_sigaction = overflow_signal_handler;
            sigemptyset(&act.sa_mask);
            sigaction(SIGIO, &act, NULL);

            // Block RT signals so we can fully handle each one
            // before getting the next
            sigset_t block_mask;
            sigemptyset(&block_mask);
            sigaddset(&block_mask, SIGRTMIN);
            sigaddset(&block_mask, SIGIO);
            sigprocmask(SIG_BLOCK, &block_mask, NULL);

But it never seems to unblock these signals. So small wonder the fam
daemon never sees any SIGRT2 sent by the kernel.

I tried the new FAM packages from the mbuild directory from comment #20,
but they don't work either. Except the failure mode is different. strace
shows:

3939  lstat("/tmp", {st_mode=S_IFDIR|S_ISVTX|0777, st_size=4096, ...}) = 0
3939  lstat("/tmp/testfile", {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
3939  lstat("/tmp/testfile", {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
3939  lstat("/tmp", {st_mode=S_IFDIR|S_ISVTX|0777, st_size=4096, ...}) = 0
3939  open("/tmp", O_RDONLY)            = 8
3939  fcntl(8, F_SETSIG, 0x22)          = 0
3939  fcntl(8, 0x402 /* F_??? */, 0xffffffff8000003e) = 0
3939  --- SIGRT2 (Real-time signal 0) @ a000000000010621 (441) ---
3939  write(6, "x", 1)                  = 1
3939  rt_sigreturn()                    = ? (mask now [])
3939  --- SIGRT2 (Real-time signal 0) @ a000000000010621 (441) ---
3939  rt_sigreturn()                    = ? (mask now [])
3939  --- SIGRT2 (Real-time signal 0) @ a000000000010621 (441) ---
3939  rt_sigreturn()                    = ? (mask now [])
3939  --- SIGRT2 (Real-time signal 0) @ a000000000010621 (441) ---
3939  rt_sigreturn()                    = ? (mask now [])
... for ~2000 lines, then
9939  --- SIGRT2 (Real-time signal 0) @ a000000000010621 (441) ---
3939  write(2, "*************** overflow famqueu"..., 51) = 51
3939  rt_sigreturn()                    = ? (mask now [])
... for ~7000 lines, and finally
3939  --- SIGIO (I/O possible) @ a000000000010621 (0) ---
3939  write(2, "*************** overflow sigqueu"..., 58) = 58
3939  rt_sigreturn()                    = ? (mask now [TRAP BUS FPE KILL USR1 USR2 TTIN TTOU])

So whatever it is, this looks a lot more like a problem in fam to me
than anything else.

Handing over to fam maintainer.

ah, thats fam-2.6.8-dnotify-load-fix.patch you're wondering about. I dropped that patch. 

What issue do you see specifically? the fileschanged -a -f /tmp/testfile testcase from above works for me. 

Using fam-2.7.0-1 and fam-server-2.7.0-1 from oldboy-dmueller-1769/ia64, the
testcase doesn't work at all for me. The server is endlessly invoking the
signal handler as shown above.

hmm, I can not reproduce that. I tried on 2.6.16-2-smp (x86), 2.6.16-rc6-git1-4-smp(x86_64) and on 2.6.16-rc5-2-default(ia64), and it works everywhere as expected. 

stupid question: you're sure you restarted famd? its called famd now (fam before), and the upgrade  path is currently not taking care of that (killall fam, rcfam restart fixes taht). ?

Well, I did rcfam restart. But if it works for you, let's close it.
I don't know what is going on on my machine, but it's in a sort of update
limbo.

Dirk, can you take care of this, please?

it works fine now minus the restart-on-upgrade issue.