<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