Re: getrlimit standards
Ted
My personal spin on this is included below (bear in mind that I've not
discussed this with the working group....)
On Oct 6, 6:30pm in "getrlimit standards
>
> You that if I had questions on the Unix 98 spec I should let you
> know..... so here's one. The description for setrlimit() appears to be
> very ambiguous as to what happens if RLIMIT_FSIZE is exceeded. The text
> says this:
>
> >RLIMIT_FSIZE
> > This is the maximum size of a file in bytes that may be created by
> > a process. If a write or truncate operation would cause this limit
> > to be exceeded, SIGXFSZ is generated for the thread. If the thread
> > is blocking, or the process is catching or ignoring SIGXFSZ,
> > continued attempts to increase the size of a file from end-of-file
> > to beyond the limit will fail with errno set to [EFBIG].
>
> Now then, what does "continued attempts" mean? Normally if SIGXFSZ is
> not caught, the process aborts. Currently Linux (modulo a bug, which is
> what called this to my attention) will send a SIGFXSZ signal, and return
> EFBIG. If the process doesn't die from the SIGFXSZ, then it will get
> the EFBIG error.
>
I believe the wording is this way so that it links with the
EFBIG error condition in write() [ and many of the stdio functions ]
which is brought in from POSIX.1 [.1 does not have the SIGXFSZ signal
at the moment].
The write() manual page states:
[EFBIG]
An attempt was made to write a file that exceeds the
implementation-dependent maximum file size or the process'
file size limit.
Thus to my mind "continued attempts" really means "repeated attempts".
On the first attempt an error may not occur since write() may be
able to write some data up to the max file size and return the
number of bytes successfully written. On a repeated/continued attempt
no bytes are successfully written and the write() fails and
sets errno to EFBIG.
> This appears to be compliant but for the "continued attempts" clause.
> If process catches SIGXFSZ and ups the limit, should the system call
> restart and retry the write? Or should it return the number of bytes
> written (possibly zero)? I would presume that making the system call
> restart and retrying the write would be the most friendly approach, but
> it's also the hardest to implement. Also, traditionally System V
> systems didn't handle restarting system calls; so should write() return
> EINTR instead?
I think the restartable system calls (set by SA_RESTART in sigaction)
only applies to EINTR cases. And that the behaviour for max file
size is defined. On the first write() that hits the limit,
a SIGXFSZ is sent to the process, the write() should return the number of
bytes successfully written which may be zero, assuming your handler
ups the limit then the next write would if it does not exceed the new limit
succeed.
>
> This appears to be a corner case where the specification is not explicit
> about what should happen. I'm curious whether this is
> accidental (i.e., an oversight) or deliberate (i.e., a desire to allow
> multiple vendor's OSs to be compliant).
>
I'm not sure on that, looking at the SVID it has the same wording so
I suspect that we are seeing some historical wording passed down. This
is something we can improve on in a future revision:-)
> And what do you think Linux should do in the ideal case? (Afterwards we
> can see how hard it is to implement it --- but something as vague as
> "continued attempts" makes me nervous.)
>
See above, I hope that helps
regards
Andrew
Reply to: