[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#748271: [latex-cjk-common] latex command did not work until I ran it once under superuser!?



Hi,

Thank you again for your help.


2014-05-18 12:28 GMT+09:00 Norbert Preining <preining@logic.at>:
Hi,

I cannot really grasp at the moment whether there are still problems?

Is everything working for you now?

Once the .fmt file(s) were created under root, it seems that TeX-related commands
work as far as my needs are concerned.
 
> severity: wishlist Re the large size of texlive-lang-cjk: It would be
> nice if we can selectively install C-part, K-part and J-part of CJK of
> texlive-lang-cjk.

Is already done in TeX Live 2014 which is in experimental,, and will
be uploaded to unstable as soon as TL2014 is released.

This is great news.
Two years ago, I used such split packages and thus there were much more room left
in the installation directory (which *may* explain the strange problem I saw.)
 
> tex -kpathsea-debug=-1 -recorder foo.tex 2>foo-debug.log

That looks all fine and works, as you have noticed.

> BTW, the strange problem of ".fmt not found" seems to have been cured by
> running latex once under superuser. (So I am skeptical

So that means
        THere are no problems anymore!

Is this correct?


Yes, as far as my needs for TeX commands are concerned! But I have no idea why it got fixed, and how in the first place it was introduced :-(
 
Or do you still have a format where the problem occurs?

Not that I noticed.
 

> Are ".fmt" files created into system installation directory?  But, if

At installation time and when run as root with fmtutil-sys, they
are copied into
        /var/lib/texmf/web2c/

If user runs it (which *should*not*be*necessary*) the are copied into
        ~/.texmf-var/

In both cases, if the disk space is exhausted, this will not
succeed.

Hmm... I am not sure if this error was noticed during installation.
Such an error should stop the installation by signalling an error to dpkg/apt-get/aptitude, etc.
 
Here is the emacs dir-mode buffer:
Aside from the tex directory that contains tex.fmt, most of the directories under question was
updated on 00:39 of 15th May. Gee I wish I could corelate this time to what package I installed at the time. (Is there a time stamp in dpkg log or something?)

  /var/lib/texmf/web2c:
  合計 104
  drwxr-xr-x 11 root root  4096  5月 16 01:11 .
  drwxr-xr-x  8 root root  4096  5月 16 01:11 ..
  drwxr-xr-x  2 root root  4096  5月 15 00:39 eptex
  drwxr-xr-x  2 root root  4096  5月 15 00:39 euptex
  -rw-r--r--  1 root root  5843  5月 16 01:11 fmtutil.cnf
  drwxr-xr-x  2 root root  4096  5月 15 00:39 luatex
  drwxr-xr-x  2 root root  4096  5月 13 21:34 metafont
  drwxr-xr-x  2 root root  4096  5月 15 00:39 pdftex
  drwxr-xr-x  2 root root  4096  5月 15 00:39 ptex
  drwxr-xr-x  2 root root  4096  5月 13 21:34 tex
  -rw-r--r--  1 root root 51885  5月 15 00:40 updmap.log
  drwxr-xr-x  2 root root  4096  5月 15 00:39 uptex
  drwxr-xr-x  2 root root  4096  5月 15 00:40 xetex

Note that pdftex  contains .fmt files that were produced earlier.

  /var/lib/texmf/web2c/pdftex:
  合計 10284
  drwxr-xr-x  2 root root    4096  5月 15 00:39 .
  drwxr-xr-x 11 root root    4096  5月 16 01:11 ..
  -rw-r--r--  1 root root  517834  5月 14 23:39 amstex.fmt
  -rw-r--r--  1 root root    3315  5月 14 23:39 amstex.log
  -rw-r--r--  1 root root  655333  5月 15 00:39 etex.fmt
  -rw-r--r--  1 root root    6606  5月 15 00:39 etex.log
  -rw-r--r--  1 root root 2767744  5月 15 00:39 jadetex.fmt
  -rw-r--r--  1 root root   33784  5月 15 00:39 jadetex.log
  -rw-r--r--  1 root root  990888  5月 15 00:39 latex.fmt
  -rw-r--r--  1 root root   13506  5月 15 00:39 latex.log
  -rw-r--r--  1 root root  335365  5月 13 21:34 mptopdf.fmt
  -rw-r--r--  1 root root    3910  5月 13 21:34 mptopdf.log
  -rw-r--r--  1 root root  656023  5月 15 00:39 pdfetex.fmt
  -rw-r--r--  1 root root    6987  5月 15 00:39 pdfetex.log
  -rw-r--r--  1 root root 2776336  5月 15 00:39 pdfjadetex.fmt
  -rw-r--r--  1 root root   33872  5月 15 00:39 pdfjadetex.log
  -rw-r--r--  1 root root  990950  5月 15 00:39 pdflatex.fmt
  -rw-r--r--  1 root root   13694  5月 15 00:39 pdflatex.log
  -rw-r--r--  1 root root  656020  5月 15 00:39 pdftex.fmt
  -rw-r--r--  1 root root    6985  5月 15 00:39 pdftex.log

tex.fmt was installed still earlier.

   /var/lib/texmf/web2c/tex:
  合計 312
  drwxr-xr-x  2 root root   4096  5月 13 21:34 .
  drwxr-xr-x 11 root root   4096  5月 16 01:11 ..
  -rw-r--r--  1 root root 303458  5月 13 21:34 tex.fmt
  -rw-r--r--  1 root root   2485  5月 13 21:34 tex.log

This state of affairs is due to the manner I installed various tex-related packages in a piece-meal manner instead of installing texlive-base or texlive-lang-cjk in one full swoop.

> so, this is done when a user issues a TeX-related command by running
> setuid binary, correct?

No setuid package here.

> Anyway, if a file space issue happened during installation, it was
> not obvious to me.

I still think that this is the only explanation.

OK, if so, the error was not propagated to the top-level apt-get/aptitude in an explicit manner.


> *BUT*, usually, when file system space issue arises during package
> installation, apt-get or aptitude clearly fails and so I can take

The fmtutil run creates dump files that are several MB, my
/var/lib/texmf/web2c weights 93M. That means, if there are
not 93M free, it will fail in fmtutils-sys, then free the space,
and return to apt.


I see. It sounds then fmtutil-sys may have an error path that doesn't return error code properly under low-space conditions.
 
> If a run-time generated file could not be created due to space issues,
> then it ought to be reported clearly. Maybe an fmt-generation program
> or something did not report the error during (f)write or (f)close

That can be. But it should error out in this case. The fmtutil
script is running with
        set -e
so failure to do the copy should be obvious.

Ah, one more idea: What is the output of
        dpkg -l tex-common


 dpkg -l tex-common
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name               Version        Architecture   Description
+++-==================-==============-==============-==========================================
ii  tex-common         4.04           all            common infrastructure for building and ins

Again, it loos dandy. This is one of those bug reports where one really needs to scratch one's head where the problem lies or lied.
 
> Also, I doubt the space issue because of another reason.  As I wrote
> this message, I re-ran my XML->TeX->PDF conversion script using the
> latest texlive-lang-cjk (and many other packages, dblatex xetex, etc.)
> and it successfully ran to create a PDF under an ordinary user
> account.  So I doubt if the space issue is the cause of strange
> behavior, but who knows :-(

Maybe you have cleaned up space in the meantime?


No, I did not.
 
Think about what happens when you *install* a package:
* download a copy
* unpack
* check overwrites
* move the files to the right place
THat means intermediately 2-3 times the size is necessary.

yeah, right.
 
After that, space is freed up. And if you clean your apt cache
(apt-get clean) then lots of space is freed up.

> I have been trying to see what went wrong myself even before the bug
> post, but could not come up with a possible candidate and explanation of
> self-healing (after running latex under superuser account) myself.

But this is the only explanation I see ...


OK, this seems to be the only plausible explanation, and if so,
there must be an error path that misses the clear and unmistakable display of error status
and stop apt-get/aptitude right there (!).
 
> I still think that running latex under superuser may have
> changed/fixed permannently something (broken symlink/permission

No.

> bit/??? or as you suggest create a fmt file in a file system where it
> could not be made by an ordinary user due to some reason (possibly a
> temporary space issue?)).

Yes. That is the problem. But that should have happened at
installation time.

Why that was not caught is indeed a mystery to me.
 

Again, what is the status of tex-common? (dpkg -l tex-common)


Attached above and it looks dandy :-(
 
> I am wits' end. Is it possible that there could have been an issue
> using the package(s) from TESTING repository?

I am not sure, but that should be fine...

> Finally, would you like me to run the seemingly destructive command?

It is not necessary anymore, right? Everything works? Or what does
not work?>

As far as my needs for tex commands, the system is fine (it healed mysteriously when latex was run under root, maybe some missing .fmt files were created at that instant under root and
copied into the installation directory.)
 
If "ptex" does not work, please run the above command (with debug and
recorder) with ptex, too!

ptex now works, too (!).

> Hmm., to see that you suggest that I run this as root, then I suppose
> these format ought to have been created during installation under
> super-user for system-wide sharing.  That means there is a possibility
> that they failed for some mysterious reason [and was not reported back
> to the installer and the user clearly???]

Yes, that is why I ask for the output of
        dpkg -l tex-common
which is responsible for building the formats.


Thank you again for all your help and brain-storming.

 
Norbert

------------------------------------------------------------------------
PREINING, Norbert                               http://www.preining.info
JAIST, Japan                                 TeX Live & Debian Developer
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0  ACF0 6CAC A448 860C DC13
------------------------------------------------------------------------


Reply to: