Re: delayed transfer of mail to Pine
On Wed, Feb 06, 2002 at 10:15:38AM -0600, Cheryl Homiak wrote: > I am using fetchmail and pine; lately I am noticing something that didn't > happen before, so I wonder if it has to do with an upgrade of fetchmail. > When I fetch my mail, my primary pop3 usually has at least a couple > hundred messages, and all of them are fetched. But when I get into Pine, > only 100 of those messages are present, plus the smaller numbers of > messages from my other email providers. This wouldn't bother me, except > that it is sometimes fifteen minutes or more before the rest of those > messages finally appear in my Pine inbox. What's going on here? At first, > I thought I was losing mail; it does all eventually get to the inbox, but > why the big delay? If you are using exim as your MTA, edit /etc/exim.conf and change the value of smtp_accept_queue_per_connection to a sane value for your mail volume. The default value is 10. For a smarthost set-up, I believe this is changed to 100, which is way too low if you subscribe to active mail lists like debian-user. What is happening is that exim is queueing everything over 100 messages for later delivery. Either set the value to a very high number that will allow delivery of all mails in one connection, or set it to zero to disable the feature. Hope this helps. Cordially, Mark S. Reglewski
Re: delayed transfer of mail to Pine
On Wed, Feb 06, 2002 at 11:17:22AM -0800, Paul E Condon wrote: > On Wed, Feb 06, 2002 at 10:53:39AM -0600, Mark S. Reglewski wrote: > > > > If you are using exim as your MTA, edit /etc/exim.conf and change the value > > of smtp_accept_queue_per_connection to a sane value for your mail volume. > > The default value is 10. For a smarthost set-up, I believe this is changed > > to 100, which is way too low if you subscribe to active mail lists like > > debian-user. What is happening is that exim is queueing everything over > > 100 messages for later delivery. > > > > Either set the value to a very high number that will allow delivery of all > > mails in one connection, or set it to zero to disable the feature. > > > I'm using fetchmail/exim/mutt (not pine). I looked at my exim.conf just now. > I find that I have > > smtp_accept_queue_per_connection = 100 > > but I have never noticed a delay in lots of mail showing up in mutt. > I think there may be something else involved in Cheryl's problem, but I'm > not sufficiently skilled at this to make an intelligent suggestion. Interesting comment, Paul. First, a disclaimer, then my reply. Disclaimer: I am a complete and clueless Debian and Linux newbie. The only reason that I ventured a reply to Cheryl's original query was that I recently encountered exactly the same problem in setting up mail in Linux. I too run a setup of mutt + fetchmail + exim, and have recently been poring over docs and configuration files. Reply: After getting my mail setup going in Debian, I noticed emails being delivered into my spool file index as I was working my mail in mutt. For a couple of days I naturally thought that these were just messages being pulled off my ISP's server by the fetchmail daemon. But by chance I noticed that some of the deliveries were completely out of sync with fetchmail's polling interval. I checked /var/log/exim/mainlog and discovered that any messages in excess of 100 that were retrieved by fetchmail and passed to exim were being queued for deferred delivery. So more study led me to the /etc/exim.conf file, and the setting of smtp_accept_queue_per_connection. So, it's possible that you have been seeing deferred message deliveries without realizing it. If your smtp_accept_queue_per_connection is set to 100 and messages are *not* being queued, then I think you have a bug against exim. Check your exim logs to see if you are experiencing deferred delivery of messages in excess of 100. If so, you might want to edit your /etc/exim.conf file along the lines I suggested earlier. You could also do this: The next time you boot up, run fetchmail -c -v to see how many messages are on your POP server before you actually invoke fetchmail to retrieve them. Run tail -f /var/log/exim/mainlog in a terminal window while fetchmail is retrieving your messages. You should see messages in excess of 100 being queued in real time. Of course, the acid test for Cheryl will be whether she gets all her messages delivered in one connection the next time she invokes fetchmail with 100+ messages on her mail server. I hope she will report success or failure. If it's failure, then some mail guru will have to chime in, since this clueless newbie is at the outer limits of his knowledge. Cordially, Mark S. Reglewski
Re: delayed transfer of mail to Pine
On Wed, Feb 06, 2002 at 09:07:59PM -0600, Gary Turner wrote: > On Wed, 06 Feb 2002 11:17:22 -0800, Paul E Condon wrote: > >On Wed, Feb 06, 2002 at 10:53:39AM -0600, Mark S. Reglewski wrote: > >> On Wed, Feb 06, 2002 at 10:15:38AM -0600, Cheryl Homiak wrote: > >> > When I fetch my mail, my primary pop3 usually has at least a couple > >> > hundred messages, and all of them are fetched. But when I get into Pine, > >> > only 100 of those messages are present. . . [snip] > > >> If you are using exim as your MTA, edit /etc/exim.conf and change the value > >> of smtp_accept_queue_per_connection to a sane value for your mail volume. > >> The default value is 10. For a smarthost set-up, I believe this is changed > >> to 100, which is way too low if you subscribe to active mail lists like > >> debian-user. What is happening is that exim is queueing everything over > >> 100 messages for later delivery. > >> > >I'm using fetchmail/exim/mutt (not pine). I looked at my exim.conf just now. > >I find that I have > > > >smtp_accept_queue_per_connection = 100 > > > >but I have never noticed a delay in lots of mail showing up in mutt. > >I think there may be something else involved in Cheryl's problem, but I'm > >not sufficiently skilled at this to make an intelligent suggestion. > > > >From Cheryl's description, it looks as if she is getting 1 big mailbag a > day. On my system, with dsl always connected, I fetch the mailbag every > 10 minutes or so and seldom have more than 20 at a time, but a couple of > hundred per day. This may be the same type situation you have, Paul. > True. If Paul has an always-on connection, he'll never run up against the message-per-connection limit, and that would be why he never noticed a problem. As you can see from Cheryl's later post, she *does* have DSL, but she *doesn't* leave her machine on all the time, so she will at least sometimes run into the same limit on messages per connection as I do out here in Dial-Up World. Cordially, Mark S. Reglewski
Re: Procmail and Mutt questions ?
On Tue, Feb 19, 2002 at 06:20:47PM +0100, R.Pac wrote: > how may specify to mutt co keep a copy in ~/Mail/outbox/ directory > each time I send a mail to someone ? Include this in your $HOME/.muttrc: set record=~/Mail/outbox set copy=yes Hope this helps. Cordially, Mark S. Reglewski
Re: (OT) chicago
On Wed, 20 Feb 2002, dman wrote: > The details aren't finished yet, but it looks like I'll be working in > Chicago (Elgin, actually) next quarter. Is anyone here in the Chicago > area? I live about three miles from the Loop. Dman, you may be a fine Unix/Linux hacker, but you need to develop your map-reading skills. Elgin is about forty miles NW of the Loop, and few Chicagoans or Elginians would consider it a suburb of Chicago at that distance. It's at the edge of my road map, next to the legend "Here There Be Dragons". If you don't have a car out here, you won't actually be *in* Chicago very much, though it's an easy drive on I-90 if you do. I hope you make it out here. Street food is cheap and edible. More pizzerias than people. Do they have "Italian beef" sandwiches where you come from? If not, you'll have to try them, they're delicious. Cordially, Mark S. Reglewski
Re: (OT) chicago
On Thu, Feb 21, 2002 at 02:38:21PM -0800, Karsten M. Self wrote: > on Thu, Feb 21, 2002, Mark S. Reglewski ([EMAIL PROTECTED]) wrote: > > On Wed, 20 Feb 2002, dman wrote: > > > > > The details aren't finished yet, but it looks like I'll be working in > > > Chicago (Elgin, actually) next quarter. Is anyone here in the Chicago > > > area? > > [snip] > > Elgin is about forty miles NW of the Loop. . . . > > If you don't have a car out here, you won't actually be *in* > > Chicago very much, though it's an easy drive on I-90 if you do. > > I'd recommend Metra Rail over driving -- far less hassle, no parking > problems, drops you straight into the Loop, and you can hack for an hour > on the way in and out ;-) > > ...just beware the mid-day service blackout -- 11 am - 1pm or so. > Otherwise, coverage is great. Don't know if there is service from Elgin per se, but a co-worker commutes into town via Metra from Crystal Lake, which is just spitting distance from Elgin. Well, easy driving distance. If you were mad enough to try to walk to Crystal Lake from Elgin, you'd show up in the Loop picking corn stalks out of your hair. If you rail into the city, there are many money-losing bus and train routes to get around, but bus and train schedules get sparser and sparser with each passing year as the annual losses erode service. You could use cabs to get around the city, but you might have to speak languages other than English, C, or Python to make yourself understood. And you *may* find out that you have a better idea of where you are going than the cabbie. Also understand that it is next to *impossible* to get a cab pickup in some Chicago neighborhoods (mine is an example). So you might take a cab to a destination and find out that you can't get a pickup to go back where you came from. So a Chicago-newbie should plan any excursions from Elgin carefully. My opinion: the flexibility of having a car makes driving a clear win for the Chicago novice, even with the cost of parking and the hassle of the drive figured in. Cordially, Mark S. Reglewski
Re: (OT) chicago
On Thu, Feb 21, 2002 at 08:25:02PM -0600, Rich Puhek wrote: > > I do love driving the Chicago area freeways though. Watch "Road Warrior" > before you go and you'll be ready for the evening traffic. Nothing like > following someone doing 85 on 355 (speed limit supposedly 55 MPH) and > seeing someone even crazier rocket by on the right while burning > wreckage sits on the right. Just make sure you've got a lot of quarters > (or get Ipass). Heh, heh. You drive the limit? Speed limits on the expressways (never called freeways by the natives) and tollways are *only* recommendations. Except around holiday weekends, the roads are only lightly patrolled by state troopers. And their speeder-catching hideouts are well known to regular travelers. Haven't done 55 in twenty years. Zero tickets in twenty years, without using a radar detector. That should say something about speed enforcement around here. Cordially, Mark S. Reglewski
Re: Help with missing /boot/boot.b
On Thu, Feb 28, 2002 at 09:32:15AM -0400, Liam Black wrote: > Hi, > > I posted a message to this list awhile ago because the hard drive that was > mounted to /boot, and which contained boot.b, had decided to go to the big > drive bay in the sky. I was told that recompiling my kernel might solve the > problem, but didn't get a chance to get around to it until last night. > > I did make menuconfig, make dep, make bzImage, make-kpkg kernel_image, dpkg > -i kernel_image. > > It goes fine until it gets to the Lilo configuration bit. At that point, > whether I'm using my existing lilo.conf or creating a new one, it errors me > out. When I look at the log, it tells me that lilo couldn't find > /boot/boot.b (well, yea) and that I should manually edit my lilo.conf. Is > there a step or a flag or something that I'm missing, here? I didn't catch the earlier post or reply about recompiling the kernel. I had a similar problem recently with a hard drive failure. I run a dual-boot box with Windows on hda and Debian on hdd. I had /boot created at the beginning of the failed disk (hda). When I installed a new drive and recreated /boot at the beginning, I couldn't get lilo to work any more. I was trying to use my Potato installation cd to make the disk bootable again, and the installer bombed out every time. Booting from floppy and running /sbin/lilo as root bombed out with error messages about missing /boot/boot.b. I solved my problem by going root, firing up dselect, and uninstalling lilo, then reinstalling it. During package installation, I was prompted with a couple of questions, and when done, lilo was working again, with a proper /boot/boot.b file in /boot. All I had to do after this was tweak /etc/lilo.conf so I could boot my legacy Windows installation, and I was done. No kernel recompile was necessary. Sorry if this isn't relevant to your situation, as I said, I don't recall your earlier post, or why you were advised to recompile. Good luck. Cordially, Mark S. Reglewski
Re: Help with missing /boot/boot.b
On Fri, Mar 01, 2002 at 03:18:41PM -0400, Liam Black wrote: > > I will try your advice this evening. How did you recreate /boot/boot.b, > though? Was this part of the lilo Process? > > Thank you for your detailed and informative response. Even if it does not > assist me, it will likely assist others! > > leem Liam, you accidentally replied off-list, so I'm posting the reply back to debian-user in case it would be helpful to others in the same boat. *I* didn't recreate /boot/boot.b, it was done auto-magically when I reinstalled lilo. When I replaced my failing hard drive (hda), which had my Windows installation plus my Debian potato /boot partition, I stupidly neglected some sage advice from the lilo manual located in /usr/share/doc/lilo/Manual.txt.gz: Begin quote - If performing a destructive upgrade and/or erasing your Linux partitions, de-install LILO _before_ that if using it as the MBR. End quote -- I inferred from this that if I used dselect to uninstall then reinstall lilo, that I might help myself. It worked. When I reinstalled lilo the install or configuration scripts asked me a couple of questions, nothing esoteric, but I simply don't remember what info I was prompted for. No matter, after I reinstalled lilo, the /boot/boot.b and map files I was missing had been recreated by the package installation, and Debian was bootable from the hard disk again. It's worth a try, and certainly less hassle than recompiling your kernel. Cordially, Mark S. Reglewski
Re: Help!!! undelete for ext3fs!!!
On Fri, Mar 01, 2002 at 06:28:30PM -0600, Cheryl Homiak wrote: > [snip] As > for backups, I'm really sorry but i can't figure out what a MO disk is. I think this is tech speak for a magneto-optical disk, which is a rare beast that I've never actually seen, only heard about. You may google the web for more info about them. > Unfortunately, the only facilities I have right now for doing backup of > any kind is the old floppy, and I probably should have had this data on > floppy. Take it from someone who lived in DOS World for over ten years, floppy backup is about as good as no backup at all. Maybe worse, since you might have a false sense of security. Floppies are hideously unreliable, and just too small to back up present-day large hard disks. The only thing I use floppies for nowadays is to pass small files to friends who don't have Net connections, and for emergency boot disks. And I always make *three* of those at a crack, since I'm as likely to find a corrupted sector on the diskette when I need it as I am to boot a kernel. They like to fail at the most inconvenient times. > I'd love to have a backup system, and you'll get no argument from > me against its importance, but the reality is that I don't have one right > now. CD-Rs work okay for people who don't have large amounts of data to back up, and they are an inexpensive solution. For large amounts of data, tape, preferably SCSI, would seem to be a common recommendation from the old hands on Linux lists. Problem is that a drive that can back up a large disk won't be cheap. Add the cost of a set of tapes to rotate backups, and the cost of a good SCSI board if you don't already have a SCSI channel on your machine, and you're talking a good chunk of change. I use a poor man's remedy: I back up to my second hard drive. This is a "cold swap" IDE drive. I have one disk in the bay to which I back up, and two extra to rotate. One is always off-site at my locker at work, and I tote them back and forth when I go to work to rotate the backups. Since the backups are compressed, and I don't back up anything I can recreate from my Debian installation CDs, I can get away with smaller drives for the backup bay than for the primary disk. The backup disks have either been cannibalized from older systems, or bought for cheap at used computer shops. Not an ideal solution, by any means, but it "works" for some values of "works". At least I can back up everything that needs backing up on a single medium, so unattended backups are possible, and the disk-to-disk transfers are pretty fast. And it was a lot cheaper than DDS. Just $0.02 worth. Cordially, Mark S. Reglewski
Re: suggestion
On Sat, Mar 02, 2002 at 11:52:31AM -0600, will trillich wrote: > short version: > why not have your .signature reflect which debian you're using? > > long version: > > i've noticed that occasionally someone who uses, say, potato, > asks for advice and information, and the answers some from > another debianista using, say, woody. much of the time this is > not a problem, but then there's the occasional situation where > the woody (or sid) system has something that potato (or woody) > doesn't. and neither asker nor responder indicate which systems > they're using. Will, missing relevant data in problem reports and responses is certainly a pain as you indicate, but I think it's better to try to educate novice posters on submitting good, informative reports on a per case basis rather than trying to implement your .signature remedy. Why? 1) You simply won't get enough people to change their .sigs to make this useful. The .sig for a lot of old hands on the Net is an expression of their personalities: you'd have as much luck in trying to persuade them to change their hair styles, manner of dress, or favorite soft drink. 2) There are a lot of people who just mentally filter out the .sig as noise. I've been on the Net since, oh, '97, and within a month I had pretty much stopped looking at .sig blocks. I rarely look at them now unless they are BIG or otherwise eye-catchingly ugly. It would be the last place I would look for information relevant to a problem report. This "ignore-sig-block" habit is so ingrained I doubt that I could train myself to consistently look at list .sigs unless I used Pavlov/high-voltage-electroshock conditioning. I'm deeply sympathetic to novices on the list (I'm one of them!), but not enough to run current through myself to alter a reflex. You've identified a real problem, but I think your fix is unworkable. Cordially, Mark S. Reglewski .sig-less by choice and habit
Re: dpkg - the letter prefixes.. what do they mean
On Sat, Mar 02, 2002 at 08:02:39PM -0500, Joey Hess wrote: > dman wrote: > > Desired=Unknown/Install/Remove/Purge/Hold > > | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed > > |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: > > uppercase=bad) > > ||/ Name VersionDescription > > +++-==-==- > > ii vim6.0.226-1 Vi IMproved - enhanced vi editor > > I wonder if this minor change would make the ascii art vaguely more > understandable: Yes, with emphasis on *vaguely*. See below. > > Desired=Unknown/Install/Remove/Purge/Hold > | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed > |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: > uppercase=bad) > ||/ Name VersionDescription > vvv-==-==- > ii vim6.0.226-1 Vi IMproved - enhanced vi editor > > Here is another version: > > Desired=Unknown/Install/Remove/Purge/Hold > |Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed > ||Prob?=Hold/Reinst-required/X=both-problems (Status,Prob: uppercase=bad) > ||| Name VersionDescription > vvv-==-==- > ii vim6.0.226-1 Vi IMproved - enhanced vi editor > > I prefer this last one. Comments? Disagree. I vote for the first fix. The slight spacing and offset caused by using the slash as opposed to the pipe characters are more likely to draw the viewer's eye to the arrows, and convey to him that all that ascii mess is actually pointing to the status columns. The second version just looks a bit more like hacker gibberish to novice eyes. Take it from a Debian novice who had to scratch his head for quite a while to decode this screen for the first time not so long ago. Note that I don't think the improvement is great. This is likely to be a forbiddingly confusing screen to the novice even with the improvement you have suggested. But any improvement is welcome. The dselect man page says it all (at least in potato it does): Begin quote -- BUGS The dselect package selection interface is confusing or even alarming to a new user. End quote Note also that when the clueless novice *has* finally decoded the screen, it's a piece of cake. "Intuitive" is generally just a synonym for "what is familiar to me". Cordially, Mark S. Reglewski
Re: configuring smtp
On Sun, Mar 03, 2002 at 11:25:50AM -0800, Xucaen wrote: > [snip] I am unable to locate any config > files to setup the new smtp server. Where do I > set up smtp information? and how? I changed > exim.conf but still not able to send e-mail. > What exactly did you do to /etc/exim.conf? The section configuring a smarthost setup in my /etc.exim.conf looks like this: ## # ROUTERS CONFIGURATION # #Specifies how remote addresses are handled # ## # ORDER DOES MATTER # # A remote address is passed to each in turn until it is accepted. # ## # Remote addresses are those with a domain that does not match any item # in the "local_domains" setting above. # Send all mail to a smarthost smarthost: driver = domainlist transport = remote_smtp route_list = "* foo.bar.net bydns_a" end You would replace "foo.bar.net" above with the name of your ISP's mail server. This is for exim 3.12-10 in potato. Also, for outgoing mail to work on a smarthost setup, you'll have to edit the file /etc/email-addresses. It is commented and shows you the syntax to associate your login name on your system with an email address on your smarthost. If you don't do this, your outgoing mail will be broken. If you have done these things, and outgoing mail is still broken, check /var/log/exim/mainlog for interesting messages and post back to the list. Hope this helps. Cordially, Mark S. Reglewski
Re: dpkg - the letter prefixes.. what do they mean
On Sun, Mar 03, 2002 at 10:16:42PM +0100, Matijs van Zuijlen wrote: > How about not using ascii art at all, but just use something along the > lines of: > > Status flag explanations: > 1) Desired=Unknown/Install/Remove/Purge/Hold > 2) Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed > 3) Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: > uppercase=bad) > > 123 Name VersionDescription > ===-==-==- > ii vim6.0.226-1 Vi IMproved - enhanced vi editor > > I think that would *really* clear things up a lot. Maybe the > explanations could even contain some more spaces. Excellent. Easier to read and understand than any of the ascii art versions. dselect will still strike terror into the hearts of newbies everywhere, but this is better. Cordially, Mark S. Reglewski
Re: RFC: Beginner's vim tutorial
On Friday, January 11, 2002 at 11:44 AM dman wrote: > On Thu, Jan 10, 2002 at 10:27:39PM -0600, Donald R. Spoon wrote: > | 2. I have always had problems at the start remembering keyboard > | commands on ANY wordprocessor / editor that I have ever tried. > | VI/VIM has been especially perplexing because I cannot determine > | the under-lying logic used in its design. This means I am > | constantly in the "help" section and reading the docs and never > | get any work done. Eventually I give up and go to something that > | I have already learned and use it. Are you aware of ANY > | documention that will give a historicaly perspective about > | VI/VIM? How did it evolve? Why was this particular set of > | commands chosen? Is there any "logic" (neumonics?) available > | to help remember important commands for the beginner? (Example: > | Wordstar's command keys were layed out in a geometric manner > | on the keyboard. Once I knew this I could usually figure out a > | command sequence and NOT have to refer to the docs/help menus > | nearly as much.) [snip start of dman's mini-tutorial] > x Delete current character (don't know why this key, just > remember it) (same as 'dl') Hahahahaha. You are obviously not old enough to remember the archeological artifact called a typewriter. These mechanical devices were used, before personal computers loaded with word processors and text editors, to create hard-copy printed output such as letters, term papers, and the like. The canonical overstrike character used to wipe out errors in preliminary drafts of typewritten documents was the 'x'. *Very* informal documents might even be distributed to recipients without the x overstriking having been cleaned up. The hackers who coded vi and the ex line editor upon which it is based lived in the Cretaceous period, when dinosaurs walked the earth, and many documents were prepared with typewriters. This is *probably* the origin of 'x' as delete in vi and its clones. Only way to be sure is to ask the coders themselves, of course, but I'd bet a lot on my conjecture's being correct. [snip end of dman's mini-tutorial] Cordially, Mark S. Reglewski
Re: system logs not getting rotated
On Sun, Apr 07, 2002 at 10:50:19AM -0400, Rick Pasotto wrote: > ii logrotate 3.5.9-7Log rotation utility > > For several weeks now my system logs have not been getting rotated. All > logging is going to the .0 files. syslog, daemon.log, auth.log, etc. > remain at zero length and syslog.0, daemon.log.0, auth.log.0, etc keep > growing. If I reboot logging goes to the correct file until the first > rotation. > > Is this a config problem or is there a problem with whichever program > (logrotate?) does the rotating? Doesn't klogd need to be told to close > the old file and open the new one? Where does that happen? > > I find no reference to these files in either logrotate.d or > logrotate.conf nor in the system crontabs. Where is this setup? Rick, logrotate has nothing to do with the files you are interested in, as you see from logrotate.conf. Look at your /etc/cron.daily/sysklogd and /etc/cron.weekly/sysklogd scripts. They use the /usr/bin/savelog utility to rotate system logs. If log rotation is broken on your system, something must be wrong here. You might want to look at man savelog and man syslogd-listfiles. Do you use exim as MTA? Exim log rotation is handled by /etc/cron.daily/exim, also using savelog. Are your exim logs being rotated okay? If so, you'll have a working log rotation script for comparison. Cordially, Mark S. Reglewski -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: exim not sending mail
On Sun, Apr 07, 2002 at 06:29:40PM -0700, Joe Heuring wrote: > I'm not sure what exim is trying to do here. "joe" is my user name on > the computer joeheuring is my email name for cox.net > > my /etc/aliases has always read > > joeheuring: joe Hello Joe, Not an exim expert here by any means, but it's worth checking /etc/email-addresses. There's a bit of magic in the REWRITE CONFIGURATION section of /etc/exim.conf that uses this file. You should have a line that associates your local login name with your real email address at your ISP. In your case it would be something like: joe: [EMAIL PROTECTED] or whatever the correct info is in your case. If this was somehow changed it would break your outgoing mail. Cordially, Mark S. Reglewski -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: system logs not getting rotated
On Mon, Apr 08, 2002 at 12:04:27AM -0400, Rick Pasotto wrote: > Thanks. With your help I have found what the problem *is*. Now I'd like > to know *why* and *how* the problem came to be. Don't thank me too fast. See below. > The cron.daily/sysklogd script passes the argument 'reload-or-restart' > to /etc/init.d/sysklogd *however* that is not one of the options in the > case statement. There are only a 'reload|force-reload' and a 'restart'. > The cron.daily/sysklogd script was getting a usage message which went to > the bit bucket. > > I have never manually edited *any* of these scripts. Any changes have > been done via apt-get. > > Woody needs to be checked to verify that the problem doesn't still > exist. This is very puzzling. I just flipped a potato installation to woody on Saturday, April 6. My cron.daily/sysklogd script has the same line with the 'reload-or-restart' argument, which should be bogus according to Debian Policy, section 10.3.2, which recognizes as legitimate arguments only 'start', 'stop', 'restart' and 'force-reload', or optionally, 'reload'. The line in question *looks* like a piece of pseudo-code that was inserted while the author was debating whether to restart the daemon with a restart or reload argument, but inadvertently left in the final version of the script. But my logs in woody are being rotated properly. Messages are being logged to the current /var/log/syslog file, syslog.0 syslog.1.gz have been properly created. No problem here with any logs in /var/log. If you change the line in the script to: /etc/init.d/sysklogd reload which is what it reads in the potato /etc/cron.daily/sysklogd script, does your logging get fixed? Cordially, Mark S. Reglewski -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: system logs not getting rotated
On Mon, Apr 08, 2002 at 01:19:52AM -0500, Mark S. Reglewski wrote:
> I just flipped a potato installation to woody on Saturday, April 6. My
> cron.daily/sysklogd script has the same line with the 'reload-or-restart'
> argument, which should be bogus according to Debian Policy, section 10.3.2,
> which recognizes as legitimate arguments only 'start', 'stop', 'restart' and
> 'force-reload', or optionally, 'reload'. The line in question *looks* like
> a piece of pseudo-code that was inserted while the author was debating
> whether to restart the daemon with a restart or reload argument, but
> inadvertently left in the final version of the script.
D'oh. Just tested this. In potato, as root:
/etc/init.d/sysklogd reload # works
/etc/init.d/sysklogd restart # works
/etc/init.d/sysklogd reload-or-restart # fails with message:
Usage: /etc/init.d/sysklogd {start|stop|reload|restart|force-reload}
In woody *all three* commands *work*. That's right, the 'reload-or-restart'
argument works. It restarts the logging daemon without error. So Rick,
whatever is b0rking your system logging, it's not that line in
/etc/cron.daily/sysklogd.
Looks like documentation is running a little behind development here.
My chin just hit the keyboard. Time for some sleep.
Cordially,
Mark S. Reglewski
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: system logs not getting rotated
On Mon, Apr 08, 2002 at 08:57:44AM -0400, Rick Pasotto wrote: > Somehow my system has the old init.d/sysklogd script and the new > cron.daily script. > > I just did 'apt-get --reinstall install sysklogd' and the init.d script > did *not* get updated. Is that behavior correct? Do I need to uninstall > and then install sysklogd? That *shouldn't* be necessary at all. dpkg-reconfigure could be your friend here. But it only works for packages using debconf. See the short man page for more details. On my potato installation: # dpkg-reconfigure sysklogd # fails with error message: debconf: package "sysklogd" is not installed or does not use debconf In woody the same command works but does not ask me any configuration questions, properly so because on my woody installation there would be no differences between files on my brand new system and the ones to install. > Is this one of those script changes that produces the 'use maintainers > or keep your old' questions? Possibly. Don't remember from my recent potato to woody flip; there were a lot of packages for which I got these questions and I can't remember which ones, naturally. > If so that could be the cause of my problem as I usually (but > inconsistently) keep the old. That question seldom gives any hint whether > the new script has important changes or even if it's the same as what's > already there. No, Rick, I don't think that's quite correct. The question won't even come up during package configuration unless there's a diff between the old file on your system and the new maintainer's version. When this question comes up, you get a prompt to keep old, use new, or view the diffs. If you chose the last a pager screen comes up with the diffs presented for your examination, and you can decide the importance yourself. This works pretty well for short files with few diffs, but I'll admit that a big file with lots of diffs can be confusing to evaluate in the heat of the moment. And for a newcomer to Linux and Debian such as me, the significance of the changes will often not be readily apparent. Try reconfiguring your package and see whether logging gets fixed. If not, I'm running out of ideas here. Since I'm new to Debian, there weren't a lot of them to begin with. Cordially, Mark S. Reglewski -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
