Re: editor that understands CTRL/B, CTRL/I, CTRL/U
On Fri, 27 Apr 2012 18:36:13 -0600, Chad Perrin wrote: On Fri, Apr 27, 2012 at 06:00:51PM -0400, Jerry wrote: On Fri, 27 Apr 2012 14:33:29 -0700 David Brodbeck articulated: Again, this is one of the reasons credit scoring is becoming so popular -- it's an almost automatic way to narrow down the pile. Another method in common use right now is to throw out applications from anyone who's currently unemployed, and only look at ones who already have a position and are looking to change jobs. I have been told by several people in HR that the trend to give preference to those all ready working as opposed to the unemployed is based on the philosophy that if no one else will hire them, then why should we. While we could argue whether that logic is flawed, it is never-the-less presently in use. However, it doesn't really pertain to entry level openings. With the glut of individuals entering the job market, for an applicant to not be proficient in the skills being advertised for by the prospective employer is just a waste of time. If the employer is looking for skill A and B, crying to him/her that you have skill C is just a waste of both your times. It *does* pertain to entry level positions, because (from what I have seen) most entry level positions come with an experience requirement of at least two years. But then this would invalidate ENTRY level. How exactly is an applicant supposed to get a job from that entry level pool when he doesn't have previous experience because he simply wants to ENTER that field of profession? You speak as though you think they're correctly identifying the skills they actually need from their employees. A big part of this entire discussion has been about the fact that many responsible parties in the hiring process are utterly without capacity for correctly identifying the skills they actually need to optimally fill the open positions. Correct, at least that's my experience. To give you _few_ examples which are more the norm than exceptions: good MS standart knowledge (Yavoll mein Hare Heiny Standart-Leader von Sowercrowd!) programming knowledge in established programming languages, e. g. OS2 (cc hello.os2, and it's OS/2 with slash) modern Microsoft operating systems (Windows 98 and XP) (yes, _very_ modern and current; hey, it's more than 10 years old!) extended basic knowledge (so what, basic or extended?) autonomous team-oriented working (maybe as a one man team!) It's funny when you encounter job offers by recruiters and HR services who _fail_ to properly spell our native language, but think they are in a positition to place _you_ (as a professional) into a good job! Okay, it's NOT funny. It's also not funny if you have to explain to such a senior consultant permanent placement how to open a PDF file containing your application documents, and it's even worse when they try to trick you to do their work, e. g. enter all your data again into their (!) HR database. As I said, the problem of the unclear expression _what_ skills actually are needed can make it hard to properly apply for a job. This problem isn't only present for written application, it's also there if you get invited to an interview and the guy across the table is simply asking the wrong questions, or unable to understand your answers. -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Pfizer Dewormers From Santa Cruz Animal Health
Are you having trouble viewing this e-mail? [1]Click here to view it from our website. To ensure that you continue receiving emails from us, please add [2]santacruzbiotechnol...@scbt.com to your e-mail address book. [3][USEMAP:20120426_pfizer_email.jpg] Copyright © 2012 Santa Cruz Biotechnology, Inc. Santa Cruz Biotechnology, Inc. and the Santa Cruz Biotechnology, Inc. logo are registered trademarks of Santa Cruz Biotechnology, Inc. All content contained in this website is property of Santa Cruz Biotechnology, Inc. and may be used only with the expressed written permission of Santa Cruz Biotechnology, Inc. All rights reserved. Santa Cruz Biotechnology, Inc. is located at 2145 Delaware Avenue, Santa Cruz, CA 95060 USA Email: [4]webmas...@scbt.com If you desire to not receive our e-mail bulletins at freebsd-questions@freebsd.org, simply [5]unsubscribe or forward this email message to webmas...@scbt.com. Santa Cruz Biotechnology, Inc. References 1. http://www.scbt.com/emails/broadcast.php?lang=enpromo=pfizer_20120426url=ah_pfizer.html 2. mailto:santacruzbiotechnol...@scbt.com 3. LYNXIMGMAP:file://localhost/tmp/tmpD_YBq4.html#cow 4. mailto:webmas...@scbt.com 5. http://www.scbt.com/email_bulletin.php?eid=freebsd-questions@freebsd.org ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: UFS Crash and directories now missing
On Sat, Apr 28, 2012 at 1:43 AM, Wojciech Puchar woj...@wojtek.tensor.gdynia.pl wrote: All the jails wound up in the /usr/local/etc/apache22 of the only surviving jail which is the http proxy to all the other jails. Right before the server crashed I noticed MySQL at 100% o several CPUs and the server was on it's knees, so I'm wondering was this an attack? is it possible that Apache or MySQL moved the files?? I mean the jails are there, I'm even backing them up right now but how did these directories move here? Anybody has ANY logical explanation??? 99% - someone did moved them. 1% - hardware problem possibly memory. without this there is no way for directory to be accidentally moved I somewhat agree, but it wasn't a person. I am the only administrator, the only one with root access. The jails were effectively moved to the /usr/local/etc/apache22 of the single that survived at the top level. I'm thinking something between mount, EzJail, the journal and the way MySQL created a great deal of head contention, so something must have gotten corrupted at the directory level like you state, but the strange part is no _data_ corruption as such, because I was able to physically archive the jails, move them to the correct directory and archived them all with ezjail-admin to a different disk. I was thinking of formatting the jails drive, but after all this disk activity and no errors, and everything booted up correctly, I am not so sure now that it's needed it. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: UFS Crash and directories now missing
I somewhat agree, but it wasn't a person. I am the only administrator, the only one with root access. The jails were effectively moved to the /usr/local/etc/apache22 of the single that survived at the top level. I'm thinking something between mount, EzJail, the journal and the way MySQL created a great deal of head contention, so something must have gotten corrupted at the directory level like you state, but the strange part is no _data_ corruption as such, because I was able to physically archive the jails, move them to the correct directory and no matter what you do FreeBSD DOES NOT ramdomly move directories. if you are sure you didn't move it yourself then it must be machine hardware problem but still unlikely. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Synchronising jails
/usr/ports/net/rsync On Fri, 27 Apr 2012, Frank Staals wrote: Hey Everyone, I'm looking for a way to synchronise two jails. More specifically, I would like to keep/maintain an exact copy of a given jail. As an example: Suppose I build a jail A on some system (in my particular case build with ezjail) , and I copy the jail into jail B on some other system (using tar, as is mentioned here: http://forums.freebsd.org/showthread.php?t=17813). Now stuff happens in Jail A, e.g. files change, new stuff is installed etc. I would like to propagate these changes to jail B, but since the transfer is over WAN I would like not to have to copy the entire jail again, just the stuff that has changed since the last backup. It is safe to assume nothing in Jail B changes: I basically want to maintain the exact copy so if something would happen to the system running Jail A I can immediately switch to jail B without much hassle. Normally I would say this a perfect use case for rsync. But as the aforementioned thread mentions ``scp or similar wont work to copy a jail'', and I consider rsync similar to scp, I am under the impression that rsync would not be usable in this situation. Can anyone shed some light on this, or suggest an alternative to synchronise the jails? Regards, -- - Frank ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: FreeBSD vice OS X memory management
does OS X kernel share any code with FreeBSD kernel's memory management subsystem ? IMHO no. OSX is somehow-microkernel based, they did take things from FreeBSD but not this IMHO. anyway - who cares Something is deeply broken in OS X memory management http://workstuff.tumblr.com/post/20464780085/something-is-deeply-broken-in-os-x- memory-management One of the problems that caught my eyes was inactive memory reclamation. I remember some time ago there was a thread here with similar topic. http://lists.freebsd.org/pipermail/freebsd-questions/2012-March/239121.html jb ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: FreeBSD vice OS X memory management
most importantly networking but certainly not memory subsystem. On Wed, 25 Apr 2012, Chuck Swiger wrote: On Apr 25, 2012, at 5:31 AM, jb wrote: does OS X kernel share any code with FreeBSD kernel's memory management subsystem ? The simple answer is no. A more complex answer: % grep -ri freebsd xnu-1699.24.23 | wc -l 520 % grep -ril freebsd xnu-1699.24.23 | sort | uniq ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: FreeBSD vice OS X memory management
2) Inactive memory (which is memory that has been recently used but is no longer) is supposed to be seamlessly reclaimed automatically by the OS when needed for new programs. In practice, I?ve found that this isn?t the case, and my system slows to a crawl and starts paging out to disk when free memory drops to zero, even as half of the available RAM (which is a lot) is marked as inactive. ... Well, this is not a case of a BSD is dying troll (you can safely ignore those). yes it is, just search a bit to know what inactive memory in FreeBSD is. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: FreeBSD vice OS X memory management
If you really are having a problem with FreeBSD you are going to have to do a lot better than this in terms of providing some data points which define the problem. I am in agreement with Adam here: either you can work the problem or you can troll. I don't see any indication yet of any real problem analysis, only a wild mix of stuff non-related to FreeBSD sprinkled with some magic 'memory management' dust. The fact that FreeBSD DOES NOT page excessively on the same workload relative to other OS (linux, netbsd) is one of most important thing i decided to use it. If his system is heavily paging then simply he have too large working set. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: FreeBSD vice OS X memory management
is relatively new. My guess is that if there is a problem it's ZFS specific. If it were a more general problem I think we'd see a lot more complaints, whereas ZFS already has a reputation for needing lots of memory. you may precisely set up a limits of memory that ZFS would use at most. or just don't use it which i do. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: FreeBSD vice OS X memory management
Wojciech Puchar wojtek at wojtek.tensor.gdynia.pl writes: 2) Inactive memory (which is memory that has been recently used but is no longer) is supposed to be seamlessly reclaimed automatically by the OS when needed for new programs. In practice, I?ve found that this isn?t the case, and my system slows to a crawl and starts paging out to disk when free memory drops to zero, even as half of the available RAM (which is a lot) is marked as inactive. ... Well, this is not a case of a BSD is dying troll (you can safely ignore those). yes it is, just search a bit to know what inactive memory in FreeBSD is. His description (the quoted text) is at least of intuitive nature, and in fact in may be correct as it referrs to OS X MM subsys, which may be based on least-recently used pageout algorithm (as FreeBSD originally used to be too). jb ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: FreeBSD vice OS X memory management
Wojciech Puchar wojtek at wojtek.tensor.gdynia.pl writes: does OS X kernel share any code with FreeBSD kernel's memory management subsystem ? IMHO no. OSX is somehow-microkernel based, they did take things from FreeBSD but not this IMHO. anyway - who cares Well, I quoted the source in my 2nd post in this thread. But I will repeat it once again: I'm quite sure that the memory manager of OSX wasn't derived from BSD, but from Mach. Actually, FreeBSD has adapted that memory manager, so it's rather the other way around If so, both OS X and FreeBSD share the same MM subsys base. jb ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: editor that understands CTRL/B, CTRL/I, CTRL/U
On Sat, 28 Apr 2012 07:41:18 +0200 Polytropon articulated: On Fri, 27 Apr 2012 16:46:52 -0400, Jerry wrote: On Fri, 27 Apr 2012 13:58:40 -0600 Chad Perrin articulated: On Fri, Apr 27, 2012 at 01:57:10PM -0400, Jerry wrote: On Fri, 27 Apr 2012 10:32:24 -0600 Chad Perrin articulated: On Thu, Apr 26, 2012 at 06:43:06PM -0400, Jerry wrote: On Thu, 26 Apr 2012 15:52:56 -0600 Chad Perrin articulated: On Thu, Apr 26, 2012 at 02:45:53PM -0700, David Brodbeck wrote: Generic skills aren't recognized because they're hard to judge and test for. People want quantifiable, objective things to weed out applicants. This is also why credit scoring has become so popular -- sure, someone's credit score may not tell whether they'd be a good employee or not, but it's a convenient, objective way to throw out a bunch of resumes. Indeed -- and the employer who bucks this trend does him/her self a huge service, because large numbers of very skilled and/or talented people are being rejected on entirely arbitrary criteria that have little or no correlation to their ability to do the job. People who use such critera are forcing themselves to compete with everyone else in the industry using the same criteria, leaving a glut of job candidates who would be great at the job waiting for someone else to give them a chance. Wouldn't it be far easier for this glut of job applicants to either become proficient in the skills stated in the job description for which they are applying or do what everyone else does; i.e. lie on their résumé. If the mountain will not come to Mahomet, Mahomet must go to the mountain. 1. Pretty much every employer has a slightly different list of keywords. I guess you think all these job candidates should learn every skill in the world. No, I think they should learn the one(s) most sought after in their chosen field. If 90% of the potential openings in a specific field are requesting proficiency with MS Word, what do you think any legitimate applicants should become proficient in? Right -- because all the keywords you need will always be Microsoft Word. Admit it: you're just making up half-baked excuses to disagree now. If the requirement is for proficiency in MS Word, Excel or whatever and you lack those skills then you are not qualified for the job. Period. There are two problems hidden: 1. You typically cannot learn proprietary products for free. Of course there are books and online material to help you, but you cannot try the software. You have to buy it, and you have to buy the OS that supports it. There is no (legal) way for autodidacts to make theirselves familiar by learning and doing. Irrelevant. You cannot learn to be a doctor, lawyer, physicist, etcetera sans an education. Unless you have managed to acquire a free ride, i.e. you are getting the education on someone elses dime, you will need to pay. Quite frankly Poly, I would have expected a better argument from you than that. It was really quite bogus. 2. There are many different versions, so when you encounter Microsoft Word as a required skill, you cannot be sure that the skill _you_ have will be the right one. You know that products like Word differ from version to version. And of course they highly differ from established and standardized ways of doing things, so your generic knowledge (e. g. acquired by learning and doing OpenOffice or StarOffice or Abiword) isn't fully portable simply because of the arbitraryness of how Word does things. arbitraryness [sic} is one way of describing it. Since MS Office is the de facto standard it can be stated that the other entries in the word processing field are guilty of arbitrariness in their approach to the matter. For the record, would you please point me to the RFC that gives the requirements for a word processor. I must have missed it somewhere. By the way, have you noticed that StarOffice, OpenOffice nor Abiword all work exactly the same either? Are they guilty of arbitrariness? Come to think about it, FreeBSD does not work the same as Ubuntu or linux. In fact, none of them work exactly the same. Quick Poly, call the Arbitrariness Police?. This must be nipped in the bud immediately. But let's rest the Word case. There is other software much more expensive and far less present on home systems to do and learn. Oracle databases, Enterprise Java Frameworks or SAP are just a few examples. There are _courses_ that you can attend in order to learn more. For example, such courses cost 2000-10,000 Euro here. This is nothing that poor people can afford, even though they are highly skilled IT nerds. For the most part, I fully concur with you. Several years ago my wife was required to take a course in Microsoft Office Access in order to get a promotion in her job. The course only cost $49 and was given over, if I remember correctly, four or six nights over a two week period.
Re: UFS Crash and directories now missing
On Sat, Apr 28, 2012 at 3:22 AM, Wojciech Puchar woj...@wojtek.tensor.gdynia.pl wrote: I somewhat agree, but it wasn't a person. I am the only administrator, the only one with root access. The jails were effectively moved to the /usr/local/etc/apache22 of the single that survived at the top level. I'm thinking something between mount, EzJail, the journal and the way MySQL created a great deal of head contention, so something must have gotten corrupted at the directory level like you state, but the strange part is no _data_ corruption as such, because I was able to physically archive the jails, move them to the correct directory and no matter what you do FreeBSD DOES NOT ramdomly move directories. if you are sure you didn't move it yourself then it must be machine hardware problem but still unlikely. After a little more research, ___it it NOT unlikely at all___ that under high distress and a hard boot, UFS could have somehow corrupted the directory structure, whilst maintaining the data intact. From what I've learned so far, UFS is actually divided into 2 layers: one that controls the directory structure and metadata and a lower layer containing the data, so the directories being screwed up and the data intact it is actually quite possible. What I'm trying to do is figure out is how it happened, and try prevent it from happening again, so instead of dismissing it as impossibility, I think we all should spend a little time figuring out how these things can happen and determine how it can be prevented or reduced. Should you find your neighbor's beard catch fire, it's wise to soak one's own -- Alejandro ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: UFS Crash and directories now missing
Alejandro Imass aim...@yabarana.com wrote: On Sat, Apr 28, 2012 at 3:22 AM, Wojciech Puchar woj...@wojtek.tensor.gdynia.pl wrote: I somewhat agree, but it wasn't a person. I am the only administrator, the only one with root access. The jails were effectively moved to the /usr/local/etc/apache22 of the single that survived at the top level. I'm thinking something between mount, EzJail, the journal and the way MySQL created a great deal of head contention, so something must have gotten corrupted at the directory level like you state, but the strange part is no _data_ corruption as such, because I was able to physically archive the jails, move them to the correct directory and no matter what you do FreeBSD DOES NOT ramdomly move directories. if you are sure you didn't move it yourself then it must be machine hardware problem but still unlikely. After a little more research, ___it it NOT unlikely at all___ that under high distress and a hard boot, UFS could have somehow corrupted the directory structure, whilst maintaining the data intact. This is techically accurate, *BUT* the specifics of the quote corruption unquote in the case under discussion make it *EXTREMELY* unlikely that this is what happened. 99.99+++% of all UFS filesystem corruption' issues are the result of a system crash _between_ the time cached 'meta-data' is updated in memory and that data is flushed to disk (a deferred write). The second most common (and vanishingly rare) failure mode is a powerfail _as_ a sector of disk is being written -- resulting in 'garbage data' being written to disk. The next possibility is 'cosmic rays'. If running on 'cheap' hardware (i.e., without 'ECC' memory), this can cause a *SINGLE-BIT* error in data being output. The fact that the 'corrupted' filesystem passed fsck -without- any reported errors shows that everything in the filesystem meta-data was consistent Given *that*, there are precisely *TWO* ways that the 'results' that have been reported could have happened. 1) Something did a mv(2) of the various jail directories 'from' their original location to the 'apache' diretory. This involves simply *copying* the diretory entry from the jail's 'parent directory' to the apache directory, and then marking the entry in the original parent as 'unused'. Nothing other than the directory whre the jail 'used to live', and the directory 'where it was found' are touched. This occured _through_ the system 'mv' function, so all the normal 'housekeeping' was done properly. 2) it was -not- done though mv(2) -- but that requires that a whole *series* of corruptions of the filesystem, _ALL_ of which had to occur in 'exactly' the right way. They are: 1) The -size- (filesystem metadata) of the orignal parent directory had to be changed to reflect the smaller size. 2) the 'indirect block' info for the original parent directory had to be changed to reflect the absense of the block(s) that are no longer part of that file. 3) the _size_ of the Apache directory had to be increased to reflect the additional block(s) that are now part o that directory. 4) the 'indirect block' info for the apache directory has to be changed to reflect the presense of the new block(s) that are now part of that file. This requires multiple -hundreds- of bits 'in error', in a minimum of FOUR separate disk locations. A -single- failure simply *CANNOT* cause all of this. The probability of a random single-bit error in a gigabyte of RAM is on the order of one such occurance in six months. The odds of having multiple *simultaneous* errors is the probability of a single-bit error raised to the power of the number of bits in error. e.g. the probability of a simultaneous 10-bit radom error is roughly 1 in 30 million years. The odds of it being a -specific- ten bits out of that gigabyte is preposterously small. The odds of the required specific _multiple-hundreds_ of bits in error occuringis (conservatively) 1 in (30 million years)**50 * ((2**30)!) / ((2^9)!) The first factor, alone, is over 7.1E373 years. I think it is safe to conclude that the probabilities -greatly- favor alternative #1. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: editor that understands CTRL/B, CTRL/I, CTRL/U
On Sat, 28 Apr 2012 07:36:03 -0400, Jerry wrote: On Sat, 28 Apr 2012 07:41:18 +0200 Polytropon articulated: On Fri, 27 Apr 2012 16:46:52 -0400, Jerry wrote: On Fri, 27 Apr 2012 13:58:40 -0600 Chad Perrin articulated: On Fri, Apr 27, 2012 at 01:57:10PM -0400, Jerry wrote: On Fri, 27 Apr 2012 10:32:24 -0600 Chad Perrin articulated: On Thu, Apr 26, 2012 at 06:43:06PM -0400, Jerry wrote: On Thu, 26 Apr 2012 15:52:56 -0600 Chad Perrin articulated: On Thu, Apr 26, 2012 at 02:45:53PM -0700, David Brodbeck wrote: Generic skills aren't recognized because they're hard to judge and test for. People want quantifiable, objective things to weed out applicants. This is also why credit scoring has become so popular -- sure, someone's credit score may not tell whether they'd be a good employee or not, but it's a convenient, objective way to throw out a bunch of resumes. Indeed -- and the employer who bucks this trend does him/her self a huge service, because large numbers of very skilled and/or talented people are being rejected on entirely arbitrary criteria that have little or no correlation to their ability to do the job. People who use such critera are forcing themselves to compete with everyone else in the industry using the same criteria, leaving a glut of job candidates who would be great at the job waiting for someone else to give them a chance. Wouldn't it be far easier for this glut of job applicants to either become proficient in the skills stated in the job description for which they are applying or do what everyone else does; i.e. lie on their résumé. If the mountain will not come to Mahomet, Mahomet must go to the mountain. 1. Pretty much every employer has a slightly different list of keywords. I guess you think all these job candidates should learn every skill in the world. No, I think they should learn the one(s) most sought after in their chosen field. If 90% of the potential openings in a specific field are requesting proficiency with MS Word, what do you think any legitimate applicants should become proficient in? Right -- because all the keywords you need will always be Microsoft Word. Admit it: you're just making up half-baked excuses to disagree now. If the requirement is for proficiency in MS Word, Excel or whatever and you lack those skills then you are not qualified for the job. Period. There are two problems hidden: 1. You typically cannot learn proprietary products for free. Of course there are books and online material to help you, but you cannot try the software. You have to buy it, and you have to buy the OS that supports it. There is no (legal) way for autodidacts to make theirselves familiar by learning and doing. Irrelevant. You cannot learn to be a doctor, lawyer, physicist, etcetera sans an education. Unless you have managed to acquire a free ride, i.e. you are getting the education on someone elses dime, you will need to pay. Quite frankly Poly, I would have expected a better argument from you than that. It was really quite bogus. 2. There are many different versions, so when you encounter Microsoft Word as a required skill, you cannot be sure that the skill _you_ have will be the right one. You know that products like Word differ from version to version. And of course they highly differ from established and standardized ways of doing things, so your generic knowledge (e. g. acquired by learning and doing OpenOffice or StarOffice or Abiword) isn't fully portable simply because of the arbitraryness of how Word does things. arbitraryness [sic} is one way of describing it. Since MS Office is the de facto standard it can be stated that the other entries in the word processing field are guilty of arbitrariness in their approach to the matter. I don't agree here. The history in UI and behavioural changes in prograns like Word made whole generations of its users nearly completely RE-learn what they already could do before, worse or better. During the many versions things massively changed, and there is no _the_ Word version you find un business. Putting formatting options into the File menu is one of such things that I call arbitrary, because logic dictates that it would be expected to be where the other formatting options (typeface, selection, paragraph - page) are found. Something similar can be seen for visualisation settings: some of them are in View, some other aren't. Standard (at least in my idealized opinion) also includes file formats. Instead of memory dump blobs, programs like OpenOffice use a publically documented format which makes it easy to implement output processors for OO-files without further problems. For the record, would you please point me to the RFC that gives the requirements for a word processor. I must have missed it somewhere. By the
Re: UFS Crash and directories now missing
On Sat, Apr 28, 2012 at 11:39 AM, Robert Bonomi bon...@mail.r-bonomi.com wrote: Alejandro Imass aim...@yabarana.com wrote: On Sat, Apr 28, 2012 at 3:22 AM, Wojciech Puchar woj...@wojtek.tensor.gdynia.pl wrote: I somewhat agree, but it wasn't a person. I am the only administrator, the only one with root access. The jails were effectively moved to the /usr/local/etc/apache22 of the single that survived at the top level. I'm thinking something between mount, EzJail, the journal and the way MySQL created a great deal of head contention, so something must have gotten corrupted at the directory level like you state, but the strange part is no _data_ corruption as such, because I was able to physically archive the jails, move them to the correct directory and no matter what you do FreeBSD DOES NOT ramdomly move directories. if you are sure you didn't move it yourself then it must be machine hardware problem but still unlikely. After a little more research, ___it it NOT unlikely at all___ that under high distress and a hard boot, UFS could have somehow corrupted the directory structure, whilst maintaining the data intact. This is techically accurate, *BUT* the specifics of the quote corruption unquote in the case under discussion make it *EXTREMELY* unlikely that this is what happened. 99.99+++% of all UFS filesystem corruption' issues are the result of a system crash _between_ the time cached 'meta-data' is updated in memory and that data is flushed to disk (a deferred write). The second most common (and vanishingly rare) failure mode is a powerfail _as_ a sector of disk is being written -- resulting in 'garbage data' being written to disk. The next possibility is 'cosmic rays'. If running on 'cheap' hardware (i.e., without 'ECC' memory), this can cause a *SINGLE-BIT* error in data being output. The fact that the 'corrupted' filesystem passed fsck -without- any reported errors shows that everything in the filesystem meta-data was consistent Given *that*, there are precisely *TWO* ways that the 'results' that have been reported could have happened. 1) Something did a mv(2) of the various jail directories 'from' their original location to the 'apache' diretory. This involves simply *copying* the diretory entry from the jail's 'parent directory' to the apache directory, and then marking the entry in the original parent as 'unused'. Nothing other than the directory whre the jail 'used to live', and the directory 'where it was found' are touched. This occured _through_ the system 'mv' function, so all the normal 'housekeeping' was done properly. 2) it was -not- done though mv(2) -- but that requires that a whole *series* of corruptions of the filesystem, _ALL_ of which had to occur in 'exactly' the right way. They are: [...] I think it is safe to conclude that the probabilities -greatly- favor alternative #1. OK. So after your comments and further research I concur with you on the mv but if it wasn't a human, then this might be exposing a serious security flaw in the jail system or the way EzJail implements it. The whole point of using jails is to protect things like this from happening. Given that the only jail that survived was the front-end Apache Web server/reverse proxy, then it is also safe to suspect the apache (or other) process running on it was able to perform a mv of the rest of the jails to it's own /usr/local/etc/apache22 directory. Is there no possibility is that after the system crash, the journal recocery process and/or fsck could have moved this directories ? Thanks, -- Alejandro ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: UFS Crash and directories now missing
On Sat, Apr 28, 2012 at 12:36 PM, Alejandro Imass aim...@yabarana.com wrote: On Sat, Apr 28, 2012 at 11:39 AM, Robert Bonomi bon...@mail.r-bonomi.com wrote: Alejandro Imass aim...@yabarana.com wrote: On Sat, Apr 28, 2012 at 3:22 AM, Wojciech Puchar woj...@wojtek.tensor.gdynia.pl wrote: I somewhat agree, but it wasn't a person. I am the only administrator, the only one with root access. The jails were effectively moved to the /usr/local/etc/apache22 of the single that survived at the top level. I'm thinking something between mount, EzJail, the journal and the way MySQL created a great deal of head contention, so something must have gotten corrupted at the directory level like you state, but the strange part is no _data_ corruption as such, because I was able to physically archive the jails, move them to the correct directory and no matter what you do FreeBSD DOES NOT ramdomly move directories. if you are sure you didn't move it yourself then it must be machine hardware problem but still unlikely. After a little more research, ___it it NOT unlikely at all___ that under high distress and a hard boot, UFS could have somehow corrupted the directory structure, whilst maintaining the data intact. This is techically accurate, *BUT* the specifics of the quote corruption unquote in the case under discussion make it *EXTREMELY* unlikely that this is what happened. 99.99+++% of all UFS filesystem corruption' issues are the result of a system crash _between_ the time cached 'meta-data' is updated in memory and that data is flushed to disk (a deferred write). The second most common (and vanishingly rare) failure mode is a powerfail _as_ a sector of disk is being written -- resulting in 'garbage data' being written to disk. The next possibility is 'cosmic rays'. If running on 'cheap' hardware (i.e., without 'ECC' memory), this can cause a *SINGLE-BIT* error in data being output. The fact that the 'corrupted' filesystem passed fsck -without- any reported errors shows that everything in the filesystem meta-data was consistent Given *that*, there are precisely *TWO* ways that the 'results' that have been reported could have happened. 1) Something did a mv(2) of the various jail directories 'from' their original location to the 'apache' diretory. This involves simply *copying* the diretory entry from the jail's 'parent directory' to the apache directory, and then marking the entry in the original parent as 'unused'. Nothing other than the directory whre the jail 'used to live', and the directory 'where it was found' are touched. This occured _through_ the system 'mv' function, so all the normal 'housekeeping' was done properly. 2) it was -not- done though mv(2) -- but that requires that a whole *series* of corruptions of the filesystem, _ALL_ of which had to occur in 'exactly' the right way. They are: [...] I think it is safe to conclude that the probabilities -greatly- favor alternative #1. OK. So after your comments and further research I concur with you on the mv but if it wasn't a human, then this might be exposing a serious security flaw in the jail system or the way EzJail implements it. The whole point of using jails is to protect things like this from happening. Given that the only jail that survived was the front-end Apache Web server/reverse proxy, then it is also safe to suspect the apache (or other) process running on it was able to perform a mv of the rest of the jails to it's own /usr/local/etc/apache22 directory. Is there no possibility is that after the system crash, the journal recocery process and/or fsck could have moved this directories ? Also note that even the EzJail basejail was moved also, so it could be a security hole in the way nullfs is used or in nullfs itself. but the curious thing is that the basejail is supposed to be mounted read-only so how did that get moved to the http-proxy jail?? That is why I suspect it could have been something in the boot process like the journal recovery, fsck or something else with that kind of privilege and when the EzJail filesystems were unmounted. -- Alejandro ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: UFS Crash and directories now missing
Alejandro Imass aim...@yabarana.com wrote: On Sat, Apr 28, 2012 at 11:39 AM, Robert Bonomi bon...@mail.r-bonomi.com wrote: Alejandro Imass aim...@yabarana.com wrote: After a little more research, ___it it NOT unlikely at all___ that under high distress and a hard boot, UFS could have somehow corrupted the directory structure, whilst maintaining the data intact. This is techically accurate, *BUT* the specifics of the quote corruption unquote in the case under discussion make it *EXTREMELY* unlikely that this is what happened. 99.99+++% of all UFS filesystem corruption' issues are the result of a system crash _between_ the time cached 'meta-data' is updated in memory and that data is flushed to disk (a deferred write). The second most common (and vanishingly rare) failure mode is a powerfail _as_ a sector of disk is being written -- resulting in 'garbage data' being written to disk. The next possibility is 'cosmic rays'. If running on 'cheap' hardware (i.e., without 'ECC' memory), this can cause a *SINGLE-BIT* error in data being output. The fact that the 'corrupted' filesystem passed fsck -without- any reported errors shows that everything in the filesystem meta-data was consistent [...] I think it is safe to conclude that the probabilities -greatly- favor alternative #1. OK. So after your comments and further research I concur with you on the mv but if it wasn't a human, then this might be exposing a serious security flaw in the jail system or the way EzJail implements it. BOGON ALERT!!! Jails only prevent stuff -inside- the jail from affecting stuff outside the jail. They do *NOT* prevent stuff 'oustide the jail' from affecting stuff INSIDE the jail. For any fool-proof system, there exists a *sufficiently*determined* fool capable of breaking it. The whole point of using jails is to protect things like this from happening. FALSE TO FACT. Given that the only jail that survived was the front-end Apache Web server/reverse proxy, then it is also safe to suspect the apache (or other) process running on it was able to perform a mv of the rest of the jails to it's own /usr/local/etc/apache22 directory. FALSE TO FACT. Is there no possibility is that after the system crash, the journal recocery process and/or fsck could have moved this directories ? Anything is 'possible' -- c.f. 'nasal monkeys'. HOWEVER, if, for example, you would bother to examine the source code for fsck you would discover that it doesn't do -anything- 'significant' without ASKING FIRST. You reported it didn't find any problems -- not even anay of the 'petty' ones it will correct w/o asking -if- the '-p' option is specified. Journal revovery _could_, 'theoretically' have done it -- *IF* something else did the 'mv' just before the crash, and that operation was journaled, but not yet committed to disk at the time of the crash. However, on a standard UFS filesystem, filesystem metadata updates are written 'synchronously', which should eliminate _that_ wild, unfounded, speculaction. You sir, don't know what you don't know, and much of what you think you know is incorrect. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: UFS Crash and directories now missing
On Sat, Apr 28, 2012 at 1:31 PM, Robert Bonomi bon...@mail.r-bonomi.com wrote: Alejandro Imass aim...@yabarana.com wrote: On Sat, Apr 28, 2012 at 11:39 AM, Robert Bonomi bon...@mail.r-bonomi.com wrote: Alejandro Imass aim...@yabarana.com wrote: After a little more research, ___it it NOT unlikely at all___ that under high distress and a hard boot, UFS could have somehow corrupted the directory structure, whilst maintaining the data intact. This is techically accurate, *BUT* the specifics of the quote corruption unquote in the case under discussion make it *EXTREMELY* unlikely that this is what happened. 99.99+++% of all UFS filesystem corruption' issues are the result of a system crash _between_ the time cached 'meta-data' is updated in memory and that data is flushed to disk (a deferred write). The second most common (and vanishingly rare) failure mode is a powerfail _as_ a sector of disk is being written -- resulting in 'garbage data' being written to disk. The next possibility is 'cosmic rays'. If running on 'cheap' hardware (i.e., without 'ECC' memory), this can cause a *SINGLE-BIT* error in data being output. The fact that the 'corrupted' filesystem passed fsck -without- any reported errors shows that everything in the filesystem meta-data was consistent [...] I think it is safe to conclude that the probabilities -greatly- favor alternative #1. OK. So after your comments and further research I concur with you on the mv but if it wasn't a human, then this might be exposing a serious security flaw in the jail system or the way EzJail implements it. BOGON ALERT!!! I admit my ignorance on how the filesystem works but I don't think your condescending remarks add a lot of value. The issue here is this actually happened and there is a flaw somewhere other than the stupid administrator did it. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: UFS Crash and directories now missing
On Sat, 28 Apr 2012 13:52:02 -0400, Alejandro Imass wrote: On Sat, Apr 28, 2012 at 1:31 PM, Robert Bonomi bon...@mail.r-bonomi.com wrote: Alejandro Imass aim...@yabarana.com wrote: On Sat, Apr 28, 2012 at 11:39 AM, Robert Bonomi bon...@mail.r-bonomi.com wrote: Alejandro Imass aim...@yabarana.com wrote: After a little more research, ___it it NOT unlikely at all___ that under high distress and a hard boot, UFS could have somehow corrupted the directory structure, whilst maintaining the data intact. This is techically accurate, *BUT* the specifics of the quote corruption unquote in the case under discussion make it *EXTREMELY* unlikely that this is what happened. 99.99+++% of all UFS filesystem corruption' issues are the result of a system crash _between_ the time cached 'meta-data' is updated in memory and that data is flushed to disk (a deferred write). The second most common (and vanishingly rare) failure mode is a powerfail _as_ a sector of disk is being written -- resulting in 'garbage data' being written to disk. The next possibility is 'cosmic rays'. If running on 'cheap' hardware (i.e., without 'ECC' memory), this can cause a *SINGLE-BIT* error in data being output. The fact that the 'corrupted' filesystem passed fsck -without- any reported errors shows that everything in the filesystem meta-data was consistent [...] I think it is safe to conclude that the probabilities -greatly- favor alternative #1. OK. So after your comments and further research I concur with you on the mv but if it wasn't a human, then this might be exposing a serious security flaw in the jail system or the way EzJail implements it. BOGON ALERT!!! I admit my ignorance on how the filesystem works but I don't think your condescending remarks add a lot of value. The issue here is this actually happened and there is a flaw somewhere other than the stupid administrator did it. If you search the archives of this list, you'll find my _first_ post to that list: I've had a similar problem, df shows data must be there after crash (panic - reboot - fsck trouble), but files aren't there (even _not_ in lost+found). It's quite possible that in _exceptional_ moments this can happen. The fsck program is intended to repair the most typical file system faults, but nothing complicated will be done without interaction: Altering data on disk will _always_ involve the responsible (!) admin to check if it is really intended to do so. There can be many reasons. I've never found out what was the reason for the trouble I've had. Some years ago, I found a make failing because /uss/src/blah... something not found, and a quick memtest revealed the secret: defective RAM module that caused a bit error, and the difference between r and s is just one bit. Replaced the module - everything worked. Mean soldering rays from outer space. :-) You'll find many useful forensic tools in the ports collection that might help locate lost data (quotes intended as long as the data is still on the disk). The more complex your setting is (e. g. striped disks, or ZFS), this can be nearly impossible. Plain old UFS can sometimes be your saviour (but BACKUP should be your real friend). -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: UFS Crash and directories now missing
On Sat, Apr 28, 2012 at 2:01 PM, Polytropon free...@edvax.de wrote: On Sat, 28 Apr 2012 13:52:02 -0400, Alejandro Imass wrote: On Sat, Apr 28, 2012 at 1:31 PM, Robert Bonomi bon...@mail.r-bonomi.com wrote: Alejandro Imass aim...@yabarana.com wrote: On Sat, Apr 28, 2012 at 11:39 AM, Robert Bonomi bon...@mail.r-bonomi.com wrote: Alejandro Imass aim...@yabarana.com wrote: After a little more research, ___it it NOT unlikely at all___ that under high distress and a hard boot, UFS could have somehow corrupted the directory structure, whilst maintaining the data intact. This is techically accurate, *BUT* the specifics of the quote corruption unquote in the case under discussion make it *EXTREMELY* unlikely that this is what happened. 99.99+++% of all UFS filesystem corruption' issues are the result of a system crash _between_ the time cached 'meta-data' is updated in memory and that data is flushed to disk (a deferred write). The second most common (and vanishingly rare) failure mode is a powerfail _as_ a sector of disk is being written -- resulting in 'garbage data' being written to disk. The next possibility is 'cosmic rays'. If running on 'cheap' hardware (i.e., without 'ECC' memory), this can cause a *SINGLE-BIT* error in data being output. The fact that the 'corrupted' filesystem passed fsck -without- any reported errors shows that everything in the filesystem meta-data was consistent [...] I think it is safe to conclude that the probabilities -greatly- favor alternative #1. OK. So after your comments and further research I concur with you on the mv but if it wasn't a human, then this might be exposing a serious security flaw in the jail system or the way EzJail implements it. BOGON ALERT!!! I admit my ignorance on how the filesystem works but I don't think your condescending remarks add a lot of value. The issue here is this actually happened and there is a flaw somewhere other than the stupid administrator did it. If you search the archives of this list, you'll find my _first_ post to that list: I've had a similar problem, df shows data must be there after crash (panic - reboot - fsck trouble), but files aren't there (even _not_ in lost+found). It's quite possible that in _exceptional_ moments this can happen. The fsck program is intended to repair the most typical file system faults, but nothing complicated will be done without interaction: Altering data on disk will _always_ involve the responsible (!) admin to check if it is really intended to do so. There can be many reasons. I've never found out what was the [...] that might help locate lost data (quotes intended as long as the data is still on the disk). The more complex your setting is (e. g. striped disks, or ZFS), this can be nearly impossible. Plain old UFS can sometimes be your saviour (but BACKUP should be your real friend). Thanks for your reply. I can't figure out how there was no data loss and yet the directories moved just like that. We have nightly backups and it's one of the features we love about EzJail and it's archive feature. The base system sits on another disk entirely and it's pristine, we don't install anything except the basic system on the system disk and the other disk is exclusively divided in jails, so the possibility of an outside process doing the mv is unlikely. Everything point to that something or someone executed a mv but how was this done? or if there is a potential problem and could happen again. And contrary to other comments here, and my admitted ignorance, I believe there are actually 3 possibilities: 1) something inside a jail was able to move the other jails into itself 2) something outside the jails moved the jails 3) the directories were moved at reboot by journal recovery, fsck or something else That is what worries me, is that it wasn't just some random bit or cosmic ray, but the potential of happening again. I am not so sure that it is *impossible* that a jail could affect other jails with EzJail. -- Alejandro ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: UFS Crash and directories now missing
On 28/04/2012 19:52, Alejandro Imass wrote: On Sat, Apr 28, 2012 at 1:31 PM, Robert Bonomibon...@mail.r-bonomi.com wrote: Alejandro Imassaim...@yabarana.com wrote: On Sat, Apr 28, 2012 at 11:39 AM, Robert Bonomi bon...@mail.r-bonomi.com wrote: Alejandro Imassaim...@yabarana.com wrote: After a little more research, ___it it NOT unlikely at all___ that under high distress and a hard boot, UFS could have somehow corrupted the directory structure, whilst maintaining the data intact. This is techically accurate, *BUT* the specifics of the quote corruption unquote in the case under discussion make it *EXTREMELY* unlikely that this is what happened. 99.99+++% of all UFS filesystem corruption' issues are the result of a system crash _between_ the time cached 'meta-data' is updated in memory and that data is flushed to disk (a deferred write). The second most common (and vanishingly rare) failure mode is a powerfail _as_ a sector of disk is being written -- resulting in 'garbage data' being written to disk. The next possibility is 'cosmic rays'. If running on 'cheap' hardware (i.e., without 'ECC' memory), this can cause a *SINGLE-BIT* error in data being output. The fact that the 'corrupted' filesystem passed fsck -without- any reported errors shows that everything in the filesystem meta-data was consistent [...] I think it is safe to conclude that the probabilities -greatly- favor alternative #1. OK. So after your comments and further research I concur with you on the mv but if it wasn't a human, then this might be exposing a serious security flaw in the jail system or the way EzJail implements it. BOGON ALERT!!! I admit my ignorance on how the filesystem works but I don't think your condescending remarks add a lot of value. The issue here is this actually happened and there is a flaw somewhere other than the stupid administrator did it. Ok, Not wanting to take any side in what could end up in personal attacks and nasty things being said about any poster genitors but : - Jails are very widely used, in fact it is probably one of the most used functionnality of FreeBSD. Far beyond ZFS, MAC or any of the other nice thingies FreeBSD has. - Jails are very often misused. Though not overly complex, creating a proper jail and upgrading it can sometime be a bit tricky. - Though not entirely devoid of bug and perfect, FreeBSD 8.2 is probably the best thing there is out there when it comes to system stability. It might be lacking some little nooks and cranies when it comes to perfect compliance with obscure standards, it might not behave as expected in some very few situation, but these are extremely rare. FreeBSD 8.2 is very widely used and this is one of the first time I heard of such a problem in jails. Nothing even remotely rings a bell. Take all these information into account and put yourself in our shoes. When reading your problem description, most of us will be inclined to think that you did something wrong. My personnal guess would be that you probably abused ln a bit too much when creating the jails (total shot in the dark here, but it could explain what happened). I don't see how journaling could impact your jails in anyway except if your jails were all extremely new when the crash happened or that the I/O was such that FreeBSD could never sync and commit journal from the time you created your jails to the time where the system crashed. Extremely unlikely. So my question is : where all the jail created properly ? Did you cpdup each and every one of them or were you lazy at some point ? Are all the jails properly declared in rc.conf ? My guess would be that the first jail was created in the right way, but that others were created using cp and ln, resulting in unexpected behaviour in the end. If I am right then the surviving jail would be either the first or the last you created. Jerome Herman ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: UFS Crash and directories now missing
On 04/28/2012 11:16 AM, Alejandro Imass wrote: That is what worries me, is that it wasn't just some random bit or cosmic ray, but the potential of happening again. I am not so sure that it is*impossible* that a jail could affect other jails with EzJail. Sorry I'm late to the party. How about contacting EZjail and explaining what has happen:-) it may be a bug? http://erdgeist.org/arts/software/ezjail/#Author ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Performance and mouse problems
Le 27/04/2012 ? 12:14:04-0500, Adam Vande More a écrit On Fri, Apr 27, 2012 at 11:13 AM, Albert Shih albert.s...@obspm.fr wrote: Hi all I've got two very strange problem I'm running 9-stable on a Dell Laptop E4200. Since this morning when I put a USB mouse (I've try three mouses to be sure) it's not working. The kernel and HAL see the mouse but Xorg don't seem do anything. The second point is the load of the system is alway more than 1 (~1.5-2) event I do nothing. I kill all services, daemon, software and the load never drop. I've stop : hald dbus powerd etc... and ps don't show any process eating some ressource. But the load is high (and the laptop is very hot). I make a csup of world and build new userland, and news kernel. And nothing change http://www.wonkity.com/~wblock/docs/html/aei.html Well I don't see why this can be from a misconfiguration, the usb mouse work well before I update hald and world. But I read you link and I don't have those option in my configuration of xorg. Any other idea ? But thanks. For the problem about performance I submit this problem on stable mailing list. Regards JAS -- Albert SHIH DIO bâtiment 15 Observatoire de Paris 5 Place Jules Janssen 92195 Meudon Cedex Téléphone : 01 45 07 76 26/06 86 69 95 71 xmpp: j...@obspm.fr Heure local/Local time: sam 28 avr 2012 22:49:23 CEST ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: UFS Crash and directories now missing
Hi, On Saturday 28 April 2012 20:15:25 Alejandro Imass wrote: On Sat, Apr 28, 2012 at 3:22 AM, Wojciech Puchar woj...@wojtek.tensor.gdynia.pl wrote: I somewhat agree, but it wasn't a person. I am the only administrator, the only one with root access. The jails were effectively moved to the /usr/local/etc/apache22 of the single that survived at the top level. I'm thinking something between mount, EzJail, the journal and the way MySQL created a great deal of head contention, so something must have gotten corrupted at the directory level like you state, but the strange part is no _data_ corruption as such, because I was able to physically archive the jails, move them to the correct directory and no matter what you do FreeBSD DOES NOT ramdomly move directories. if you are sure you didn't move it yourself then it must be machine hardware problem but still unlikely. After a little more research, ___it it NOT unlikely at all___ that under high distress and a hard boot, UFS could have somehow corrupted the directory structure, whilst maintaining the data intact. From what I've learned so far, UFS is actually divided into 2 layers: one that controls the directory structure and metadata and a lower layer containing the data, so the directories being screwed up and the data intact it is actually quite possible. What I'm trying to do is figure out is how it happened, and try prevent it from happening again, so instead of dismissing it as impossibility, I think we all should spend a little time figuring out how these things can happen and determine how it can be prevented or reduced. somebody mentioned the links. Did you use links in the jails to access the data? If then the directories of the jails got screwed, the links are gone but the original data is still there. The damaged directory might got fixed during the first reboot after the crash and you never noticed the fix. Erich ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Performance and mouse problems
On 28/04/2012 22:52, Albert Shih wrote: Le 27/04/2012 ? 12:14:04-0500, Adam Vande More a écrit On Fri, Apr 27, 2012 at 11:13 AM, Albert Shihalbert.s...@obspm.fr wrote: Hi all I've got two very strange problem I'm running 9-stable on a Dell Laptop E4200. Since this morning when I put a USB mouse (I've try three mouses to be sure) it's not working. The kernel and HAL see the mouse but Xorg don't seem do anything. The second point is the load of the system is alway more than 1 (~1.5-2) event I do nothing. I kill all services, daemon, software and the load never drop. I've stop : hald dbus powerd etc... and ps don't show any process eating some ressource. But the load is high (and the laptop is very hot). I make a csup of world and build new userland, and news kernel. And nothing change http://www.wonkity.com/~wblock/docs/html/aei.html Well I don't see why this can be from a misconfiguration, the usb mouse work well before I update hald and world. But I read you link and I don't have those option in my configuration of xorg. Any other idea ? But thanks. For the problem about performance I submit this problem on stable mailing list. Regards JAS I was afraid this would happen. And I fear it is just the begining. I assume you did not create any custom hald rule. Did you ? The first thing to do is to add Option AutoAddDevices Off In your ServerLayout section of xorg.conf. Then restart X and try to plug a mouse again. It may result in your mouse not working in X, but at least it should stop your computer from using all it's CPU trying to map the mouse. If indeed the CPU load does not reach skyhigh levels when you plug a USB mouse, we will be able to conclude that there is a DBus/hald problem. Also could you do the following - Mouse unplugged : # /usr/local/etc/rc.d/hald stop # /usr/local/sbin/hald --daemon=no --verbose=yes /tmp/hald_debug.log 21 # dbus-launch lshal /tmp/dbus_hal_debug.log 21 - plug mouse # dbus-launch lshal /tmp/dbus_hal_debug.log 21 And post the content of both log files ? That should help in understanding what is going on. In the worst case there are mecanism that will keep HAL from tinkering/probing usb mouse. Jerome Herman ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: editor that understands CTRL/B, CTRL/I, CTRL/U
On 2012-04-24 11:50, Anton Shterenlikht wrote: My daughter is doing a touch typing course that presumes MS Word. So far she was fine with pico, but now they want the kids to practice CTRL/B (bold), CTRL/I (italic), CTRL/U (underline). She really needs to use these particular combinations because that is how the on-line assessment tool is set out. I use nothing but vi, so have no clue which, if any, editor from ports/editors will have these particular combinations implemented. Please recommend one, preferably as simple and as small as possible. I'm a serious vi(m) advocate, but in this case, due to the use case, I also ++ Abiword. Steve ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: UFS Crash and directories now missing
Alejandro Imass a...@p2ee.org wrote: 3) the directories were moved at reboot by journal recovery, fsck or something else I think it's *extremely* unlikely that fsck was involved, because it just doesn't do things like that. It might move an orphaned directory (or file) to lost+found, but nowhere else. That's in addition to the fact that, as someone already mentioned, it asks before doing anything. I don't know enough about the details of journal recovery to comment on it as a suspect. That is what worries me, is that it wasn't just some random bit or cosmic ray, but the potential of happening again ... Any chance that your base system -- rather than one of the jails -- has somehow been cracked; maybe even that the cracker precipitated the crash? It might be wise to restore the whole system from backup, the base from a moderately old one since it doesn't change anyway, rather than trying to recover. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: UFS Crash and directories now missing
On Sat, Apr 28, 2012 at 5:03 PM, Erich Dollansky er...@alogreentechnologies.com wrote: Hi, On Saturday 28 April 2012 20:15:25 Alejandro Imass wrote: On Sat, Apr 28, 2012 at 3:22 AM, Wojciech Puchar woj...@wojtek.tensor.gdynia.pl wrote: I somewhat agree, but it wasn't a person. I am the only administrator, the only one with root access. The jails were effectively moved to the /usr/local/etc/apache22 of the single that survived at the top level. I'm thinking something between mount, EzJail, the journal and the way MySQL created a great deal of head contention, so something must have gotten corrupted at the directory level like you state, but the strange part is no _data_ corruption as such, because I was able to physically archive the jails, move them to the correct directory and no matter what you do FreeBSD DOES NOT ramdomly move directories. if you are sure you didn't move it yourself then it must be machine hardware problem but still unlikely. After a little more research, ___it it NOT unlikely at all___ that under high distress and a hard boot, UFS could have somehow corrupted the directory structure, whilst maintaining the data intact. From what I've learned so far, UFS is actually divided into 2 layers: one that controls the directory structure and metadata and a lower layer containing the data, so the directories being screwed up and the data intact it is actually quite possible. What I'm trying to do is figure out is how it happened, and try prevent it from happening again, so instead of dismissing it as impossibility, I think we all should spend a little time figuring out how these things can happen and determine how it can be prevented or reduced. somebody mentioned the links. Did you use links in the jails to access the data? If then the directories of the jails got screwed, the links are gone but the original data is still there. The damaged directory might got fixed during the first reboot after the crash and you never noticed the fix. Hi Erich, thanks for your reply. I don't know what links you are referring to, but please point me in that direction. I initially suspected that it could have been the journal recovery and/or fsck but as you can see, a couple of people have said this is impossible, but have to admit my ignorance on some specifics of the UFS filesystem, yet out of logic seems like the most plausible explanation. I've been running FBSD since 6.2 and jails since then as well. Today I run 6 public servers in 8.2 with between 15 to 20 jails each and we switched to ezjail last year and use strictly by the book. I do use flavours though, and I may archive and re-create jails with a specific archive but always using ezjail-admin. Since all our servers are 8.2 and all updated the same, I may port jails from one server to the other using the ezjail archive method, but nothing as stupid as someone was suggesting that I was using cp or soft links. I've never had any problems except in _this particular server_ where I have client that has a problem with MySQL and under some conditions it drains the whole server. I suspected corruption of the fs because of all the contention generated by MySQL to the point where it simply hung and had to hard-reboot. I doubt it's hardware because these are relatively new servers Xeon X3370, 8GB RAM, 2 x 150GB 10,000rpm Velociraptor disks. We have the pristine OS in one disk and jails in the other. Nothing runs outside of jails, not even the MTA which runs postfix inside one of the jails. This is the first crash when anything like this has happened in over 6 years running FBSD, and I am surprised as anyone here because of the weirdness of the jail directories moving like that. We had backups of the previous night, but I didn't even use them. The data was all there, intact, just moved inside the only surviving jail, which happens to be the http reverse proxy of all the other jails. If you have any leads as to how this can happen other than cosmic rays I would greatly appreciate it. Thanks! -- Alejandro Erich ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: UFS Crash and directories now missing
On Sun, Apr 29, 2012 at 3:26 AM, per...@pluto.rain.com wrote: Alejandro Imass a...@p2ee.org wrote: [...] Any chance that your base system -- rather than one of the jails -- has somehow been cracked; maybe even that the cracker precipitated the crash? It might be wise to restore the whole system from backup, the base from a moderately old one since it doesn't change anyway, rather than trying to recover. There is always that possibility but I strive to keep these servers updated, I block most ap, nigeria and russia ip blocks using updated Wizcrafts' lists, run fail2ban and other security measures. We have a policy of only one password and there are no users or services in the base system other than mine. As I said in another mail I run 6 servers and been runing FBSD for almost 7 years and this is the first time I've seen this happen. -- Alejandro ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: UFS Crash and directories now missing
Hi, On Sunday 29 April 2012 08:58:17 Alejandro Imass wrote: On Sat, Apr 28, 2012 at 5:03 PM, Erich Dollansky er...@alogreentechnologies.com wrote: On Saturday 28 April 2012 20:15:25 Alejandro Imass wrote: On Sat, Apr 28, 2012 at 3:22 AM, Wojciech Puchar woj...@wojtek.tensor.gdynia.pl wrote: I somewhat agree, but it wasn't a person. I am the only administrator, the only one with root access. The jails were effectively moved to the /usr/local/etc/apache22 of the single that survived at the top level. I'm thinking something between mount, EzJail, the journal and the way MySQL created a great deal of head contention, so something must have gotten corrupted at the directory level like you state, but the strange part is no _data_ corruption as such, because I was able to physically archive the jails, move them to the correct directory and no matter what you do FreeBSD DOES NOT ramdomly move directories. if you are sure you didn't move it yourself then it must be machine hardware problem but still unlikely. After a little more research, ___it it NOT unlikely at all___ that under high distress and a hard boot, UFS could have somehow corrupted the directory structure, whilst maintaining the data intact. From what I've learned so far, UFS is actually divided into 2 layers: one that controls the directory structure and metadata and a lower layer containing the data, so the directories being screwed up and the data intact it is actually quite possible. What I'm trying to do is figure out is how it happened, and try prevent it from happening again, so instead of dismissing it as impossibility, I think we all should spend a little time figuring out how these things can happen and determine how it can be prevented or reduced. somebody mentioned the links. Did you use links in the jails to access the data? If then the directories of the jails got screwed, the links are gone but the original data is still there. The damaged directory might got fixed during the first reboot after the crash and you never noticed the fix. Hi Erich, thanks for your reply. I don't know what links you are referring to, but please point me in man link They are practical in jails when things are read only. Mark everything read-only and nothing should go wrong. that direction. I initially suspected that it could have been the journal recovery and/or fsck but as you can see, a couple of people I only installed journals on a new machine without any experience there. UFS does normally the job for me. have said this is impossible, but have to admit my ignorance on some specifics of the UFS filesystem, yet out of logic seems like the most plausible explanation. This is not a good reasoning. I have had clients using my own software for years before it crashed with an error which was in there since the start. I've been running FBSD since 6.2 and jails since then as well. Today I run 6 public servers in 8.2 with between 15 to 20 jails each and we switched to ezjail last year and use strictly by the book. I do use flavours though, and I may archive and re-create jails with a specific archive but always using ezjail-admin. Since all our servers are 8.2 and all updated the same, I may port jails from one server to the other using the ezjail archive method, but nothing as stupid as someone was suggesting that I was using cp or soft links. I never used ezjail in real life. I've never had any problems except in _this particular server_ where I have client that has a problem with MySQL and under some conditions it drains the whole server. I suspected corruption of the fs because of all the contention generated by MySQL to the point where it simply hung and had to hard-reboot. I doubt it's hardware because these are relatively new servers Xeon X3370, 8GB RAM, 2 x 150GB 10,000rpm Velociraptor disks. We have the pristine OS in one disk and jails in the other. Nothing runs outside of jails, not even the MTA which runs postfix inside one of the jails. This is the first crash when anything like this has happened in over 6 years running FBSD, and I am surprised as anyone here because of the weirdness of the jail directories moving like that. We had backups of the previous night, but I didn't even use them. The data was all there, intact, just moved inside the only surviving jail, which happens to be the http reverse proxy of all the other jails. If you have any leads as to how this can happen other than cosmic rays I would greatly appreciate it. Check if their are links there after you remade the system. I have also no other idea then. Erich Thanks! -- Alejandro Erich ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: UFS Crash and directories now missing
On Sat, Apr 28, 2012 at 10:20 PM, Erich Dollansky erichfreebsdl...@ovitrap.com wrote: Hi, On Sunday 29 April 2012 08:58:17 Alejandro Imass wrote: On Sat, Apr 28, 2012 at 5:03 PM, Erich Dollansky er...@alogreentechnologies.com wrote: [...] Hi Erich, thanks for your reply. I don't know what links you are referring to, but please point me in man link They are practical in jails when things are read only. Mark everything read-only and nothing should go wrong. I though you were referring to something else entirely. No, I don't use soft or hard links with jails, unless EzJail uses them but I doubt it, I think everything like that in EzJail is done by mounting via nullfs. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
