Re: 100% [Waiting for headers]
On Sunday, June 24, 2012 05:52:16, lina wrote: > On Sun, Jun 24, 2012 at 5:45 PM, Curt wrote: > > On 2012-06-24, lina wrote: > >> Dselect reported me that my /var has saturated. Indeed, 100%. > >> > >> My question is that how to set to let me know earlier when the var > >> reached 98%. Kinda of dangerous huh? > > > > My question would be why is /var being "saturated" in the first place. > > Ha ... I didn't realize I should have used aptitude autoclean before. > Lots of .deb ball there. > > Dom guessed exactly right on another thread. For those running Debian Stable boxes /var/cache/apt/archives/ only slowly grows because upgrades are rare, so it generally takes several years for /var to fill up, and this issue generally goes unnoticed. However for those who run Debian Unstable, /var ends up filling up much, much faster because instead of upgrades happening every two years, they happen every single day, so /var tends to fill up in about ONE year. (Or at least that's what my experience was.) Because of this I got into the habit of running 'apt-get clean' after all package installs and upgrades, and there turns out to be a downside to doing that. It's convenient to be able to downgrade a newly broken package to a previous version that's in the package cache. In aptitude this can be done by highlighting a package and then pressing the 'v' key to show available verisons of the package -- you can then press '+' on the previous version (if there's a previous version still in the cache) and downgrade the package. These options are only available if 'apt-get clean' has NOT been run, though -- otherwise only the latest installed version is available. So as a result it's best to run 'apt-get clean' occasionally rather than constantly. :-P On Debian Stable where packages generally don't break it's probably safe -- yet ironically it's on Debian Unstable where packages occasionally do break is where one would want to clean out the package cache most often. -- Chris -- Chris Knadle chris.kna...@coredump.us -- 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/201206240643.55530.chris.kna...@coredump.us
Re: 100% [Waiting for headers]
On Sunday, June 24, 2012 01:28:28, lina wrote:
> On Sun, Jun 24, 2012 at 12:49 PM, Chris Knadle
> wrote:
> > On Saturday, June 23, 2012 23:49:54, lina wrote:
> >> Kinda of funny,
> >>
> >> Dselect reported me that my /var has saturated. Indeed, 100%.
> >>
> >> My question is that how to set to let me know earlier when the var
> >> reached 98%. Kinda of dangerous huh?
> >
> > This is a common problem. If this is a box you're running KDE on I'd
> > suggest the freespacenotifier package. If this is a server (or doesn't
> > run KDE) then
>
> It runs with xfce4.
>
> > I'd suggest configuring the box such that you'll get email output from
> > cron, and then make a cronjob that outputs text only when the free space
> > left on filesystems reaches the desired "warning" threshold.
>
> I started to initiate a script,
>
> $ while [ df -h | grep "/dev/sda11 " | awk '{print $5}' > 90% ]; do
> sleep 1000 ; done mail l...@email.com
> bash: [: missing `]'
> bash: 90%: No such file or directory
>
> not work.
>
> Can someone recommend some build-in script which integrate the cron,
> so I can take it as template and learn from it. I don't know which one
> is the best fit, which also autorun everytime after reboot.
This evening I came up with the following quick script, "freespacewarn",
which I placed in my home directory under ~/bin :
#!/bin/bash
df -h | fgrep -v -e Filesystem | while read FS SIZE USED AVAIL PCNT_USE
MOUNTEDAT JUNK
do
export PCNT_USE
PCNT=$(echo $PCNT_USE | tr -d '%')
if [ $PCNT -gt 90 ]; then
echo "Warning: filesystem at $MOUNTEDAT nearly full."
echo " Filesystem $FS, Size $SIZE, $USED used, $AVAIL avail, $PCNT_USE
used, mounted at $MOUNTEDAT"
fi
done
Then I made a user crontab entry via 'crontab -e' to run this once a day
at 7am:
0 7 * * * /home/cknadle/bin/freespacewarn
-- Chris
--
Chris Knadle
chris.kna...@coredump.us
--
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/201206240237.18558.chris.kna...@coredump.us
Re: OT: /var on another distro, was: Re: 100% [Waiting for headers]
On Sunday, June 24, 2012 01:39:06, Ralf Mardorf wrote: > Hi Chris, > > I usually have at least one Suse, one Debian, one Ubuntu and one Arch > installed, just to get one Linux, that fit to my most important needs. That sounds like it could occasionally be confusing... but also interesting. I've been meaning to try Arch, simply because it's one of the distros that I haven't yet tried. > Usually that are Debian or Ubuntu and not Suse or Arch. Perhaps I should > replace Suse with Fedora, anyway, it's hard to keep track with all > distros I'm using. Fedora is interesting in that they use SELinux by default, but I don't personally like their plans for mandating reboots for certain updates for Fedora 18. That's "too much like Windows" for my liking. I prefer Debian's restart of services after libc6 upgrades, without requiring a reboot. > AFAIK on Arch only systemd is important today, I didn't switch, OTOH I > often nag regarding to consolekit. Many distributions have switched to using systemd by default -- a few of the holdouts are Ubuntu (which uses upstart), Debian (still using sysv-rc init scripts, but now with dependency-based bootup), and Gentoo which is using OpenRC. -- Chris -- Chris Knadle chris.kna...@coredump.us -- 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/201206240233.16529.chris.kna...@coredump.us
Re: OT: /var on another distro, was: Re: 100% [Waiting for headers]
On Sunday, June 24, 2012 00:39:45, Ralf Mardorf wrote: > OT for Lina's issue, but she mentioned /var. > > I wonder if for Debian there will be some wicked changes too, systemd > seems to be one common change for some distros, IIRC ( ;) ) for Debian > too. There weve several long threads about systemd on [debian-devel] in the past couple of months, and as far as I can tell the standard sysv-rc init scripts with dependency-based bootup is what will be used for the default Wheezy release. However systemd will be an option for those that want it. I've tested systemd -- for the most part it works, but it has some limitations. For one, the option to reboot the computer within KDE won't work with systemd -- when choosing the option it instead acts as if you've logged out, and you have to re-choose to reboot within the kdm login window. For another, the sysv-rc ANSI color script output is a bit prettier (IMHO) than booting up via systemd via command line options "quiet init=/bin/systemd systemd.sysv_console=true systemd.show_status=true". > Will /var soon or later be changed for most distros, inculding Debian? > > "As of filesystem-2012.6-2 the folders /var/run and /var/lock will be > replaced by symlinks to /run and /run/lock, respectively." - > http://www.archlinux.org/ Several distros seem to be experimenting with several FHS layout changes, such as merging /sbin and /usr/sbin, /bin and /usr/bin, etc. Things in /var occasionally get moved around also. For instance years ago mail used to occupy /var/spool/mail rather than today it resides in /var/mail -- and for compatability reasons there's a symlink from /var/spool/mail -> ../mail. The main issue most DDs have with several of the proposed changes I've heard about are if they lack adherence to the FHS, or if the moves somehow violate Debian Policy. -- Chris -- Chris Knadle chris.kna...@coredump.us -- 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/201206240107.41495.chris.kna...@coredump.us
Re: 100% [Waiting for headers]
On Saturday, June 23, 2012 23:49:54, lina wrote: > Kinda of funny, > > Dselect reported me that my /var has saturated. Indeed, 100%. > > My question is that how to set to let me know earlier when the var reached > 98%. Kinda of dangerous huh? This is a common problem. If this is a box you're running KDE on I'd suggest the freespacenotifier package. If this is a server (or doesn't run KDE) then I'd suggest configuring the box such that you'll get email output from cron, and then make a cronjob that outputs text only when the free space left on filesystems reaches the desired "warning" threshold. I'm about to set up the same thing because there's a box I help administer that also regularly runs into this problem. :-/ -- Chris -- Chris Knadle chris.kna...@coredump.us -- 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/201206240049.36230.chris.kna...@coredump.us
Re: laptop battery cycling
On Sunday, May 27, 2012 21:37:49, Robert Holtzman wrote: > For the record, I'm running a Lenovo T420i with a 6 cell battery. > > In the past I've been told that it's bad practice to run a laptop on AC > with the battery installed because it would cause reduced battery > capacity. That's correct most of the time. > This raises two questions. First, is it true that laptop > batteries don't have overcharge protection, and second, how many cycles > is a battery like mine good for? Most laptop batteries today are Lithium-Ion type. Lithium-Ion batteries get damaged when they are at either extreme in terms of charge. At 100% charge the Lithium-Ion mixture can crystalize and the battery looses capacity. At near 0% a Lithium-Ion battery is at risk of exploding, so there is an internal safety circuit to permanently disable the battery if the battery charge is brought too low. The best storage charge level for Lithium-Ion is 40%. The best option for Thinkpads is to install the packages 'tp-smapi-source' and 'tp-smapi-dkms', the latter which willl build the tp-smapi kernel module. [Read the docs that come with tp-smapi-source, which will explain more about Lithium-Ion battery thresholds.] This allows setting the low and high charge thresholds via /etc/sysfs.conf [after the 'sysfsutils' package has been installed] with rules such as: devices/platform/smapi/BAT0/start_charge_thresh = 30 devices/platform/smapi/BAT0/stop_charge_thresh = 91 With rules such as the above, the laptop can be on the charger and the battery plugged in and sitting at 40% and NOT be charging. This means that the laptop can safely be on the charger all the time, and yet not damage the battery. I'd like to think there is a similar utility to do this for non-Thinkpad hardware, but I haven't looked for it much. Final note on battery tech: Nickel-Metal-Hydride (NiMh) and Nickel-Cadmium (NiCad) batteries both exhibit an effect called "memory", so they should always be fully discharged followed by a full charge. So be sure to know the type of battery your laptop is using. -- Chris -- Chris Knadle chris.kna...@coredump.us GPG Key: 4096R/0x1E759A726A9FDD74 signature.asc Description: This is a digitally signed message part.
Re: 2TB USB hard drive for backing up: XFS info
On Sunday, May 06, 2012 05:19:20, Andrei POPESCU wrote: > On Vi, 04 mai 12, 15:08:57, Chris Knadle wrote: ... > > Speed is generally what XFS is good at, *except* when it comes to > > deletion of a large number of files -- that's where it's slow. > > On advise of a list subscriber I have added the 'delaylog' mount option. > This is supposed to help if you have a new enough kernel. It took me a while to find a reference for what this setting does. Having read the paragraph in the link below [it's question #40 when using the contents at the top of the page], it seems there's a speed benefit but also a risk of additional corruption in the case of an unclean shutdown. http://www.xfs.org/index.php/XFS_FAQ#Q:_I_want_to_tune_my_XFS_filesystems_for_.3Csomething.3E As for the kernel -- I'm currently using Linux 3.3.4. [I've been custom compiling my own kernel using make-kpkg from the 'kernel-package' package for a long time now.] > > Also in practice I find that any kernel crash or hard-power-off corrupts > > XFS to at least some extent requiring an xfs_check and xfs_repair, so I > > have to make sure to keep a LiveCD on hand to be able to do this. > > I using xfs only on my laptop, so I have hard power-off only if the > kernel crashes. I just did the xfs_check and xfs_repair now, but they > didn't find any problems. The last time I had a hard-power-off both of the XFS filesystems on my laptop came up clean also, however I did have corruption and had to clean out about a hundred files in /lost+found. [Mostly temp files, but 'debsums -s' also reported files missing from packages, so I needed to reinstall several packages to fix that.] -- Chris -- Chris Knadle chris.kna...@coredump.us GPG Key: 4096R/0x1E759A726A9FDD74 signature.asc Description: This is a digitally signed message part.
Re: 2TB USB hard drive for backing up: XFS info
On Friday, May 04, 2012 17:31:23, Camaleón wrote: > On Fri, 04 May 2012 15:08:57 -0400, Chris Knadle wrote: > > On Monday, April 30, 2012 10:53:46, Camaleón wrote: > >> On Sun, 29 Apr 2012 20:16:58 +0200, Martin Steigerwald wrote: > >> > Am Dienstag, 24. April 2012 schrieb Camaleón: ... > > The steps to actually fsck a XFS filesystem: > >- mount the XFS filesystem to replay the log > >- unmount the XFS filesystem that was just mounted > >- run xfs_check on the filesystem's device > >- if necessary run xfs_repair on the filesystem's device > > You mean you don't even notice a file system inconsistency until it > royally crashes or even something worse? Oh. Yes that's corret -- XFS does /not/ warn you at boot time (nor mount time) if the state of the filesystem is inconsistent. YOU have to know to check that (or find out "the hard way"), and if you use XFS for "/" you somehow need to know to do it from a LiveCD. :-/ [This is rarely explained.] > > Note this means running 'xfs_check' is done when the filesystem is not > > mounted. _Supposedly_ it can also be run if the filesystem is mounted > > read- only, but in practice I find it's best (and easier) to run the XFS > > commands from a LiveCD. The xfs_check and xfs_repair operations are > > incredibly fast -- even for a 500GB filesystem it's usually only takes > > about 10 or 15 seconds. Speed is generally what XFS is good at, *except* > > when it comes to deletion of a large number of files -- that's where > > it's slow. > > So... is that you don't find it suitable for a standard "/" partition? Hmm. Having given that a thought -- yeah I think that would be a good idea and I might be happier using ext4 for "/" and keep using XFS for /home. On my next reinstall of my laptop (whatever year that will be :-P) I might try that and see how I like it. > I mean, if it's better don't analyze an XFS partition when is mounted > read-only, that can be really a no-no for many installations running > 24/365. Yes. And in addition nounting a "/" XFS partition read-only to run xfs_repair on is fairly tricky. Even when booting up into single-user mode it's still necessary to shut down several processes, which last I recall also includes the sshd daemon. :-/ I'm currently using XFS for "/" on a remote server I have no physical access to, and I'm finding this is a problem because I don't have a good way of running xfs_check and xfs_repair on it while the system is running. The hosting company supports remote KVM and bootup to a LiveCD of your choice, and I think this is basically what I'd have to resort to using if I wanted to run xfs_repair on "/" on that box. > > Also in practice I find that any kernel crash or hard-power-off corrupts > > XFS to at least some extent requiring an xfs_check and xfs_repair, so I > > have to make sure to keep a LiveCD on hand to be able to do this. > > I've also heard about terrific stories of data lose after an unexpected > power failure on volumes running on XFS but as I said before, I have no > direct experience with this file system so I can't comment. I've experienced some data loss due to unclean shutdowns, so I can verify that that's possible. I have not yet had any "massive" data loss, thankfully. ... > > The main reason I've been running XFS is for speed -- even on top of > > LUKS I'm finding XFS is able to do sustained 40MB/s transfers over 1Gb > > ethernet, where ext4 on the same box is not able to sustain that. > > However ext4 is more reliable and easier to deal with, because it's able > > to run an fsck at boot time and without neeting a LiveCD to fix it. ;-) > > Not bad numbers. BTW these numbers are with 1Gb ethernet /without/ using jumbo frames -- this is because the unmanaged switch I'm using doesn't support them. > In the event I give XFS a whirl it will be over my "/data" partition, > that's for sure... and fortunately all of my system have UPS units on > behind O:-) All of the systems I'm using XFS on have UPSes on them too -- yet I find systems I run go down hard once in a blue moon, so IMHO a UPS won't completely save you from needing to run xfs_check and xfs_repair occasionally. -- Chris -- Chris Knadle chris.kna...@coredump.us GPG Key: 4096R/0x1E759A726A9FDD74 signature.asc Description: This is a digitally signed message part.
Re: 2TB USB hard drive for backing up: XFS info
On Monday, April 30, 2012 10:53:46, Camaleón wrote: > On Sun, 29 Apr 2012 20:16:58 +0200, Martin Steigerwald wrote: > > Am Dienstag, 24. April 2012 schrieb Camaleón: ... > > XFS might also have long file check times. > > I still have not tried this so I can't really tell but what I've heard on > XFS is not comparable to ext3, I mean, in regards with the time it takes > to perform a filesystem check. On XFS, fsck is literally a no-op -- it does *not* fsck the filesystem. The steps to actually fsck a XFS filesystem: - mount the XFS filesystem to replay the log - unmount the XFS filesystem that was just mounted - run xfs_check on the filesystem's device - if necessary run xfs_repair on the filesystem's device Note this means running 'xfs_check' is done when the filesystem is not mounted. _Supposedly_ it can also be run if the filesystem is mounted read- only, but in practice I find it's best (and easier) to run the XFS commands from a LiveCD. The xfs_check and xfs_repair operations are incredibly fast -- even for a 500GB filesystem it's usually only takes about 10 or 15 seconds. Speed is generally what XFS is good at, *except* when it comes to deletion of a large number of files -- that's where it's slow. Also in practice I find that any kernel crash or hard-power-off corrupts XFS to at least some extent requiring an xfs_check and xfs_repair, so I have to make sure to keep a LiveCD on hand to be able to do this. This gets even more interesting when running XFS on top of LUKS encryption. I'm currently doing that, and I have had to do an xfs_repair operation -- it involves running cryptsetup manually at the command line within a LiveCD and then running xfs_repair on the newly created unencrypted device. [And of course you have to know to look and make sure the LiveCD contains those utilities.] Definitely an interesting experience. The main reason I've been running XFS is for speed -- even on top of LUKS I'm finding XFS is able to do sustained 40MB/s transfers over 1Gb ethernet, where ext4 on the same box is not able to sustain that. However ext4 is more reliable and easier to deal with, because it's able to run an fsck at boot time and without neeting a LiveCD to fix it. ;-) -- Chris -- Chris Knadle chris.kna...@coredump.us GPG Key: 4096R/0x1E759A726A9FDD74 signature.asc Description: This is a digitally signed message part.
Re: Install a package from testing?
On Saturday, April 28, 2012 18:19:58, Nick Meyers wrote: > Good evening all, > > Got a hopefully easy question. > > I currently have a dual boot system with Debian (Squeeze) and windows. The > only reason I've booted into windows for several months now has been to > access MySQL Workbench when I'm not at work. I noticed that MySQL > Workbench is available as a package in Wheezy, so I thought I would look > into the possibility of installing it from there. I've looked through > several of the documents available, but I'm still not clear on how this > could be accomplished without doing an upgrade. I updated sources.list and > did an update, but when I select the package for install I am prompted to > remove several other packages. mysql-workbench has a long list of dependencies: $ apt-cache show mysql-workbench | fgrep Depends Depends: libatk1.0-0 (>= 1.12.4), libatkmm-1.6-1 (>= 2.22.1), libc6 (>= 2.4), libcairo2 (>= 1.7.2), libcairomm-1.0-1 (>= 1.6.4), libctemplate0, libfontconfig1 (>= 2.8.0), libfreetype6 (>= 2.2.1), libgcc1 (>= 1:4.1.1), libgdk-pixbuf2.0-0 (>= 2.22.0), libgl1-mesa-glx | libgl1, libglib2.0-0 (>= 2.16.0), libglibmm-2.4-1c2a (>= 2.30.0), libgnome-keyring0 (>= 2.22.2), libgtk2.0-0 (>= 2.24.0), libgtkmm-2.4-1c2a (>= 1:2.24.0), liblua5.1-0, libmysqlclient16 (>= 5.1.50-1), libpango1.0-0 (>= 1.18.0), libpangomm-1.4-1 (>= 2.27.1), libpcre3 (>= 8.10), libpython2.7 (>= 2.7), libsigc++-2.0-0c2a (>= 2.0.2), libsqlite3-0 (>= 3.5.9), libstdc++6 (>= 4.6), libtinyxml2.6.2, libuuid1 (>= 2.16), libx11-6, libxml2 (>= 2.7.4), libzip2 (>= 0.10), zlib1g (>= 1:1.1.4), python (>= 2.6.6-7~), python2.7, mysql-workbench-data (= 5.2.38+dfsg-3), mysql-client, python-mysql.connector, python-paramiko, python-pysqlite2, python-all, python-pexpect ... and so a lot of the system has to be upgraded to Wheezy in order to satisfy the above dependencies. And there's no current backport for Squeeze for mysql-workbench. > How hard would it be to install just that package from the testing suite, > and if it is not too much trouble, would someone be willing to direct me? It doesn't look straightforward -- there are several conflicts to handle, and the conflicts you're going to have depends on what you have installed on your system that will require updating in order to get this installed. Because this is complicated, I have a suggestion: you could build a Debian Squeeze virtual machine (this could duplicate what you currently have installed, if you want to go that far), and then test the upgrade in the VM -- i.e. in a safe environment. Some virtualization solulutions (like VirtualBox) allow you to do a "snapshot" of the system before making major changes, so you can roll back to the snapshot if it goes wrong and you want to try another upgrade. -- Chris -- Chris Knadle chris.kna...@coredump.us -- 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/201204281856.41993.chris.kna...@coredump.us
Re: Logging question
On Saturday, April 28, 2012 05:49:05, Camaleón wrote: > El 2012-04-27 a las 21:53 -0700, cletusjenkins escribió: ... > > I did find a problem where PCI slot 3 shares a DMA > > with the IDE controller, the NIC was in that slot. It is a 3com 3905B > > which is supposed to be able to share DMAs (and so does the > > controller), but after taking the card out the number of lockups went > > down, but still occur. Occasionally when it locks up I can still move > > the mouse and even type commands into an xterm, but if you do anything > > that hits the harddrive it locks up totally. At least once I was able > > to enter a shutdown command that worked, but usually it locks up before > > that happens. That sounds like an I/O deadlock. > > I replaced the disks and cables, same problem. I moved the OS disk to > > another controller and it still locks up (eventually). I can do a > > fresh installl of debian without any lockups. I even took all the > > drives off the motherboards controllers, disabled the controller in > > the bios and used a disk/cable along with a PCI IDE card that worked > > in a spare machine. Still it eventually locked up. That is interesting. I'm assuming that the PCI IDE card used a different kernel module to support it, which suggest this is likely not an issue related to a particular driver. I have a couple of other suggestions you might consider trying. - Have the RAM that's in the machine tested using a hardware memory tester. [You can try using Memtest+ if you want, but there are certain resevered sections of the RAM that Memtest+ cannot test, which is why I'm suggesting this.] - Try a different kernel version if you can find one, because there's a chance that this is a deadlock issue that's fixed in a new kernel version. The easy way to do this is to find someone that has built a newer generic kernel, the more complicated way is to learn how to do custom kernel compilation directly to a Debian pacakge. - It's possible that this is hardware related in a way that's difficult to test. For instance I've recently learned that electrolytic capacitors slowly loose both capacity and voltage rating over time. -- Chris -- Chris Knadle chris.kna...@coredump.us -- 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/201204281149.41793.chris.kna...@coredump.us
