<tomas <at> tuxteam.de> writes:
>
>
> On Fri, Jun 17, 2016 at 01:12:00PM +0000, Andrey wrote:
>
> [...]
>
> But writing a minimal Tcl program and running it through strace might shake
> out whether they do any fcntl behind the scenes...
>
o.k.
serv:~$ cat >t.tcl
set f [open tst.tst w]
puts $f test
close $f
serv:~$ strace tclsh t.tcl
...
open("tst.tst", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 5
fcntl(5, F_SETFD, FD_CLOEXEC) = 0
ioctl(5, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS,
0x7ffc5a3bb3e0) = -1 ENOTTY (Inappropriate ioctl for device)
write(5, "test\n", 5) = 5
close(5) = 0
...
as it was expected - nothing miraculous
> > how it could be when I tried to save a file from Emacs and got 'Resource
> > temporarily unavailable'
> >
> > well, I included all open(2) errors in your test:
> >
> > int nerr[]={EACCES,EEXIST,EFAULT,EFBIG,EINTR,EINVAL,EISDIR,ELOOP,
> > EMFILE,ENAMETOOLONG,ENODEV,ENOENT,ENOMEM,ENOSPC,ENOTDIR,ENXIO,
> > EOPNOTSUPP,EOVERFLOW,EPERM,EROFS,ETXTBSY,EWOULDBLOCK};
>
> I see. So still EWOULDBLOCK is the likely "culprit".
>
I am afraid not, it has nothing to do with NONBLOCKED i/o,
it's normal BLOCKED.
> I see three things you might try:
>
> - sift through the kernel sources watching out for a possible
> EWOULDBLOCK return on open()
>
> - have a look at the Emacs sources
>
there is nothing particular about emacs
it my have been 'bash' or anything that uses libc
> - use the LD_PRELOAD trick [1] to install a little spy on open()
> and let the system running for a while like this (the last one
> depends on the ratio of how critical your system is and how
> corageous you are
>
> regards
> [1]
https://rafalcieslak.wordpress.com/2013/04/02
/dynamic-linker-tricks-using-ld_preload
-to-cheat-inject-features-and-investigate-programs/
>
Thank you Thomas! it is something I'll look at later, although system is
quite busy and critical.
I am still wondering could be systemd somehow imposes limits on resources,
not having a clue what should I watch for.
All the best,
Andrey
