<div dir="ltr">Hi list,<br><br>Thank you for offering the great package incoporating many packages<br>under one umbrella.<br><br>I would like to report a problem and patch.<br><br>I have experienced a very rare and hard-to-diagnose problem<br>
presumably caused by low free file space condition during installation<br>of TeX-related packages, especially texlive package.<br><br>This happened under Debian, but the problem can happen elsewhere, too.<br><br>PROBLEM:<br>
<br>After a seemingly successful installation, trying to run tex-related<br>commands from the tex installation failed because it could not find<br>and produce .fmt files.<br><br>A discussion in Debian bug report system indicates that the<br>
cause is very likely to be low free-space condition.<br><a href="https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=748962" target="_blank">https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=748962</a><br><br>But there was no smoking gun back then.<br>
<br>What irked me most is Debian GNU/Linux installer did not report any<br>abnormal conditions during the installation, and it printed that it<br>had successfully loaded TeX-related packages.<br>But the end result was that the installation was not usable later<br>
since .fmt files were not created properly. This confused me to no end.<br><br>DEBUGGING:<br><br>So I started debugging.<br><br>I started on the assumption that some commands that are executed<br>during the installation of TeX-related packages including TeX-live<br>
don't return error exit code properly when they encountered errors due<br>to low-space condition (errno == ENOSPC). So I looked for potential<br>issues in this regards when I start debugging.<br><br>Naturally I looked at .fmt files creation which was screwed up as<br>
prime suspect.<br><br>FILE: fmtutil.sh is the most likely culprit.<br><br>(Others may remain, but I have identified serious bugs in fmtutil.sh<br>and am proposing a patch.)<br><br>After a few days reading and testing the code, here are an observation<br>
and possible improvements that can make a script file used in<br>TeX-live, fmutils.sh, more robust in the face of a low free-space<br>condition, and hopefully make it report possible error as exit code to<br>invoking process in a more reliable way.<br>
<br>============================================<br>To make a VERY LONG story short, here is a summary:<br>============================================<br><br>Most compelling bug:<br><br>An "mv" command was executed in "if" command portion, but there<br>
was NO "else/fi" part to handle its error!<br>I think this is the culprit that fails to return the error code so<br>that the Debian package installer could properly failed the<br>installation.<br><br>Now, it has a proper error handler in my proposed patch. I also noticed<br>
empty (0-byte) .fmt files under /var/lib/texmf/ hierarchy when this "mv" command<br>failed due to full file system condition.<br>So I decided to remove the bogus partial file when "mv" failed.<br><br>
Also, the trap processing introduced by "set -e" may not be<br>
most appropriate and so I changed it a little.<br><br>So, To wrap up, I am attaching a patch.<br>Please find below the diff of modified fmtutil.sh<br><br>fmtutil is actually /usr/share/texlive/texmf-dist/scripts/texlive/fmtutil.sh<br>
<br>diff of modified fmtutil in /tmp/fmtutil.sh<br>and<br>/usr/bin/fmtutil which is a symlink to the script under<br>/usr/share/texlive/...<br>was produced and attached.<br><br>To be exact, I looked at Debian version of the fmtutil.sh, and<br>
so there may be a few Debian-specific changes in the original<br>fmtutil.sh with which I started.<br><br><br>Thank you in advance for your attention.<br><br>---<div><br>Here is the MUCH LONGER version.<br><br>===============<br>
VERY LONGER version<br>
===============<br><br>Here are the gory details that are behind the proposed patch.<br><br>There are a few issues with the current code of fmtutil.sh (I downloaded<br>TexLive 2013 source code from TUG web site, and am describing the<br>
issue. If in 2014 version, it has improved, so much the better.)<br><br>To be exact, I looked at Debian version of the fmtutil.sh, and<br>so there may be a few Debian-specific changes in the original<br>fmtutil.sh with which I started.<br>
<br><br>(1) (Unintended or intended?) extra execution of a command when it<br> fails in one user-defined function, "verbose" .<br><br>(2) When an error of producing a format file is encountered (possibly<br> due to full file system condition), during processing when "--all"<br>
is passed, the error seems to be sometimes ignored, and so the<br> error code is not returned as exit code.<br><br>(3) The fmtutil.sh script in TeXLive 2013 does not seem to have<br> "set -e" to exit as soon as an error occurs during the script<br>
execution. This flag is in Debian version. I think it is a good<br> idea to have it in the script.<br> If "set -e" is in TexLive 2014 version already, so much the better.<br><br>(4) logged error/report messages are not flushed sometimes.<br>
<br> Contrary to popular belief, calling "log_failure" does not stop<br> processing immediately when fmtutil.sh is trying to produce many<br> .fmt files ("--all" flag). All it does is to accumulate the error<br>
messages as errors are encountered. At the end of the execution,<br> when user-defined function "byebye" is called, the accumulated<br> error messages are printed and error return is taken.<br> "log_warning" is similar and only that it does not cause the<br>
script to return by error exit code. (I modify it to report error<br> in my patch proposed here.)<br><br> This operation is in theory. Unfortunately, there seems to be a<br> loop-hole, an error path that may not invoke "byebye", and thus we<br>
may not see the error messages flushed at all :-(<br><br>The second issue above could be the cause of possible reason why I did<br>not see the Debian installer fail and .fmt files were not produced<br>when there was a very low free-space condition during installation.<br>
(And I am more or less convinced that the missing handling of the<br>failure of an "mv" command executed in if-expression part is the<br>cause of fmtutil.sh not reporting the error under low-space condition.)<br>
<br>So, I am proposing a patch here. It consists of changes of functional<br>specification in a few places and a set of added comments for better<br>maintainability.<br><br>With this patch, fmtutil.sh is much more robust, and the installer<br>
will catch more errors due to low free-space conditions during the<br>installation with the patch, and this should save support man-hours<br>later on.<br><br>I know everyone is busy with 2014 release. So once the dust settles<br>
down, I would appreciate to have someone look into this matter without<br>hurry.<br><br>VERY LENGTHY DESCRIPTION:<br><br>Sorry about this lengthy writing, but the code seems to have lasted<br>more than a dozen years, and there are so many things that accumulated<br>
over the years that introduce possible errors during low-space<br>condition. So I am afraid that you have to read the long description<br>below to understand some subtle changes proposed in the patch.<br><br>"fmtutil-sys --all" may not return error exit code under low free space condition.<br>
<br>(1) I found that fmtutil.sh has a slightly buggy function.<br>(fmtutil.sh is part of texlive-base and is called eventually when<br>fmtutil-sys --all is called during installation to create .fmt files.)<br><br>I am attaching a patch to re-define the problematic function and to<br>
replace log_warning with log_failure to signal the calling program<br>that a failure occurred.<br><br>Summary regarding "verbose": Well, "verbose" alone is worth a single<br>post :-(, but I am including the whole description in one post.<br>
<br>There is one shell-function "verbose()" which is used to invoke a<br>passed command and redirect stderr based on the exit value of<br>$mktexfmtMode (which is either "true" or "false").<br>
<br>Here is the definition of "buggy" verbose()<br>from fmtutil.sh ( linked from /usr/bin/fmtutil to<br>/usr/share/texlive/texmf-dist/scripts/texlive/fmtutil.sh)<br><br>###############################################################################<br>
# verbose (cmd)<br># execute cmd. Redirect output depending on $mktexfmtMode.<br>###############################################################################<br>verbose()<br>{<br> $mktexfmtMode && ${1+"$@"} >&2 || ${1+"$@"}<br>
}<br><br><br>This function as it is written today is buggy in the sense that if the<br>command fails when $mktexfmtMode is "true", the failing command is<br>executed TWICE (!). The first execution is with the redirection of<br>
STDERR. The second execution is without such redirection. I think<br>this is quite unintentional.<br><br>Or could it be intentional?<br><br>Maybe the thought was that if the redirected execution failed, let us<br>re-execute the command without error redirection so that the error is<br>
visible on invoking console.<br><br>But there is a ramification regarding exit code if this were the<br>original intention.<br>The exit code from this execution of<br>"verbose other command options ..." becomes,<br>
when the command fails on the LEFT Hand Side (LHS) of "||",<br>it is the exit code of the executed command (without re-direction) on<br>the right-hand side (RHS) of "||".<br><br>Under very space-tight conditions of a local file system, the failure<br>
may happen while the stderr is re-directed (LHS), but a failure may not<br>happen when the command is executed as is without re-direction on the RHS (!)<br>(However, if the command only tries to produce .fmt file, then the<br>
this may not be relevant?)<br><br>Also, more to the point. I am not entirely sure what is the returned<br>exit code when the RHS of "||" fails, depending on the version of the<br>shell. We may not get the error condition that triggers 'trap' at all (!?)<br>
That is one reason I want a mundane use of if/then/else/fi proposed in<br>the patch.<br><br>cf. Shell version dependency. Background:<br><br>[1] Here is a quote regarding the condition of error handled by trap from<br>"bash" man page.<br>
<br>About "trap [-lp] [arg] [sigspec ..]<br> ...<br> If a sigspec is ERR, the command arg is executed whenever a simple<br> command has a non-zero exit status, subject to the following<br> conditions. The ERR trap is not executed if the failed command is part<br>
of the command list immediately following an until or while keyword,<br>* part of the test following the if or elif reserved words, part of a<br>* command executed in a && or || list, or if the command return<br>
status is being inverted using !. These are the same conditions obeyed<br> by the errexit option.<br><br> => I am not entirely sure if the failure in the RHS of "||" in<br> |verbose()| is trapped because of the above description.<br>
In the current version, maybe.<br><br>[2] A quote: "dash" man page (under Debian GNU/linux, it seems /bin/sh is<br>a link to /bin/dash),<br><br> -e errexit' If not interactive, exit immediately if any untested<br>
command fails. The exit status of a command is considered to be<br> explicitly tested if the command is used to control an if, elif,<br> while, or until; or if the command is the left hand operand of an<br> ''&&'' or ''||'' operator.<br>
<br> => OK, so the left hand execution when it fails does not cause the<br> trap to take effect even if it fails, and only the failure on the<br> RHS is noticed. Hmm...<br><br>[3] Venerable Single Unix Specification OpenGroup Posix specification<br>
document.<br><a href="http://pubs.opengroup.org/onlinepubs/7908799/xcu/chap2.html" target="_blank">http://pubs.opengroup.org/onlinepubs/7908799/xcu/chap2.html</a><br><br>This is POSIX!<br><br>-e<br> When this option is on, if a simple command fails for any of the<br>
reasons listed in Consequences of Shell Errors or returns an exit<br> status value >0, and is not part of the compound list following a<br> while, until or if keyword, and is not a part of an AND or OR<br> list, and is not a pipeline preceded by the "!" reserved word,<br>
then the shell will immediately exit.<br><br> => So it doesn't say explicitly that the failure of the right<br> hand side of "||" triggers the error processing defined by<br> trap immediately. Thus, POSIX accommodates the both positions of<br>
"dash" and "bash" beautifully :-)<br><br> cf. Here "AND" list or "OR" list is defined in POSIX.<br> AND Lists<br> The control operator && denotes an AND list. The format is:<br>
<br> command1 [ && command2] ...<br><br> First command1 will be executed. If its exit status is zero,<br> command2 will be executed, and so on until a command has a<br> non-zero exit status or there are no more commands left to<br>
execute. The commands will be expanded only if they are executed.<br><br> Exit Status: The exit status of an AND list will be the exit<br> status of the last command that is executed in the list.<br><br> OR Lists<br>
The control operator || denotes an OR List. The format is:<br><br> command1 [ || command2] ...<br><br> First, command1 will be executed. If its exit status is<br> non-zero, command2 will be executed, and so on until a command<br>
has a zero exit status or there are no more commands left to<br> execute.<br><br> Exit Status: The exit status of an OR list will be the exit<br> status of the last command that is executed in the list.<br>
<br><br>Also, in fmtutil.sh, originally trap processing invokes "cleanup" only<br>and message buffer was not flushed. Now trap calls "byebye" and<br>message is flushed. BASH allows the 'ERR' specification, which<br>
would trigger trap processing, as a value to specify the error of a<br>command execution in shell script. When "set -e" is used and a command<br>fails, a trap would be taken with "ERR". But this is only available<br>
in BASH. In the end, I inserted "if" checks in a few places instead<br>of relying on "set -e".<br><br><br>FURTHER DETAILS:<br><br>DETECTIVE WORK<br><br>My bet was that when "fmtutil-sys --all" was called to create all<br>
required .fmt files on my PC, some invocations of it failed due to low<br>free-space conditions but did not return the exit error code<br>correctly.<br><br>So I checked the calling sequence that would happen when "--all" is<br>
passed to fmtutil, and found that the user-defined functions are<br>called in this order.<br><br>main<br> -><br> recreate_all<br> -><br> recreate_loop<br> -><br> run_initex<br> -><br> verbose<br>
<br>In "run_initex", the following piece of code is where the meat of<br>processing takes place.<br><br>--- quote<br> verboseMsg "$progname: running \`$engine -ini $tcxflag $jobswitch $prgswitch<br>$texargs' ..."<br>
<br> # run in a subshell to get a local effect of TEXPOOL manipulation:<br> (<br> # If necessary, set TEXPOOL. Use absolute path, because of KPSE_DOT.<br> $localpool && { TEXPOOL="`pwd`:$TEXPOOL"; export TEXPOOL; }<br>
verbose $engine -ini $tcxflag $jobswitch $prgswitch $texargs<br> ) </dev/null<br>--- end quote<br><br>I realized that "verboseMsg" is to print out what is going on to the<br>log.<br>and somehow user-defined "verbose" command was used to invoke the<br>
command, "$engine -ini $tcxflag $jobswitch $prgswitch $texargs".<br><br>This slightly buggy function is called within "run_initex"<br>(yes, that is where the fmt files are created eventually!)<br><br>
This "verbose" function should be rewritten to avoid the re-execution<br>
of the command "${1+"$@"}" when it fails when "$mktexfmtMode" is true.<br><br>Correction-1:<br><br>verbose()<br>{<br> if $mktexfmtMode<br> then<br> ${1+"$@"} >&2<br>
else<br> ${1+"$@"}<br> fi<br>}<br><br>If you are in doubt, you can see the repeated execution of command in<br>the following simplified test script.<br><br># cat /tmp/t-buggy.sh<br>#!/bin/sh<br>#<br>
<br># This script is to show that a failure of<br># a command executed in verbose may be executed twice.<br><br># false is not a good failure command sample<br><br>set -e<br><br>rc=0<br><br>verbose() # original. This is buggy!<br>
{<br> $mktexfmtMode && ${1+"$@"} >&2 || ${1+"$@"}<br>}<br><br>#<br>run_initex()<br>{<br> # run in a subshell to see if this changes anything.<br> (<br> echo "run_initex called"<br>
# DO SOMETHING THAT SHOULD FAIL<br> cp /dev/null /etc<br> ) </dev/null<br>}<br><br># should succeed<br>verbose echo "hello, world"<br>echo "rc = $?"<br><br>echo before cp /dev/null /etc<br>
# should fail<br>verbose cp /dev/null /etc<br>echo "rc = $?"<br><br>echo before subshell execution<br># should fail<br># run in a subshell ...<br> (<br> verbose cp /dev/null /etc<br> ) </dev/null<br>echo "rc = $?"<br>
<br>echo before run_initex<br><br>mktexfmtMode=true<br>rc=1<br># should fail since run_initex invokes false inside.<br>verbose run_initex $rc<br>echo "rc = $?"<br><br>echo before cp /dev/null /etc<br># should fail under ordinary user account.<br>
verbose cp /dev/null /etc<br>echo "rc = $?"<br><br>exit 0<br><br><br>The above is the content of the script.<br>Now let us run it.<br><br>$ /tmp/t-buggy.sh || echo failure<br>hello, world<br>rc = 0<br>before cp /dev/null /etc<br>
cp: cannot create regular file '/etc/null': Permission denied<br>cp: cannot create regular file '/etc/null': Permission denied<br>failure<br>$<br><br>Please notice the repeated execution of the failed command by "verbose()".<br>
That is because when "$mktexfmtMode" is true the passed command is<br>executed with redirection.<br>In this case, the passed command "cp /dev/null /etc" should fail for<br>ordinary user.<br>But it is then re-executed because of ||. Shell figured that Left-Hand<br>
Side (LHS) failed and so tried to execute Right-Hand Side (RHS), too.<br><br>Now, when I rewrite verbose() in the suggested manner, what happens?<br>With fixed verbose (as in correction-1 above):<br><br>$ /tmp/t-OK.sh || echo fail<br>
hello, world<br>rc = 0<br>before cp /dev/null /etc<br>cp: cannot create regular file '/etc/null': Permission denied<br>fail<br>$<br><br>Great. It is executed only once and I think this is the intended behavior.<br>
<br>BTW, suppose the intention of "verbose" was to capture whatever error<br>message (to file descriptor 2) to a file associated with STDOUT (file<br>decriptor 1) [I may got confused here and 1 and 2 may be swapped] and<br>
later check error condition by searching for a certain string pattern<br>in saved re-directed output, we may encounter a subtle problem *IF and<br>ONLY IF* the command fails during an (almost) full file system condition<br>
when output is redirected (LHS), AND IF it succeeds without such<br>redirection (RHS).<br><br>Now, if the original intention was to run the command in<br>non-redirected manner when it fails in re-directed manner, an explicit<br>
test using if/then/fi is still better since the individual command is<br>more likely to cause the shell execution to trap if an error occurs,<br>and return exit code as it should (and we don't have to worry about<br>
the obscure trap handling of different version of shells to boot!)<br>
<br>Correction-1':<br>verbose()<br>{<br> _v_repeat=false;<br> if $mktexfmtMode<br> then<br> ${1+"$@"} >&2 # failure should trigger trap in this form.<br> if test $? = 0<br> then<br>
:<br> else<br> _v_repeat=true;<br> fi<br> fi<br> if $_v_repeat<br> then<br> ${1+"$@"}<br> fi<br>}<br><br>(2) log_warning<br><br> Near line 765, we have the following code snippet in fmtutil.sh:<br>
<br>--- quote<br> if test -f "$fmtfile"; then<br> grep '^! ' $format.log >/dev/null 2>&1 &&<br> log_warning "\`$engine -ini $tcxflag $jobswitch $prgswitch $texargs'<br>
possibly failed."<br>--- end quote<br><br>Like I said in (1) above, format.log may have failed to capture the error message<br>under a very space-tight condition in "verbose()". That is tough.<br><br>Anyway, I wanted see the "log_warning" to be changed to a<br>
failing "log_failure" instead. The reason is that log_warning in the<br>current form prints a one line warning and then kept on producing<br>other .fmt files merrily and at the end.<br>And it seems to forget about the error return<br>
code from the "failure" noticed by '\! '.<br><br>Why? As I re-read the code, when user-defined function "byebye" is<br>called to exit the script execution, if a previous call to "log_warning"<br>
has been made, then the accumulated warning message is printed, but no<br>error processing is done. Only when "log_failure" has been called at<br>least once, the fmtutil.sh returns error exit code of 1 as a whole.<br>
<br>I should note that I was looking at the console when the TeX-related<br>packages were installed (eventually the installation turned out to be<br>broken) I did not notice any strange output (I may have missed a line<br>
or two, to be sure.) Can there be an exit path that does not call<br>"byebye" and omit printing the accumulated error and warning messages<br>just in case?<br><br>I bet there is!<br><br>If "set -e" is set as in Debian version of fmtutil.sh, then any error<br>
caught such as, say, the failure of<br><br> cp "$poolfile" $engine.pool<br><br>near Line 729 under near-full file system condition<br>would cause the shell execution to stop and take exit processing.<br><br>
Then the setting of<br>
<br> trap 'cleanup 1' 1 2 3 7 13 15<br><br>near line 164, inside the user-function of "setupTmpDir()"<br>will cause the script to exit WITHOUT calling the<br>dumping of accumulated messages performed by "byebye".<br>
<br>"cleanup" referred to in the trap statement above is a user-defined<br>function.<br><br>(Well, at least, it does return exit code 1 when 'cleanup 1' is<br>executed. So why didn't we see an error that would have caused Debian<br>
installer to report the installation failure eventually. I now know<br>why: unpatched fmtutil.sh failed to properly handle the error of an<br>"mv" command executed in if-command.)<br><br>Maybe we could change the above trap into the following so that<br>
message buffer is flushed.<br><br> trap 'byebye' 1 2 3 7 13 15<br><br>Norbert suggested we should not stop right there as soon as the first<br>error was encountered and should try to produce other .fmt files as<br>
many as we can. I concur. So to make this intention clear, I agree to<br>continue using "log_warning" when "grep" failed.<br><br>The code in fmtutil.sh tried to handle errors using "set -e" (in<br>
Debian version), "trap ...", etc. But I am afraid that the error<br>handling was not so well structured using "set -e", "trap ...", etc.<br><br>So I am suggesting the patch to make it a Little more<br>
organized or straight-forward and make sure that "byebye" is called<br>even in the face of unexpected error, but I am not sure if I<br>succeeded perfectly.<br>But it fixes a few serious bugs that failed to report errors to the<br>
invoking process, and it is definitely better than the original<br>version.<br><br>(I tested this script under full /var partition condition, and the<br>modified script printed out error messages at the end while the<br>
original failed to do so.)<br>
<br>I attach such output at the end.<br><br><br>Also, I modified the code to exit with error code when "log_warning" is<br>called (in addition to the case of "log_failure").<br><br>There is another usage of "log_warning" near line 796.<br>
<br>--- quote<br> if cp "$destfile" "$mplib_mem_file" </dev/null; then<br> mktexupd "$fulldestdir" "$mplib_mem_name"<br> else<br> log_warning "cp $destfile $mplib_mem_file failed."<br>
fi<br>--- end quote<br><br>The warning should indeed be produced when the file system is full and "cp"<br>can fail then!<br><br>This really should have shown up on my Debian installation log.<br>But I am not sure if the accumulated warning was printed due to the<br>
possible short-cut exit without calling "byebye" mentioned earlier.<br><br>(This particular use of "log_warning" has been changed to<br>"log_failure" since "log_failure" does not stop execution<br>
right away. Even when "--all" is given, the execution goes up to the<br>last .fmt creation, and only after that the error messages are printed<br>in one chunk after warning messages.)<br><br><br>====<br><br>OK, that's it.<br>
<br>As a user of linux system with not so large partition, I really need<br>to make sure that "log_warning" works, and "fmtutil.sh" as a whole<br>performs to return exit error code at the end with proper setting of<br>
error handlers.<br><br>TIA<br><br><br><br>---<br>PS:<br>Now I notice that, if fmtutil.sh is passed "--no-error-if-no-format",<br>it does not abort when it probably should.<br><br>We can't have proper error failure if this option is used.<br>
<br>Such call with --no-error-if-no-format was introduced<br>in TeXLive 2013 in<br><br>./texlive-20130530-source/texk/texlive/linked_scripts/texlive/<a href="http://tlmgr.pl" target="_blank">tlmgr.pl</a>: $errors += do_cmd_and_check("fmtutil$sysmode --no-error-if-no-format --byengine $e");<br>
<br>./texlive-20130530-source/texk/texlive/tl_scripts/ChangeLog: * fmtutil: add --no-error-if-no-format, don't abort in some cases of<br><br> full quote is:<br><br> 2010-07-04 Norbert Preining <<a href="mailto:preining@logic.at" target="_blank">preining@logic.at</a>><br>
<br> * fmtutil: add --no-error-if-no-format, don't abort in some cases of<br> missing formats<br><br>Oh well :-)<br><br>I may have to figure out if this possible use of<br>"--no-error-if-no-format" was relevant on my PC that runs under Debian<br>
GNU/Linux during installation of texlive-related packages.<br><br><br>PS:<br><br>NOTE: CAVEAT EMPTOR<br><br>Full File system error manifests itself in various manners.<br><br>Almost full file system (/var partition is full)<br>
comes in varieties.<br><br>In some computer installations, /tmp and /var share the same partition.<br>Then creating temporary files during shell execution (such as "here<br>document" of shell script) will fail in addition to the failure to<br>
create .fmt files.<br>Whereas if /tmp is not full and /var is full, then there is a pattern<br>of errors which will not be seen when /tmp and /var are both full.<br>Also, whether /usr and /var share the same partition also change the<br>
error behavior, too.<br><br>In my tested environment, these partitions are all different.<br><br>So your mileage varies if you test the installation of texlive under<br>low-space condition using this script.<br><br>I am sure that there are OTHER commands that fail and may<br>
fail to report that an error occurred.<br><br>But this does not change the fact that the failure to implement the<br>error handling of an "mv" command in if-command syntax was the primary<br>cause of my Debian installer's failure to notice the partial<br>
incomplete installation of texlive package, and failure to generate<br>.fmt files properly.<br><br>Sample OUTPUT form the modified fmtutil.sh<br><br>The excerpt from the log of a hardened fmtutil.sh under almost full<br>
file system condition such that even superuser fails to write to /var<br>
partition in the middle of fmtutil.sh execution.<br>(For this test, I only loaded texlive-base of Debian package.<br>If I load TeX-related more packages, then I would have gotten a dozen<br>or two .fmt creation failures.)<br>
<br>--- quote ----<br>fmtutil: running `luatex -ini -jobname=luatex -progname=luatex luatex.ini' ...<br>This is LuaTeX, Version beta-0.76.0-2013070106 (rev 4627) (INITEX)<br> restricted \write18 enabled.<br><br> [ omission ]<br>
<br>50 preloaded fonts<br>0 words of pdf memory<br>0 indirect objects<br>No pages of output.<br>Transcript written on dviluatex.log.<br>mv: error writing '/var/lib/texmf/web2c/luatex/dviluatex.fmt': No space left on device<br>
mv: failed to extend '/var/lib/texmf/web2c/luatex/dviluatex.fmt': No space left on device<br>Error: 'mv dviluatex.fmt /var/lib/texmf/web2c/luatex/dviluatex.fmt' failed<br>Warning: Removing the possibly partial file /var/lib/texmf/web2c/luatex/dviluatex.fmt left by mv failure ...<br>
<br>###############################################################################<br>fmtutil: Warning! Some warnings have been issued.<br>Visit the log files in directory<br> /var/lib/texmf/web2c<br>for details.<br>###############################################################################<br>
<br>This is a summary of all `warning' messages:<br>Removing the possibly partial file /var/lib/texmf/web2c/luatex/luatex.fmt left by mv failure ...<br>Removing the possibly partial file /var/lib/texmf/web2c/pdftex/etex.fmt left by mv failure ...<br>
Removing the possibly partial file /var/lib/texmf/web2c/pdftex/pdftex.fmt left by mv failure ...<br>Removing the possibly partial file /var/lib/texmf/web2c/pdftex/pdfetex.fmt left by mv failure ...<br>Removing the possibly partial file /var/lib/texmf/web2c/tex/tex.fmt left by mv failure ...<br>
Removing the possibly partial file /var/lib/texmf/web2c/luatex/dviluatex.fmt left by mv failure ...<br><br>###############################################################################<br>fmtutil: Error! Not all formats have been built successfully.<br>
Visit the log files in directory<br> /var/lib/texmf/web2c<br>for details.<br>###############################################################################<br><br>This is a summary of all `failed' messages:<br>'mv luatex.fmt /var/lib/texmf/web2c/luatex/luatex.fmt' failed<br>
'mv etex.fmt /var/lib/texmf/web2c/pdftex/etex.fmt' failed<br>'mv pdftex.fmt /var/lib/texmf/web2c/pdftex/pdftex.fmt' failed<br>'mv pdfetex.fmt /var/lib/texmf/web2c/pdftex/pdfetex.fmt' failed<br>'mv tex.fmt /var/lib/texmf/web2c/tex/tex.fmt' failed<br>
'mv dviluatex.fmt /var/lib/texmf/web2c/luatex/dviluatex.fmt' failed<br>byebye called<br>We had error(s).<br><br>--- end quote ---<br><br>[end of memo]<br><br></div></div>