RE: apt cache full, mandb update failed
Hi Brian, >> This morning I wanted to do an apt-get update / upgrade cycle on my >> system. The update went ok, but during the upgrade I got a " No space >> left on device" warning. >> [...] >> Preparing to replace ssh 1:6.0p1-4+deb7u3 (using >> .../ssh_1%3a6.0p1-4+deb7u4_all.deb) ... >> Unpacking replacement ssh ... >> Processing triggers for man-db ... >> /usr/bin/mandb: can't write to /var/cache/man/8774: No space left on >> device Processing triggers for hicolor-icon-theme ... >> Processing triggers for mime-support ... >> [...] >> >> My /var partition had filled up, it seems out of the 3GB there was >> about 2.5GB in /var/cache/apt/archives. The solution was simple, just >> an apt-get autoclean, I now have 2.2GB free on my /var partition. ;-) >> >> But. What wanted apt write to that mandb and was that important? > > Apt calls dpkg and it is during the course of installing with dpkg that the > triggering process occurs. You can see this by doing > > dpkg -i /var/cache/apt/archives//openssh-server_1%3a6.0p1-4+deb7u4_i386.deb Just did that again and it completed normaly. That is what I needed to know, now I know the mandb is up2date as well. Thanks. >> /usr/bin/mandb: can't write to /var/cache/man/8774: No space left on >> device Was that that man page for ssh or something like that? > > Yes. mandb has an interest in what happens in /usr/share/man. Changes there > lead to its updating its database. > For reasons you give it didn't happen, so dpkg issues a *warning*. > Nothing too serious to stop the unpacking and setting up of all the updated > packages. Well a disk full warning is pretty serious. But I get what you mean, a warning from mandb maintenance itself is not serious enough, just the reason why that happened. >> After cleaning up I did another apt-get upgrade but it reported >> nothing to do. > > This is to be expected, surely. All packages are at their newest versions. I had hoped the failed mandb update would register somewhere and a second attempt to "upgrade" would fix it. Turns out I needed that dpkg line to do that. >> So if it failed to update some files why did it >> complete anyhow? > > Would you rather the upgrade came to a halt because of some relatively minor > issue? Yes and no, according to apt-get it was a minor issue of a mandb update, the roor cause was a majot issue. > > apt-get --reinstall install openssh-server > > could be run after space is freed up. I did it by running the dpkg line, same end result I guess. Thank for the explanation and help fixing it. Bonno Bloksma
Re: apt cache full, mandb update failed
On Wed 20 Apr 2016 at 06:52:22 +, Bonno Bloksma wrote: > This morning I wanted to do an apt-get update / upgrade cycle on my > system. The update went ok, but during the upgrade I got a " No space > left on device" warning. > [...] > Preparing to replace ssh 1:6.0p1-4+deb7u3 (using > .../ssh_1%3a6.0p1-4+deb7u4_all.deb) ... > Unpacking replacement ssh ... > Processing triggers for man-db ... > /usr/bin/mandb: can't write to /var/cache/man/8774: No space left on device > Processing triggers for hicolor-icon-theme ... > Processing triggers for mime-support ... > [...] > > My /var partition had filled up, it seems out of the 3GB there was > about 2.5GB in /var/cache/apt/archives. The solution was simple, just > an apt-get autoclean, I now have 2.2GB free on my /var partition. ;-) > > But. What wanted apt write to that mandb and was that important? Apt calls dpkg and it is during the course of installing with dpkg that the triggering process occurs. You can see this by doing dpkg -i /var/cache/apt/archives//openssh-server_1%3a6.0p1-4+deb7u4_i386.deb > /usr/bin/mandb: can't write to /var/cache/man/8774: No space left on device > Was that that man page for ssh or something like that? Yes. mandb has an interest in what happens in /usr/share/man. Changes there lead to its updating its database. For reasons you give it didn't happen, so dpkg issues a *warning*. Nothing too serious to stop the unpacking and setting up of all the updated packages. > After cleaning up I did another apt-get upgrade but it reported > nothing to do. This is to be expected, surely. All packages are at their newest versions. > So if it failed to update some files why did it > complete anyhow? Would you rather the upgrade came to a halt because of some relatively minor issue? apt-get --reinstall install openssh-server could be run after space is freed up.
Re: apt cache full, mandb update failed
* Bonno Bloksma [2016-04-20 06:52 +]: > Hi, > [...] > > My /var partition had filled up, it seems out of the 3GB there was about > 2.5GB in /var/cache/apt/archives. > The solution was simple, just an apt-get autoclean, I now have 2.2GB free on > my /var partition. ;-) > > But. What wanted apt write to that mandb and was that important? > /usr/bin/mandb: can't write to /var/cache/man/8774: No space left on device > Was that that man page for ssh or something like that? > > After cleaning up I did another apt-get upgrade but it reported nothing to do. > So if it failed to update some files why did it complete anyhow? Because /var/cache/man/ resides on the apt-get autocleaned /var partition? Sigh Elimar -- Alles was viel bedacht wird ist bedenklich!;-) Friedrich Nietzsche
Re: apt cache full, mandb update failed
On Wed, Apr 20, 2016 at 06:52:22AM +, Bonno Bloksma wrote: > Hi, > > This morning I wanted to do an apt-get update / upgrade cycle on my system. > The update went ok, but during the upgrade I got a " No space left on device" > warning. > [...] > Preparing to replace ssh 1:6.0p1-4+deb7u3 (using > .../ssh_1%3a6.0p1-4+deb7u4_all.deb) ... > Unpacking replacement ssh ... > Processing triggers for man-db ... > /usr/bin/mandb: can't write to /var/cache/man/8774: No space left on device The good news is that anything in a directory named cache should be a temporary (but long lived) file that can be regenerated if it needs to be. In a tmp directory, on the other hand, you should assume that any file can be deleted arbitrarily. And in a spool directory, you should assume that files need to remain there until their purpose is complete.
apt cache full, mandb update failed
Hi, This morning I wanted to do an apt-get update / upgrade cycle on my system. The update went ok, but during the upgrade I got a " No space left on device" warning. [...] Preparing to replace ssh 1:6.0p1-4+deb7u3 (using .../ssh_1%3a6.0p1-4+deb7u4_all.deb) ... Unpacking replacement ssh ... Processing triggers for man-db ... /usr/bin/mandb: can't write to /var/cache/man/8774: No space left on device Processing triggers for hicolor-icon-theme ... Processing triggers for mime-support ... [...] My /var partition had filled up, it seems out of the 3GB there was about 2.5GB in /var/cache/apt/archives. The solution was simple, just an apt-get autoclean, I now have 2.2GB free on my /var partition. ;-) But. What wanted apt write to that mandb and was that important? /usr/bin/mandb: can't write to /var/cache/man/8774: No space left on device Was that that man page for ssh or something like that? After cleaning up I did another apt-get upgrade but it reported nothing to do. So if it failed to update some files why did it complete anyhow? Bonno Bloksma The complete log in case it is needed: Log started: 2016-04-20 08:18:15 (Reading database ... ^M [.] Reading database ... 100%^M (Reading database ... 43462 files and directories currently installed.) Preparing to replace imagemagick-common 8:6.7.7.10-5+deb7u3 (using .../imagemagick-common_8%3a6.7.7.10-5+deb7u4_all.deb) ... Unpacking replacement imagemagick-common ... Preparing to replace libmagickwand5:i386 8:6.7.7.10-5+deb7u3 (using .../libmagickwand5_8%3a6.7.7.10-5+deb7u4_i386.deb) ... Unpacking replacement libmagickwand5:i386 ... Preparing to replace libmagickcore5-extra:i386 8:6.7.7.10-5+deb7u3 (using .../libmagickcore5-extra_8%3a6.7.7.10-5+deb7u4_i386.deb) ... Unpacking replacement libmagickcore5-extra:i386 ... Preparing to replace libmagickcore5:i386 8:6.7.7.10-5+deb7u3 (using .../libmagickcore5_8%3a6.7.7.10-5+deb7u4_i386.deb) ... Unpacking replacement libmagickcore5:i386 ... Preparing to replace openssh-server 1:6.0p1-4+deb7u3 (using .../openssh-server_1%3a6.0p1-4+deb7u4_i386.deb) ... Unpacking replacement openssh-server ... Preparing to replace openssh-client 1:6.0p1-4+deb7u3 (using .../openssh-client_1%3a6.0p1-4+deb7u4_i386.deb) ... Unpacking replacement openssh-client ... Preparing to replace imagemagick 8:6.7.7.10-5+deb7u3 (using .../imagemagick_8%3a6.7.7.10-5+deb7u4_i386.deb) ... Unpacking replacement imagemagick ... Preparing to replace ssh 1:6.0p1-4+deb7u3 (using .../ssh_1%3a6.0p1-4+deb7u4_all.deb) ... Unpacking replacement ssh ... Processing triggers for man-db ... /usr/bin/mandb: can't write to /var/cache/man/8774: No space left on device Processing triggers for hicolor-icon-theme ... Processing triggers for mime-support ... Setting up imagemagick-common (8:6.7.7.10-5+deb7u4) ... Setting up libmagickcore5:i386 (8:6.7.7.10-5+deb7u4) ... Setting up libmagickwand5:i386 (8:6.7.7.10-5+deb7u4) ... Setting up libmagickcore5-extra:i386 (8:6.7.7.10-5+deb7u4) ... Setting up openssh-client (1:6.0p1-4+deb7u4) ... Setting up openssh-server (1:6.0p1-4+deb7u4) ... [] Restarting OpenBSD Secure Shell server: sshdESC[?25lESC7ESC[1G[ESC[32m ok ESC[39;49mESC8ESC[?12lESC[?25h. Setting up imagemagick (8:6.7.7.10-5+deb7u4) ... Setting up ssh (1:6.0p1-4+deb7u4) ... Log ended: 2016-04-20 08:18:28
Re: mandb: 3 questions
On 2014-01-05, Mike McClain wrote: > Some program, I presume mandb keeps recreating /var/cache/man/cs/ etc. It looks like a bug! https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=23522 Colin Watson says: Version 0.0.20 or greater of the 'localepurge' package now allows the sysadmin to purge manual pages in unwanted languages. The optimal solution is still directory exclusion in dpkg, and there are still bugs filed there, but I think this addresses your needs as far as man-db goes. I'm therefore closing this bug. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/slrnlq8pko.23s.cu...@einstein.electron.org
Re: mandb
On Thu 10 Apr 2014 at 09:22:10 -0700, Mike McClain wrote: > What are the advantages of mandb? >From mandb(8): mandb is used to initialise or manually update index database caches that are usually maintained by man. The caches contain information relevant to the current state of the manual page system and the information stored within them is used by the man-db utilities to enhance their speed and functionality. When creating or updating an index, mandb will warn of bad ROFF .so requests, bogus manual page filenames and manual pages from which the whatis cannot be parsed. Supplying mandb with an optional colon-delimited path will override the internal system manual page hierarchy search path, determined from information found within the man-db configuration file. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/10042014181334.f3dc0f6e1...@desktop.copernicus.demon.co.uk
mandb
What are the advantages of mandb? Thanks, Mike -- "Education is a man's going from cocksure ignorance to thoughtful uncertainty." -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140410162210.GC21529@playground
mandb: 3 questions
Some program, I presume mandb keeps recreating /var/cache/man/cs/ etc. after I delete them. 1) Is there any use to have such extra directories cluttering up the drive on a single user system when the user doesn't read or speak any of those other languages? 2) Is there any configuration I can do to stop these directories being recreated? 3) How many milliseconds does mandb save for the average access? Thanks, Mike -- Today is International Disturbed People's Day Please send an encouraging message to a disturbed friend. ... Just as I've done. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2014010559.GB6078@playground
Re: man/mandb errors
On Tue, Oct 07, 2003 at 09:37:19AM -0700, Paul Mackinney wrote: > At the last update of the man package, I elected to install the new > version of /etc/manpath config. The only customization I'd made was to > add the man pages for my java installation, and I was OK with losing > it. But now every time I run man, I get the following errors: > > mandb: can't chmod /usr/java/j2sdk1.4.1_02/man/index.db: \ > Operation not permitted > mandb: can't remove /usr/java/j2sdk1.4.1_02/man/index.db: \ > Permission denied > mandb: warning: can't update index cache \ > /usr/java/j2sdk1.4.1_02/man/index.db: Permission denied > mandb: No databases created. That's a filed bug which I'll look at soon (I hope, time permitting). > This is sort of understandable because the manpath command still shows > the java man directory > > $ manpath > /usr/java/j2sdk1.4.1_02/man:/usr/local/man:/usr/share/man:/usr/X11R6/man > > But I don't understand why since manpath.config doesn't list it and my > MANPATH variable is not set. A default MANPATH is inferred from your PATH if it isn't explicitly set. > I've run mandb (without errors) and read most of the man-related docs, > but I don't understand what's going on. How can I get manpath to drop > the java man directory? As a workaround until the bug is fixed, you could set an explicit MANPATH not including /usr/java/j2sdk1.4.1_02/man. Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
man/mandb errors
At the last update of the man package, I elected to install the new version of /etc/manpath config. The only customization I'd made was to add the man pages for my java installation, and I was OK with losing it. But now every time I run man, I get the following errors: mandb: can't chmod /usr/java/j2sdk1.4.1_02/man/index.db: \ Operation not permitted mandb: can't remove /usr/java/j2sdk1.4.1_02/man/index.db: \ Permission denied mandb: warning: can't update index cache \ /usr/java/j2sdk1.4.1_02/man/index.db: Permission denied mandb: No databases created. This is sort of understandable because the manpath command still shows the java man directory $ manpath /usr/java/j2sdk1.4.1_02/man:/usr/local/man:/usr/share/man:/usr/X11R6/man But I don't understand why since manpath.config doesn't list it and my MANPATH variable is not set. I've run mandb (without errors) and read most of the man-related docs, but I don't understand what's going on. How can I get manpath to drop the java man directory? TIA, PM -- Paul Mackinney [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: man v. info (was Re: mandb gets stuck!)
wow. ever thought of getting into law practice? :-) i think i touched on a very touchy issue here. i'll just go find a simple project for my python. thanks for all the replies guys! _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
Re: man v. info (was Re: mandb gets stuck!)
On Sun, Sep 02, 2001 at 03:13:10PM -0700, Karsten M. Self wrote: > on Sun, Sep 02, 2001 at 01:44:45PM +0200, Cliff Sarginson ([EMAIL PROTECTED]) > wrote: > > On Sun, Sep 02, 2001 at 11:49:11AM +0100, Colin Watson wrote: > > > On Sat, Sep 01, 2001 at 10:31:47PM +0800, Rino Mardo wrote: I agree with every word you say! regards Cliff
Re: man v. info (was Re: mandb gets stuck!)
Brian Nelson wrote: > I also agree. I think what bothers me most about info pages is that > they often read like books. Not suprising, they often *are* books. I have a book on my shelf that has about a 100% correspondence to the gdb info page. Though the gdb info page lacks RPM's autograph.. -- see shy jo
Re: man v. info (was Re: mandb gets stuck!)
On Sun, Sep 02, 2001 at 11:54:09PM -0400, Brian Nelson wrote: > I also agree. I think what bothers me most about info pages is that > they often read like books. They're usually arranged in a format > resembling chapters covering each topic in thorough detail. This is > fine if I want to read a book about Emacs, for example, but sucks if I > just want a quick reference for a command line switch or something. I don't know ... I find the CVS and grub info pages to be infinitely more informative (groan) than the manpages. OTOH it's only been the past two or three years that I've been able to navigate in an info browser, and I've been using linux for some time now :) -- Nathan Norman - Staff Engineer | A good plan today is better Micromuse Ltd. | than a perfect plan tomorrow. mailto:[EMAIL PROTECTED] | -- Patton pgpCam1uO3eKB.pgp Description: PGP signature
Re: man v. info (was Re: mandb gets stuck!)
"Karsten M. Self" writes: > The problem is that this is often specifically what is *not* sought by > those who are looking for manpages. What's wanted is a short, concise, > but illustrative reference providing: > > - A functional description of the command. > > - A synopsis of all options and/or switches for the command. > > - EXAMPLES!!! Examples of (typical) usage are essential. > > - Additional sections: FILES, SEE ALSO, BUGS, and AUTHOR, typically. > > There is a utility to convert the man page equivalent portion of a > typical info page to something resembling manpage format. > > Personally, I'd strongly recommend that the GNU project revisit the > issue of info pages altogether. They're not popular, they don't > adequately replace man pages, and there is a far more successful and > ubiquitous hypertext model (HTML) in use now. Moreover, the standard > info navigation keybindings (and even the simplified bindings offered by > tools such as pinfo) are neither ubiquitous, corrospondent to other SW > tools (emacs excepted), nor self evident. I also agree. I think what bothers me most about info pages is that they often read like books. They're usually arranged in a format resembling chapters covering each topic in thorough detail. This is fine if I want to read a book about Emacs, for example, but sucks if I just want a quick reference for a command line switch or something. It seems to me that GNU has nothing to lose and plenty to gain by maintaining man pages. Of course man pages can't replace a true documentation system like info, but a good man page is extremely useful. Nice post Karsten. -- Brian Nelson <[EMAIL PROTECTED]>
Re: man v. info (was Re: mandb gets stuck!)
On Sun, Sep 02, 2001 at 03:13:10PM -0700, Karsten M. Self wrote: > Personally, I'd strongly recommend that the GNU project revisit the > issue of info pages altogether. They're not popular, they don't > adequately replace man pages, and there is a far more successful and > ubiquitous hypertext model (HTML) in use now. Moreover, the standard > info navigation keybindings (and even the simplified bindings offered by > tools such as pinfo) are neither ubiquitous, corrospondent to other SW > tools (emacs excepted), nor self evident. Yep. Too many formats -- ~\^o^/~~~ ~\^.^/~~~ ~\^*^/~~~ ~\^_^/~~~ ~\^+^/~~~ ~\^:^/~~~ ~\^v^/~~~ + Osamu Aoki <[EMAIL PROTECTED]>, GnuPG-key: 1024D/D5DE453D + + My debian quick-reference, http://www.aokiconsulting.com/quick/+
man v. info (was Re: mandb gets stuck!)
on Sun, Sep 02, 2001 at 01:44:45PM +0200, Cliff Sarginson ([EMAIL PROTECTED]) wrote: > On Sun, Sep 02, 2001 at 11:49:11AM +0100, Colin Watson wrote: > > On Sat, Sep 01, 2001 at 10:31:47PM +0800, Rino Mardo wrote: > > > getting a little OT here but can all the man databases be converted to > > > info files? what can a "python" newbie do or have to follow in order > > > to do this? > > > > You might be able to do it, but then I'd have to kill you ;) > > > > Besides, the info client can read man pages already. Anything beyond > > that can't be done automatically, as the style of info documents is > > different to man pages (man pages go for simplicity and quick reference, > > info documents are vast sprawling hypertext things). > GNU is of course wonderful (seriously) > But what insanity drove them to try and abandon man pages ? It > remains the most eccentric of decisions. Info pages are great if you > want to know all about something when you know little, but man pages > are better when you need that quick reminder and do not want to tread > through treacle first... I asked Bradley Kuhn about this yesterday (didn't feel like broaching the topic with RMS). It's also a topic that's been raised a few times elsewhere. First, Debian Policy states that packages should have manpages. So there's a frontline response to the GNU position. Bradley cited a number advantages of the Info format, largely: it's a more complete, comprehensive, documentation source, and it's browseable in a hypertext format. The problem is that this is often specifically what is *not* sought by those who are looking for manpages. What's wanted is a short, concise, but illustrative reference providing: - A functional description of the command. - A synopsis of all options and/or switches for the command. - EXAMPLES!!! Examples of (typical) usage are essential. - Additional sections: FILES, SEE ALSO, BUGS, and AUTHOR, typically. There is a utility to convert the man page equivalent portion of a typical info page to something resembling manpage format. Personally, I'd strongly recommend that the GNU project revisit the issue of info pages altogether. They're not popular, they don't adequately replace man pages, and there is a far more successful and ubiquitous hypertext model (HTML) in use now. Moreover, the standard info navigation keybindings (and even the simplified bindings offered by tools such as pinfo) are neither ubiquitous, corrospondent to other SW tools (emacs excepted), nor self evident. There are other projects which have been suggested on a comprehensive documentation front, one of the more interesting (if less motile) being the META project initated by Rich Morin: http://www.cfcl.com/rdm/Meta The FSF needs to revisit this policy, specifically its GNU Coding Standards recommendation that man pages be considered optional: http://www.gnu.org/prep/standards_46.html#SEC46 Man Pages In the GNU project, man pages are secondary. It is not necessary or expected for every GNU program to have a man page, but some of them do. It's your choice whether to include a man page in your program. This I disagree with strongly. When you make this decision, consider that supporting a man page requires continual effort each time the program is changed. The time you spend on the man page is time taken away from more useful work. Specious: applies to any documentation. For a simple program which changes little, updating the man page may be a small job. Then there is little reason not to include a man page, if you have one. For a large program that changes a great deal, updating a man page may be a substantial burden. If a user offers to donate a man page, you may find this gift costly to accept. It may be better to refuse the man page unless the same person agrees to take full responsibility for maintaining it--so that you can wash your hands of it entirely. If this volunteer later ceases to do the job, then don't feel obliged to pick it up yourself; it may be better to withdraw the man page from the distribution until someone else agrees to update it. This argument I consider to be highly problematic. A sufficiently complex program isn't going to be well represented by a manpage, and is going to require ancilary documentation in any event. In this case, an info page is a good fit, but a man page, both covering essential concepts and pointing to additional documentation, is quite helpful. Even relatively complex systems (sed, awk, vi clones, and procmail come to mind) can be relatively well addressed by man pages. When a program changes only a little, you may feel that the discrepancies are small enough that the man page remains useful without updating. If so, put a prominent note near the beginning of the man page explaining that you don't maintain it and that the Texinfo manual is more authoritative. T
Re: mandb gets stuck!
On Sun, Sep 02, 2001 at 11:49:11AM +0100, Colin Watson wrote: > On Sat, Sep 01, 2001 at 10:31:47PM +0800, Rino Mardo wrote: > > getting a little OT here but can all the man databases be converted to > > info files? what can a "python" newbie do or have to follow in order > > to do this? > > You might be able to do it, but then I'd have to kill you ;) > > Besides, the info client can read man pages already. Anything beyond > that can't be done automatically, as the style of info documents is > different to man pages (man pages go for simplicity and quick reference, > info documents are vast sprawling hypertext things). > > -- > Colin Watson [EMAIL PROTECTED] GNU is of course wonderful (seriously) But what insanity drove them to try and abandon man pages ? It remains the most eccentric of decisions. Info pages are great if you want to know all about something when you know little, but man pages are better when you need that quick reminder and do not want to tread through treacle first... My 2 Eurocents worth Cliff
Re: mandb gets stuck!
On Sat, Sep 01, 2001 at 10:31:47PM +0800, Rino Mardo wrote: > getting a little OT here but can all the man databases be converted to > info files? what can a "python" newbie do or have to follow in order > to do this? You might be able to do it, but then I'd have to kill you ;) Besides, the info client can read man pages already. Anything beyond that can't be done automatically, as the style of info documents is different to man pages (man pages go for simplicity and quick reference, info documents are vast sprawling hypertext things). -- Colin Watson [EMAIL PROTECTED]
Re: mandb gets stuck!
getting a little OT here but can all the man databases be converted to info files? what can a "python" newbie do or have to follow in order to do this? it's just a little project of mine to exercise my mind. - Original Message - From: Colin Watson <[EMAIL PROTECTED]> To: Sent: Saturday, September 01, 2001 6:14 PM Subject: Re: mandb gets stuck! > On Fri, Aug 31, 2001 at 11:36:08PM -0700, Karsten M. Self wrote: > > on Fri, Aug 31, 2001 at 04:25:01AM -0500, Colin Watson > > ([EMAIL PROTECTED]) wrote: > > > I'm afraid none of that will work - it turns out it's the database > > > (/var/cache/man/X11R6/index.bt) that's broken, not the man pages. > > > > How did you determine this? > > About two months ago, I wrote the code that is getting into a loop. ;) I > knew it was that because of the various patterns of output he described. > I also don't think it's possible for a broken man page to cause mandb to > loop, although if you manage it I'd love to hear about it ... > > Besides, Eugene sent me the database in question, and I had a look at it > with accessdb. > > -- > Colin Watson (man-db maintainer) [EMAIL PROTECTED] > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
Re: mandb gets stuck!
On Fri, Aug 31, 2001 at 11:36:08PM -0700, Karsten M. Self wrote: > on Fri, Aug 31, 2001 at 04:25:01AM -0500, Colin Watson > ([EMAIL PROTECTED]) wrote: > > I'm afraid none of that will work - it turns out it's the database > > (/var/cache/man/X11R6/index.bt) that's broken, not the man pages. > > How did you determine this? About two months ago, I wrote the code that is getting into a loop. ;) I knew it was that because of the various patterns of output he described. I also don't think it's possible for a broken man page to cause mandb to loop, although if you manage it I'd love to hear about it ... Besides, Eugene sent me the database in question, and I had a look at it with accessdb. -- Colin Watson (man-db maintainer) [EMAIL PROTECTED]
Re: mandb gets stuck!
on Fri, Aug 31, 2001 at 04:25:01AM -0500, Colin Watson ([EMAIL PROTECTED]) wrote: > On Fri, Aug 31, 2001 at 12:37:05AM -0700, Karsten M. Self wrote: > > My suggestion: > > > >- rename /usr/X11R6/man/man3 to /usr/X11/man/man3-bak > > > >- create a directory /usr/X11R6/man/man3 > > > >- create symlinks for half the files in man3-bak: > > > >$ cd /usr/X11R6/man/man3 > >$ for file in $( ls ../man3-bak/* | head -495 ); > >do > > ln -s "$file" "$( basename file )" > >done > > > >- re-run mandb. If you get the problem, remove half the files and > > try again. If you don't get the problem, replace the 'head' above > > with 'tail', and see if it appears. > > > >- If you can't repeat the problem, then we've found something that > > works. > > I'm afraid none of that will work - it turns out it's the database > (/var/cache/man/X11R6/index.bt) that's broken, not the man pages. How did you determine this? -- Karsten M. Self http://kmself.home.netcom.com/ What part of "Gestalt" don't you understand? There is no K5 cabal http://gestalt-system.sourceforge.net/ http://www.kuro5hin.org Free Dmitry! Boycott Adobe! Repeal the DMCA!http://www.freesklyarov.org Geek for Hirehttp://kmself.home.netcom.com/resume.html pgpp8ppiyE6tu.pgp Description: PGP signature
Re: mandb gets stuck!
On Fri, Aug 31, 2001 at 12:37:05AM -0700, Karsten M. Self wrote: > My suggestion: > >- rename /usr/X11R6/man/man3 to /usr/X11/man/man3-bak > >- create a directory /usr/X11R6/man/man3 > >- create symlinks for half the files in man3-bak: > >$ cd /usr/X11R6/man/man3 >$ for file in $( ls ../man3-bak/* | head -495 ); >do > ln -s "$file" "$( basename file )" >done > >- re-run mandb. If you get the problem, remove half the files and > try again. If you don't get the problem, replace the 'head' above > with 'tail', and see if it appears. > >- If you can't repeat the problem, then we've found something that > works. I'm afraid none of that will work - it turns out it's the database (/var/cache/man/X11R6/index.bt) that's broken, not the man pages. Cheers, -- Colin Watson [EMAIL PROTECTED]
Re: mandb gets stuck!
on Thu, Aug 30, 2001 at 07:13:22PM -0400, Eugene Tyurin ([EMAIL PROTECTED])
wrote:
>
> Ok, man-db is version 2.3.19-5
>
> mandb -d -c >>/tmp/mandb.log 2>>/tmp/mandb.log seems to get stuck
> at this point:
>
> free_hashtab: 2090 entries, 1302 (62%) unique
> done.
> catpath: /var/cache/man, manpath: /usr/share/man
> Testing for existence: /usr/share/man/man1/strace.1
> Testing for existence: /usr/share/man/man8/mandb.8
> create_db(/usr/local/man): /var/cache/man/oldlocal/3684
> Testing /usr/local/man for new files
> catpath: /var/cache/man/oldlocal, manpath: /usr/local/man
>
> strace cycles endlessly through these lines:
>
> open("/usr/X11R6/man/man3", O_RDONLY|O_NONBLOCK|0x18000) = 4
> fstat64(0x4, 0xb50c)= 0
> shmat(4, 0xb7b4, 0x2ptrace: umoven: Input/output error
> ) = ?
> ipc_subcall(0x4, 0x805e928, 0x1000, 0) = 4072
> ipc_subcall(0x4, 0x805e928, 0x1000, 0) = 4072
> ipc_subcall(0x4, 0x805e928, 0x1000, 0) = 4088
> ipc_subcall(0x4, 0x805e928, 0x1000, 0) = 4072
> ipc_subcall(0x4, 0x805e928, 0x1000, 0) = 4064
> ipc_subcall(0x4, 0x805e928, 0x1000, 0) = 4080
> ipc_subcall(0x4, 0x805e928, 0x1000, 0) = 4088
> ipc_subcall(0x4, 0x805e928, 0x1000, 0) = 4088
> ipc_subcall(0x4, 0x805e928, 0x1000, 0) = 4080
> ipc_subcall(0x4, 0x805e928, 0x1000, 0) = 4056
> ipc_subcall(0x4, 0x805e928, 0x1000, 0) = 3632
> ipc_subcall(0x4, 0x805e928, 0x1000, 0) = 0
> close(4)
>
> Sometimes, these lines appears:
>
> pread(3, "\0\0\0\0\0\0\0\0008\0\0\0\"\0\0\0,\0\0\0004\0$\7\1\5\354"..., 4096,
> 229376) = 4096
>
> pread(3, "\0\0\0\0\0\0\0\0&\0\0\0,\0\0\0;\0\0\0<\0\324\5\1\5\350"..., 4096,
> 155648) = 4096
>
> /usr/X11R6/man/man3 contains 989 manpages - no symlinks or anything funny.
Any funny-looking files in there -- particularly something with special
characters in it?
I had problems with slocate on a box a few months back, in which I was
referencing sources with apt-cdrom. One of my source files was
clobbering slocate such that my locate database wasn't being created
(major peeve). Had to delete the offending files.
My suggestion:
- rename /usr/X11R6/man/man3 to /usr/X11/man/man3-bak
- create a directory /usr/X11R6/man/man3
- create symlinks for half the files in man3-bak:
$ cd /usr/X11R6/man/man3
$ for file in $( ls ../man3-bak/* | head -495 );
do
ln -s "$file" "$( basename file )"
done
- re-run mandb. If you get the problem, remove half the files and
try again. If you don't get the problem, replace the 'head' above
with 'tail', and see if it appears.
- If you can't repeat the problem, then we've found something that
works.
...and tell us what you find out.
Cheers.
--
Karsten M. Self http://kmself.home.netcom.com/
What part of "Gestalt" don't you understand? There is no K5 cabal
http://gestalt-system.sourceforge.net/ http://www.kuro5hin.org
Free Dmitry! Boycott Adobe! Repeal the DMCA!http://www.freesklyarov.org
Geek for Hirehttp://kmself.home.netcom.com/resume.html
pgp7NfsL402hp.pgp
Description: PGP signature
Bug#110738: mandb gets stuck!
Package: man-db
Version: 2.3.19-5
Severity: important
On Thu, Aug 30, 2001 at 07:13:22PM -0400, Eugene Tyurin wrote on
debian-user:
> Ok, man-db is version 2.3.19-5
>
> mandb -d -c >>/tmp/mandb.log 2>>/tmp/mandb.log seems to get stuck
> at this point:
>
> free_hashtab: 2090 entries, 1302 (62%) unique
> done.
> catpath: /var/cache/man, manpath: /usr/share/man
> Testing for existence: /usr/share/man/man1/strace.1
> Testing for existence: /usr/share/man/man8/mandb.8
> create_db(/usr/local/man): /var/cache/man/oldlocal/3684
> Testing /usr/local/man for new files
> catpath: /var/cache/man/oldlocal, manpath: /usr/local/man
>
> strace cycles endlessly through these lines:
>
> open("/usr/X11R6/man/man3", O_RDONLY|O_NONBLOCK|0x18000) = 4
> fstat64(0x4, 0xb50c)= 0
> shmat(4, 0xb7b4, 0x2ptrace: umoven: Input/output error
> ) = ?
> ipc_subcall(0x4, 0x805e928, 0x1000, 0) = 4072
> ipc_subcall(0x4, 0x805e928, 0x1000, 0) = 4072
That's normal (although it sucks a bit, mandb shouldn't have to keep
re-reading the directory all the time). If it never stops, though, I
suspect what's happened is that you've got a loop in your database. See
bug #95052 - mandb probably needs a similar fix. Also, mandb should not
purge old entries from a database it's just going to delete anyway,
which would have avoided the problem in your case.
Could you send me /var/cache/man/X11R6/index.bt by private mail, please?
I'd be interested to see just how broken it is and try to figure out how
it got that way.
This patch should act as a band-aid for now, if you feel like
recompiling man-db:
--- man-db-2.3.19/src/mandb.c.orig Fri Aug 31 02:23:32 2001
+++ man-db-2.3.19/src/mandb.c Fri Aug 31 02:33:04 2001
@@ -494,7 +494,7 @@
}
force_rescan = 0;
- if (purge) {
+ if (purge && !create) {
database = mkdbname (catpath);
purged += purge_missing (*mp);
}
Thanks,
--
Colin Watson [EMAIL PROTECTED]
Re: mandb gets stuck!
Ok, man-db is version 2.3.19-5
mandb -d -c >>/tmp/mandb.log 2>>/tmp/mandb.log seems to get stuck
at this point:
free_hashtab: 2090 entries, 1302 (62%) unique
done.
catpath: /var/cache/man, manpath: /usr/share/man
Testing for existence: /usr/share/man/man1/strace.1
Testing for existence: /usr/share/man/man8/mandb.8
create_db(/usr/local/man): /var/cache/man/oldlocal/3684
Testing /usr/local/man for new files
catpath: /var/cache/man/oldlocal, manpath: /usr/local/man
strace cycles endlessly through these lines:
open("/usr/X11R6/man/man3", O_RDONLY|O_NONBLOCK|0x18000) = 4
fstat64(0x4, 0xb50c)= 0
shmat(4, 0xb7b4, 0x2ptrace: umoven: Input/output error
) = ?
ipc_subcall(0x4, 0x805e928, 0x1000, 0) = 4072
ipc_subcall(0x4, 0x805e928, 0x1000, 0) = 4072
ipc_subcall(0x4, 0x805e928, 0x1000, 0) = 4088
ipc_subcall(0x4, 0x805e928, 0x1000, 0) = 4072
ipc_subcall(0x4, 0x805e928, 0x1000, 0) = 4064
ipc_subcall(0x4, 0x805e928, 0x1000, 0) = 4080
ipc_subcall(0x4, 0x805e928, 0x1000, 0) = 4088
ipc_subcall(0x4, 0x805e928, 0x1000, 0) = 4088
ipc_subcall(0x4, 0x805e928, 0x1000, 0) = 4080
ipc_subcall(0x4, 0x805e928, 0x1000, 0) = 4056
ipc_subcall(0x4, 0x805e928, 0x1000, 0) = 3632
ipc_subcall(0x4, 0x805e928, 0x1000, 0) = 0
close(4)
Sometimes, these lines appears:
pread(3, "\0\0\0\0\0\0\0\0008\0\0\0\"\0\0\0,\0\0\0004\0$\7\1\5\354"..., 4096,
229376) = 4096
pread(3, "\0\0\0\0\0\0\0\0&\0\0\0,\0\0\0;\0\0\0<\0\324\5\1\5\350"..., 4096,
155648) = 4096
/usr/X11R6/man/man3 contains 989 manpages - no symlinks or anything funny.
I'm confused...
--ET.
_
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
Re: mandb gets stuck!
> On Thu, Aug 30, 2001 at 02:04:13AM -0700, Karsten M. Self wrote: > > on Wed, Aug 29, 2001 at 09:31:40PM -0400, Eugene Tyurin ([EMAIL PROTECTED]) > > wrote: > > > What's /usr/local/man look like? > > My /usr/local/man is empty - does not even have manN subdirs. > > > Have you tried running strace on mandb? > > Running right now... > > --ET. > What is your man-db version? You might try to comment out all the lines in /etc/manpath.config that mention /usr/local/man, although as far as I know this should not make any difference with man-db 2.3.19-5. > > > > > _ > > Do You Yahoo!? > > Get your free @yahoo.com address at http://mail.yahoo.com > > > > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > -- Shaul Karl <[EMAIL PROTECTED]>
Re: mandb gets stuck!
on Thu, Aug 30, 2001 at 08:14:07AM -0400, Eugene Tyurin ([EMAIL PROTECTED]) wrote: > On Thu, Aug 30, 2001 at 02:04:13AM -0700, Karsten M. Self wrote: > > on Wed, Aug 29, 2001 at 09:31:40PM -0400, Eugene Tyurin ([EMAIL PROTECTED]) > > wrote: > > > What's /usr/local/man look like? > > My /usr/local/man is empty - does not even have manN subdirs. I've renamed my /usr/local/man and created a new, empty, directory of the same name. This doesn't appear to replicate your problem. > > Have you tried running strace on mandb? > > Running right now... Don't keep us in suspense. -- Karsten M. Self http://kmself.home.netcom.com/ What part of "Gestalt" don't you understand? There is no K5 cabal http://gestalt-system.sourceforge.net/ http://www.kuro5hin.org Free Dmitry! Boycott Adobe! Repeal the DMCA!http://www.freesklyarov.org Geek for Hirehttp://kmself.home.netcom.com/resume.html pgpaU5CfZQTVW.pgp Description: PGP signature
Re: mandb gets stuck!
On Thu, Aug 30, 2001 at 02:04:13AM -0700, Karsten M. Self wrote: > on Wed, Aug 29, 2001 at 09:31:40PM -0400, Eugene Tyurin ([EMAIL PROTECTED]) > wrote: > What's /usr/local/man look like? My /usr/local/man is empty - does not even have manN subdirs. > Have you tried running strace on mandb? Running right now... --ET. _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
Re: mandb gets stuck!
on Wed, Aug 29, 2001 at 09:31:40PM -0400, Eugene Tyurin ([EMAIL PROTECTED]) wrote: > > Hello, > > A few weeks ago, perhaps, I upgraded something on my woody box - and > now I can't satisfy the mandb gods. Mandb runs through cron.weekly > until I kill it - for a few days. I tried to run it manually to > create a db from scratch, but the same thing - it gets stuck. > > Here's the tail of the log (mandb -d -c): > > free_hashtab: 2088 entries, 1301 (62%) unique > done. > catpath: /var/cache/man, manpath: /usr/share/man > Testing for existence: /usr/share/man/man1/ps.1 > create_db(/usr/local/man): /var/cache/man/oldlocal/20219 > Testing /usr/local/man for new files > catpath: /var/cache/man/oldlocal, manpath: /usr/local/man > > It's been sitting like this for at least 12 hours... Any ideas? What's /usr/local/man look like? Have you tried running strace on mandb? -- Karsten M. Self http://kmself.home.netcom.com/ What part of "Gestalt" don't you understand? There is no K5 cabal http://gestalt-system.sourceforge.net/ http://www.kuro5hin.org Free Dmitry! Boycott Adobe! Repeal the DMCA!http://www.freesklyarov.org Geek for Hirehttp://kmself.home.netcom.com/resume.html pgphrxUMIGhTT.pgp Description: PGP signature
Re: mandb gets stuck!
On Wed, Aug 29, 2001 at 09:31:40PM -0400, Eugene Tyurin wrote: > A few weeks ago, perhaps, I upgraded something on my woody box - and > now I can't satisfy the mandb gods. Mandb runs through cron.weekly > until I kill it - for a few days. I tried to run it manually to > create a db from scratch, but the same thing - it gets stuck. Could you file a bug against man-db? I'd like to see an strace of that mandb process ... there aren't many places it should be able to get stuck. Thanks, -- Colin Watson [EMAIL PROTECTED]
mandb gets stuck!
Hello, A few weeks ago, perhaps, I upgraded something on my woody box - and now I can't satisfy the mandb gods. Mandb runs through cron.weekly until I kill it - for a few days. I tried to run it manually to create a db from scratch, but the same thing - it gets stuck. Here's the tail of the log (mandb -d -c): free_hashtab: 2088 entries, 1301 (62%) unique done. catpath: /var/cache/man, manpath: /usr/share/man Testing for existence: /usr/share/man/man1/ps.1 create_db(/usr/local/man): /var/cache/man/oldlocal/20219 Testing /usr/local/man for new files catpath: /var/cache/man/oldlocal, manpath: /usr/local/man It's been sitting like this for at least 12 hours... Any ideas? --ET. _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
Re: man/mandb problem -- exploit?
On Sat, Aug 11, 2001 at 12:01:40PM -0700, Ronald Hale-Evans wrote: > My system was recently cracked (my impression was that it happened via > the recent Apache exploit). Shortly before I reinstalled my system > (with better security), I lost all ability to view man pages. Typing, > say, 'man man' would bring up a brief message about how it was > reformatting the page, then nothing. > > I reinstalled, then installed an improved firewall before > bringing the system back up on the net and doing 'apt-get update; > apt-get dist-upgrade'. During the dist-upgrade process, I received a > message on the root terminal saying something like 'su session opened > for user man'. That's normal; the installation process did that in earlier versions of man-db (e.g. the one you have in stable). These days it uses start-stop-daemon to avoid the syslog entry. > I didn't know whether this was relevant, but noted it in case it had > something to do with the man-db exploit, for which there was a fix > released on 12 June. So your version of man-db is now 2.3.16-4 (just checking)? > I also ran the following commands, as recommended on the man-db > exploit page: > > suidregister /usr/lib/man-db/man root root 0755 > suidregister /usr/lib/man-db/mandb root root 0755 Those instructions are wrong, as man-db 2.3.16 could not run well without setuid privileges, while the version in testing/unstable can. I think I pointed this out at the time - could somebody on the security team (cc'ed) please either remove that advice in DSA-059-1 or at least note that potato's man-db couldn't gracefully deal with being non-setuid? (See the changelog for 2.3.18-3.) > After the dist-upgrade, I can again no longer view man pages. As an > ordinary user, a simple man command brings up something like the > following: > > Reformatting mpage(1), please wait... > man: can't create /var/cache/man/fsstnd/cat1/393: Permission denied > zsoelim: /tmp/zmanp6L0Cn: No such file or directory > man: can't unlink /var/cache/man/fsstnd/cat1/393: No such file or directory > man: can't remove /tmp/zmanp6L0Cn: No such file or directory I'd expect that after following the above advice. 'suidunregister /usr/lib/man-db/man; suidunregister /usr/lib/man-db/mandb' should fix it. > I purged and reinstalled the packages mandb, manpages, and > manpages-dev, with no luck. I found a file in /tmp named zmanX, > where 'X' was a random string. When I tried to delete or view > this file, I couldn't, because its name would change as I was trying > to do so, to zmanY, where 'Y' was another random string. Probably while you were viewing man pages? Don't worry, those are just temporary files created normally by man. Sometimes they used to get left around due to bugs (maybe still do, I'll squash that bug if I see it). > Any recommendations on getting man working on my system again are > welcome. Be very explicit, however, as I can't use man pages to > clarify any help that is cryptic. Moreover, does it seem that my > man-db has been cracked? Not to me, although I appreciate that that kind of thing is on your mind. If you still have problems after restoring setuid permissions to man-db, feel free to mail me privately. In that case, you can still read man pages with something like 'zcat /usr/share/man/man1/bash.1.gz | man -l -'. As for your problems before you reinstalled - hard to tell, but it could just have been a bug, or maybe whoever cracked your system changed the permissions of some directories. Cheers, -- Colin Watson (Debian man-db maintainer) [EMAIL PROTECTED]
man/mandb problem -- exploit?
Hi-- My system was recently cracked (my impression was that it happened via the recent Apache exploit). Shortly before I reinstalled my system (with better security), I lost all ability to view man pages. Typing, say, 'man man' would bring up a brief message about how it was reformatting the page, then nothing. I reinstalled, then installed an improved firewall before bringing the system back up on the net and doing 'apt-get update; apt-get dist-upgrade'. During the dist-upgrade process, I received a message on the root terminal saying something like 'su session opened for user man'. I didn't know whether this was relevant, but noted it in case it had something to do with the man-db exploit, for which there was a fix released on 12 June. I also ran the following commands, as recommended on the man-db exploit page: suidregister /usr/lib/man-db/man root root 0755 suidregister /usr/lib/man-db/mandb root root 0755 After the dist-upgrade, I can again no longer view man pages. As an ordinary user, a simple man command brings up something like the following: Reformatting mpage(1), please wait... man: can't create /var/cache/man/fsstnd/cat1/393: Permission denied zsoelim: /tmp/zmanp6L0Cn: No such file or directory man: can't unlink /var/cache/man/fsstnd/cat1/393: No such file or directory man: can't remove /tmp/zmanp6L0Cn: No such file or directory After typing 'man man', a file called man.1.gz appears in /var/cache/man/cat1, but all it contains is the following text: --> man.1.gz <-- I purged and reinstalled the packages mandb, manpages, and manpages-dev, with no luck. I found a file in /tmp named zmanX, where 'X' was a random string. When I tried to delete or view this file, I couldn't, because its name would change as I was trying to do so, to zmanY, where 'Y' was another random string. Rebooting seems to have taken care of this; there are presently no files in /tmp, but was this normal behaviour, or part of an exploit? Any recommendations on getting man working on my system again are welcome. Be very explicit, however, as I can't use man pages to clarify any help that is cryptic. Moreover, does it seem that my man-db has been cracked? Thanks... Ron H-E p.s. What's with the Debian list archives? I can neither search nor browse them. -- Ron's Info Closet: Center for Ludic Synergy, Kennexions Glass Bead Game, Positive Revolution FAQ, Hexagram-8 I Ching Mailing List, and links... Ron Hale-Evans ... <http://www.apocalypse.org/~rwhe/> [EMAIL PROTECTED] ... Further up and further in! fnord ... [EMAIL PROTECTED]
Re: mandb-errors!?
>I meant more the Debian version - try 'dpkg -s vim', and look at the >'Version:' line. Oic. [EMAIL PROTECTED]:~$ dpkg -s vim | grep Version Version: 5.6.070-1 Sven
Re: mandb-errors!?
"Sven Burgener" <[EMAIL PROTECTED]> wrote: >Colin Watson wrote: >>(What version of vim are you using?) > >hp:~# vim --version >VIM - Vi IMproved 5.6 (2000 Jan 16, compiled May 1 2000 16:14:28) >Included patches: 1-62, 64-70 I meant more the Debian version - try 'dpkg -s vim', and look at the 'Version:' line. -- Colin Watson [EMAIL PROTECTED]
Re: mandb-errors!?
>At one point, there was a bug that caused vim to disappear from the list >of choices for vi, ex, and so on, and it wasn't fixed properly. I've >mailed the maintainer about it. (What version of vim are you using?) hp:~# vim --version VIM - Vi IMproved 5.6 (2000 Jan 16, compiled May 1 2000 16:14:28) Included patches: 1-62, 64-70 >In the meantime, try 'update-alternatives --config ex', >'update-alternatives --config vi', and 'update-alternatives --config >view', all as root, to see if that solves the problem. If it doesn't, I will have a look at those. Thanks. >then wait for the next version of vim in unstable to appear and upgrade >to that. I dont actually have any problems with vim apart from the fact that mandb reports those errors the first time it is run. Thanks for your support. Sven
Re: mandb-errors!?
"Sven Burgener" <[EMAIL PROTECTED]> wrote: >Colin Watson wrote: >>Are you running vim? vim's alternatives keep breaking. :( I've already > >Yes, I use vim. What do you mean by "vim's alternatives keep breaking"? /usr/share/doc/debian/FAQ/ch-customizing.html, section 10.10, should give you a decent introduction to Debian's alternatives system; vim's man pages are managed that way. At one point, there was a bug that caused vim to disappear from the list of choices for vi, ex, and so on, and it wasn't fixed properly. I've mailed the maintainer about it. (What version of vim are you using?) In the meantime, try 'update-alternatives --config ex', 'update-alternatives --config vi', and 'update-alternatives --config view', all as root, to see if that solves the problem. If it doesn't, then wait for the next version of vim in unstable to appear and upgrade to that. -- Colin Watson [EMAIL PROTECTED]
Re: mandb-errors!?
>Are you running vim? vim's alternatives keep breaking. :( I've already Yes, I use vim. What do you mean by "vim's alternatives keep breaking"? >reported a previous iteration of this bug, I may get round to doing it >again ... When / how will this be fixed? Sven
Re: mandb-errors!?
"Sven Burgener" <[EMAIL PROTECTED]> wrote: >Hello > >Whenever I run "mandb" for the first time (after starting up the >system), I get errors. When I then rerun "mandb" those errors dont >appear. How can I fix them? > > >Updating index cache for path `/usr/share/man'. Wait... >Updating index cache for path `/usr/share/man'. Wait... >Updating index cache for path `/usr/share/man'. Wait...mandb: warning: >/usr/share/man/man1/view.1.gz is a dangling symlink [snip] Are you running vim? vim's alternatives keep breaking. :( I've already reported a previous iteration of this bug, I may get round to doing it again ... -- Colin Watson [EMAIL PROTECTED]
mandb-errors!?
Hello Whenever I run "mandb" for the first time (after starting up the system), I get errors. When I then rerun "mandb" those errors dont appear. How can I fix them? Updating index cache for path `/usr/share/man'. Wait... Updating index cache for path `/usr/share/man'. Wait... Updating index cache for path `/usr/share/man'. Wait...mandb: warning: /usr/share/man/man1/view.1.gz is a dangling symlink mandb: can't open /usr/share/man/man1/view.1: No such file or directory mandb: warning: /usr/share/man/man1/view.1.gz: bad symlink or ROFF `.so' request mandb: warning: /usr/share/man/man1/vi.1.gz is a dangling symlink mandb: can't open /usr/share/man/man1/vi.1: No such file or directory mandb: warning: /usr/share/man/man1/vi.1.gz: bad symlink or ROFF `.so' request mandb: warning: /usr/share/man/man1/ex.1.gz is a dangling symlink mandb: can't open /usr/share/man/man1/ex.1: No such file or directory mandb: warning: /usr/share/man/man1/ex.1.gz: bad symlink or ROFF `.so' request Updating index cache for path `/usr/share/man'. Wait...done. Updating index cache for path `/usr/X11R6/man'. Wait...done. TIA
Re: mandb
[EMAIL PROTECTED] (Account for Debian group mail) wrote: >I tried to update our manual data base using mandb on one of our machines. >I keep getting this error message: > >Processing manual pages under /usr/man... >sh: error in loading shared libraries >: undefined symbol: rl_unbind_function_in_map > >Anyone have an ideas which shared library is having the problem? I believe that's a symbol exported by libreadline. -- Colin Watson [EMAIL PROTECTED]
mandb
I tried to update our manual data base using mandb on one of our machines. I keep getting this error message: Processing manual pages under /usr/man... sh: error in loading shared libraries : undefined symbol: rl_unbind_function_in_map Anyone have an ideas which shared library is having the problem? Thanks, Ken Rea
Re: mandb, man, manpath question
On Thu, 17 Feb 2000, Johann Spies wrote: > On Wed, Feb 16, 2000 at 04:31:53PM -0700, Rick Macdonald wrote: > > On Tue, 15 Feb 2000, Johann Spies wrote: > > > > > After installing a few potato packages the manpages of some of them are > > > not available although they are there. > > > > I hope that you didn't mind my "me too" post the other day. Some people > > get upset. > > Not at all. > > > > > I didn't see any replies. Did you? > > No replies. Maybe nobody knows the answer. I suspect it is the > combination of slink/potato that is causing the problem. > > If I remember correctly you said that you also installed potato's > manpages package? And that did not sort out the problem? > > Anyhow it is not so serious that I will spend a lot of time on it. As > soon as potato comes out officially, I will order my cd's and do a > dist-upgrade. No, I think it's worse than that. >From a pure slink system, I did a dist-upgrade and got the same problem that you have. Sine then, I've been doing a dist-upgrade almost daily to pick up the few packages that are being updated daily. man-db was updated a couple of days ago but the problem is still there. So, I really think that the problem you descibed is indeed a potato bug. ...RickM...
Re: mandb, man, manpath question
On Tue, 15 Feb 2000, Johann Spies wrote: > I am trying to understand how man works. I have a mixed slink/potato > system. It seems to me that potato puts the manpages in /usr/share/man. So > I added /usr/share/man in /etc/manpath.conf and also in ~/.bash_profile > (the latter apparently causes "man" to ignore /etc/manpath.conf). > > After installing a few potato packages the manpages of some of them are > not available although they are there. > jhspies-09:37:56-~$man dviprint > No manual entry for dviprint I have the exact same problem. I just installed the lastest man-db from frozen. man-db ran for a few minutes afterwards, but the problem is still there. I have not fiddled with the conf at all. ...RickM...
mandb, man, manpath question
I am trying to understand how man works. I have a mixed slink/potato system. It seems to me that potato puts the manpages in /usr/share/man. So I added /usr/share/man in /etc/manpath.conf and also in ~/.bash_profile (the latter apparently causes "man" to ignore /etc/manpath.conf). After installing a few potato packages the manpages of some of them are not available although they are there. For example dir /usr/share/man/man1 addr2line.1.gz gcc.1.gz localedef.1.gz ar.1.gz gcov.1.gznlmconv.1.gz as.1.gz getent.1.gz nm.1.gz c++.1.gz glib-config.1.gz nodelist2lbdb.1.gz c++filt.1.gz gprof.1.gz noweb2lyx.1.gz c89.1.gz gtk-config.1.gz objcopy.1.gz cdbdump.1.gz iconv.1.gz objdump.1.gz cdbget.1.gz lbdb-fetchaddr.1.gz ranlib.1.gz cdbmake.1.gz lbdbq.1.gz reLyX.1.gz cdbstats.1.gzld.1.gz readelf.1.gz cdbtest.1.gz ldd.1.gz size.1.gz cpp.1.gz less.1.gzstrings.1.gz dviprint.1.gzlessecho.1.gzstrip.1.gz egcc.1.gzlessfile.1.gztzconfig.1.gz fluid.1.gz lesskey.1.gz tzselect.1.gz g++.1.gz lesspipe.1.gzzdump.1.gz gasp.1.gzlocale.1.gz jhspies-09:37:56-~$man dviprint No manual entry for dviprint $MANPATH set, ignoring /etc/manpath.config :/usr/man:/usr/local/man:/usr/X11R6/man:/usr/share/man I can type man cpp, man fluid and so on and it works. But dviprint and several other just give the message "No manual antry for **". How can I fix that. Regards. Johann -- Johann Spies,Windsorlaan 19, Pietermaritzburg, 3201, South Africa Tel/Faks 033-346-1310 Sel/Cell 082-255-2388 "For by him were all things created, that are in heaven, and that are in earth, visible and invisible, whether they be thrones, or dominions, or principalities, or powers; all things were created by him, and for him." Colossians 1:16
Re: man/apropos/mandb problem...
Roger Franz <[EMAIL PROTECTED]> writes:
> Evidently, fsck
> lost+found'd the index files for apropos/man/mandb, and when I run
>
> mandb -c
>
> to recreate them, it tells me it can't. ("Permission denied" errors,
> files missing, etc.)
I assume you're doing this as root?
Try erasing the files with the problems - use `dpkg -S' to find out
what packages they're from so that you can reinstall the package and
get the file back if necessary. Use `strace -e file' if mandb doesn't
explain very well which files are causing the problems.
If you can't delete the files as root, first try `chattr -i' on them.
If _that_ doesn't work, you may have to resort to black magic:
Backup what you need. Copy debugfs onto a floppy. Boot from the
rescue disk and mount this floppy (and not the hard disk). Run
debugfs on the partition with the problem, then use its `rm' command
on the offending file. Save the changes and reboot, and let fsck
clean up the mess.
--
Carey Evans http://home.clear.net.nz/pages/c.evans/
"The risk of U.S. national security resting in the hands of adults who play
with children's toys during office hours is left as an exercise to the reader."
- Bruce Martin in RISKS
man/apropos/mandb problem...
I finally fixed my sig11 problem (voltage settings on
motherboard).However, I encountered another one. Evidently, fsck
lost+found'd the index files for apropos/man/mandb, and when I run
mandb -c
to recreate them, it tells me it can't. ("Permission denied" errors,
files missing, etc.) Am I missing something? I sort of need those
things so I can figure things out. And, of course, my old hard drive
doesn't help matters. How do I recreate the index files for man,
apropos, etc.? If anybody can point me to a file or a site that
discusses this, that'd be a great help.
Thanks much!
Roger Franz
mandb error messages
When mandb is run, I get the following error messages: Processing manual pages under /usr/man... mandb: warning: /usr/man/man8/mailq.8.gz: whatis parse for mailq(8) failed mandb: warning: /usr/man/man8/sendmail.8.gz: whatis parse for sendmail(8) failed mandb: warning: /usr/man/man8/runq.8.gz: whatis parse for runq(8) failed mandb: warning: /usr/man/man8/rmail.8.gz: whatis parse for rmail(8) failed mandb: warning: /usr/man/man8/rsmtp.8.gz: whatis parse for rsmtp(8) failed mandb: warning: /usr/man/man8/in.smtpd.8.gz: whatis parse for in.smtpd(8) failed mandb: warning: /usr/man/man1/javac.1.gz is a dangling symlink mandb: warning: /usr/man/man1/javac.1.gz: bad symlink or ROFF `.so' request mandb: warning: /usr/man/man1/java.1.gz is a dangling symlink mandb: warning: /usr/man/man1/java.1.gz: bad symlink or ROFF `.so' request mandb: warning: /usr/man/man1/appletviewer.1.gz is a dangling symlink mandb: warning: /usr/man/man1/appletviewer.1.gz: bad symlink or ROFF `.so' request mandb: warning: /usr/man/man1/jre.1.gz is a dangling symlink mandb: warning: /usr/man/man1/jre.1.gz: bad symlink or ROFF `.so' request mandb: warning: /usr/man/man1/sf2text.1.gz: whatis parse for sf2text(1) failed mandb: warning: /usr/man/man1/uupath.1.gz: whatis parse for uupath(1) failed mandb: warning: /usr/man/man1/pland.1.gz: bad symlink or ROFF `.so' request /usr/man/man3/DSA_SetItem.gz: No such file or directory .3w.gz: No such file or directory Can anybody assist me in getting to the root of these? Cheers. -- Colin Telmer, Ottawa, Ontario, Canada <mailto:[EMAIL PROTECTED]> <http://www.telmer.com>
mandb --create hangs
Dear all, Follwoing the recent discussion of problems with man, I decided to try and fix it by doing mandb --create. So - I log in, su, and try and run it - [EMAIL PROTECTED]:~# mandb --create Processing manual pages under /usr/man... mandb: warning: /usr/man/man8/mailq.8.gz: whatis parse for mailq(8) failed mandb: warning: /usr/man/man8/sendmail.8.gz: whatis parse for sendmail(8) failed mandb: warning: /usr/man/man8/runq.8.gz: whatis parse for runq(8) failed mandb: warning: /usr/man/man8/rmail.8.gz: whatis parse for rmail(8) failed mandb: warning: /usr/man/man8/rsmtp.8.gz: whatis parse for rsmtp(8) failed mandb: warning: /usr/man/man8/in.smtpd.8.gz: whatis parse for in.smtpd(8) failed mandb: can't open /usr/man/man1/gnuserv.1: No such file or directory mandb: warning: /usr/man/man1/gnudoit.xemacs20.1.gz: bad symlink or ROFF `.so' r equest mandb: warning: /usr/man/man1/uupath.1.gz: whatis parse for uupath(1) failed mandb: can't open /usr/man/man1/gnuserv.1: No such file or directory mandb: warning: /usr/man/man1/gnuclient.1.gz: bad symlink or ROFF `.so' request mandb: can't open /usr/man/man1/gnuserv.1: No such file or directory mandb: warning: /usr/man/man1/gnuclient.xemacs20.1.gz: bad symlink or ROFF `.so' request mandb: can't open /usr/man/man1/gnuserv.1: No such file or directory mandb: warning: /usr/man/man1/gnuattach.xemacs20.1.gz: bad symlink or ROFF `.so' request mandb: can't open /usr/man/man1/gnuserv.1: No such file or directory mandb: warning: /usr/man/man1/gnuattach.1.gz: bad symlink or ROFF `.so' request mandb: can't open /usr/man/man1/gnuserv.1: No such file or directory mandb: warning: /usr/man/man1/gnudoit.1.gz: bad symlink or ROFF `.so' request mandb: warning: /usr/man/man1/pstogif.xemacs20.1.gz is a dangling symlink mandb: can't open /usr/man/man1/pstogif.1: No such file or directory mandb: warning: /usr/man/man1/pstogif.1.gz: bad symlink or ROFF `.so' request mandb: warning: /usr/man/man1/analog.1.gz: whatis parse for analog(1) failed It then just sits there (and indeed the process seems no longer to be running): 9:23am up 65 days, 12:38, 2 users, load average: 0.11, 0.39, 0.73 52 processes: 50 sleeping, 1 running, 1 zombie, 0 stopped CPU states: 4.0% user, 4.9% system, 0.0% nice, 91.2% idle Mem: 14144K av, 13240K used,904K free, 22732K shrd, 1944K buff Swap: 66524K av, 1984K used, 64540K free 4196K cached PID USER PRI NI SIZE RSS SHARE STAT LIB %CPU %MEM TIME COMMAND 29087 mcv21 15 0 776 776 576 R 0 8.5 5.4 1:05 top 28580 root 1 0 660 660 500 S 0 0.3 4.6 0:06 in.telnetd 1 root 0 0 116 6440 S 0 0.0 0.4 0:20 init The running process being stop, and the zombie being a runq (zombie) which I probably should get round to killing. Should I kill the process, and try again, or what? Thanks, Matthew -- Elen sila lumenn' omentielvo Steward of the Cambridge Tolkien Society Selwyn College Computer Support http://www.geocities.com/Area51/Chamber/8841/ http://www.cam.ac.uk/CambUniv/Societies/tolkien/ http://pick.sel.cam.ac.uk/
