Re: pwd.db/spwd.db file corupption when having unsafe system poweroff
First, thank you for your quick and complete reply :) then: Furthermore, file system corruption due to an abrupt cut of power should be avoided. Whenever the system comes up in a non-clean state, fsck should be run first, _then_ the boot process should continue. Still it's possible that this process leaves truncated files behind (e. g. the binary database files with a length of zero, which implies they will have to be rebuilt by pwd_mkdb). i added fsck_background=no to rc.conf but i still see the error.. and i don't see any differance in system startup output! how should i know it's working?? Alternatively to pw, you could try adduser, which is more an interactive program, but can perform the same tasks. Again, it would take care of updating all required files. This is the situation one would expect after the program ended, or at least some seconds after one got back to the root prompt. when i tried using adduser, when a error occurs(like multiple definition of a username), it's pw who reports the errors! it means that adduser also uses pw.. is this functionality of taking care of updating all required files, an add-on appeared in add-user?? During the 2 minutes, you could use programs like lsof (it's in ports) to check if a program has a file open, so you could capture the power off while writing to file incident. i tried using lsof as well , but there was no differance.. yes! when i use pw -h 0 parameter, 10 extra files are added to the lsof list.. but exactly after i enter the password, all of them are closed(none of these files are of those main 5 files of users..lib files and alike..).. and in later monitoring with lsof, i could not catch the time when these files are in use!.. i'll write a shell to monitor it more detailed though.. After you could not login again, did you check the files involved in the login process? yes, file sizes are ok but pwd.db and swpd.db are out of use..(also once i opened passwd with nano and it had irrational characters..). always if i use pwd_mkdb or just replace these two files, in next startup system will come up fine! now there is something special about my own servers, which i'm suspicious of.. i've add an executable file to my /usr/local/etc/rc.d dir, which tries to initiate some parts of myserver.. this includes usernames as well.. i mean, i may have template users during system uptime, which i won't need in next startup.. this initiliazer will remove those unwanted users and redifine main usernames, using pw.. it works fine while having safe shutdowns but when i have the bug-generator scenario, it won't work.. may it be the conflict of running my initializer and fsck ? or is it true that rc.d files are executed in shutdown process as well? is shutdown process started when i start pressing power button for 4 seconds?? i don't know what else to think of... ___ 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: pwd.db/spwd.db file corupption when having unsafe system poweroff
On Sun, 5 May 2013 10:42:02 +0430, takCoder wrote: i added fsck_background=no to rc.conf but i still see the error.. and i don't see any differance in system startup output! how should i know it's working?? Please check the correct syntax for the /etc/rc.conf entry: background_fsck=NO See /etc/defaults/rc.conf for the correct syntax example. This will cause the system to perform a fsck _prior_ to bringing up multi-user mode. In case of severe errors that cannot be corrected by fsck without heavy modification of a file system (and therefor _may_ cause data loss), it will direct the decision to the operator and ask. In such a case, # fsck -yf filesystem(s) can be used, but read man fsck and man fsck_ufs for what the options -y and -f do, and if it is what you _intend_. Alternatively to pw, you could try adduser, which is more an interactive program, but can perform the same tasks. Again, it would take care of updating all required files. This is the situation one would expect after the program ended, or at least some seconds after one got back to the root prompt. when i tried using adduser, when a error occurs(like multiple definition of a username), it's pw who reports the errors! it means that adduser also uses pw.. is this functionality of taking care of updating all required files, an add-on appeared in add-user?? That's correct. Have a look as /usr/sbin/adduser: It is actually a shell script, and it calls /usr/sbin/pw to add entries. Running pwd_mkdb at any time can be used to make sure all data is in the correct format and valid. During the 2 minutes, you could use programs like lsof (it's in ports) to check if a program has a file open, so you could capture the power off while writing to file incident. i tried using lsof as well , but there was no differance.. yes! when i use pw -h 0 parameter, 10 extra files are added to the lsof list.. but exactly after i enter the password, all of them are closed(none of these files are of those main 5 files of users..lib files and alike..).. and in later monitoring with lsof, i could not catch the time when these files are in use!.. i'll write a shell to monitor it more detailed though.. That would be a good idea. However, after the program finishes and returns you to the shell prompt, no files should be left open. At program exit, all files will be closed (part of the exit routines automatically performed). After you could not login again, did you check the files involved in the login process? yes, file sizes are ok but pwd.db and swpd.db are out of use..(also once i opened passwd with nano and it had irrational characters..). That's not good. Such a file inconsistency should not exist. always if i use pwd_mkdb or just replace these two files, in next startup system will come up fine! So something damages those files. Not good. now there is something special about my own servers, which i'm suspicious of.. i've add an executable file to my /usr/local/etc/rc.d dir, which tries to initiate some parts of myserver.. this includes usernames as well.. i mean, i may have template users during system uptime, which i won't need in next startup.. this initiliazer will remove those unwanted users and redifine main usernames, using pw.. If you intend to have user templates, you can use the /usr/share/skel (or /etc/skel or even /usr/local/etc/skel directories; adduser defaults to /usr/share/skel, and pw has -k directory for a different location). This means you can have multiple templates that you do not need to instantiate unless you create an actual user. Just an idea. it works fine while having safe shutdowns but when i have the bug-generator scenario, it won't work.. may it be the conflict of running my initializer and fsck ? That is possible, that's why fsck should be run _prior_ to doing anything with (possibly) damaged file systems. or is it true that rc.d files are executed in shutdown process as well? This depends on the rc.d files. If they define an action that should be done at shutdown time, those actions will be called. Additionally, and keep in mind people will call me old-fashioned and un-modern for that suggestion: You can put simple scripting stuff into /etc/rc.local for start, and /etc/rc.shutdown.local for shutdown. It's still supported and it works. For stuff that is too simple to deserve a real rc.d script, those files can be used. is shutdown process started when i start pressing power button for 4 seconds?? No. In this case, the system will be _forcedly_ powered off, no shutdown procedures (performing rc.d shutdown commands, flushing buffers, unmounting file systems and so on) will take place. It is _not_ the way to power down a system! Alternatively, use shutdown -h now and _then_ do the pull the plug trick. Of course, shutdown -p now is more convenient if you intend to power down your system. If your power button acts properly (check
Re: pwd.db/spwd.db file corupption when having unsafe system poweroff
On 05/05/2013 07:12, takCoder wrote: Furthermore, file system corruption due to an abrupt cut of power should be avoided. Whenever the system comes up in a non-clean state, fsck should be run first, _then_ the boot process should continue. Still it's possible that this process leaves truncated files behind (e. g. the binary database files with a length of zero, which implies they will have to be rebuilt by pwd_mkdb). i added fsck_background=no to rc.conf but i still see the error.. and i don't see any differance in system startup output! how should i know it's working?? You won't see any difference if things are all running smoothly -- that's because fsck is only required in the case of an unclean shutdown. and that simply won't happen at all for an ordinary system reboot. The main difference you'ld see with fsck_background=no is that the system will take longer to come on-line after a crash. Depending on the size of your filesystems and how much you have stored in them, it can be very much longer: I've seen filesystems take hours to run a fsck. That's why background fsck exists -- it's better in many cases for a machine to be up and running and productive again quickly, even at the slight risk of problems due to filesystem corruption during the crash. With techniques like soft updates, which ensures file system meta-data consistency, the risks of such corruption are very much lower than without. Journalling effectively extends the same guarantee to data as well as to meta-data. And then there's the ZFS approach, where the copy-on-write semantics means that what is on disk is always coherent, although an unclean shutdown can lose the last few uncommitted changes. All in all, however you manage your disks the problem remains that in an unclean shutdown, filesystem changes in progress at the time of the crash will be lost. The best thing you can do to preserve your data is to minimize the chances of unclean shutdown. Which could be as expensive as installing UPSes everywhere, or as cheap as re-educating your users that pulling the plug or pressing and holding the power button is a bad thing(tm).[*] Cheers, Matthew [*] Some might suggest that this re-education is best achieved by a form of Pavlovian conditioning using severe negative reinforcement involving blunt force trauma. -- Dr Matthew J Seaman MA, D.Phil. PGP: http://www.infracaninophile.co.uk/pgpkey signature.asc Description: OpenPGP digital signature
DTrace support in Postgresql not working
Hi guys, I have a system running 10-CURRENT (r250217) which I've built Postgresql 9.2.4 with DTrace support enabled on a VM running 9.1-STABLE (r250009) which I'm unable to build it on. On 10-CURRENT the problem is that dtrace -l does not list the postgresql provider. My make.conf on both system is STRIP= CFLAGS+=-fno-omit-frame-pointer on 9.1-STABLE the build fails with Assertion failed: (nrc == rc), function _libelf_resync_sections, file /usr/src/lib/libelf/elf_update.c, line 341. gmake: *** [utils/probes.o] Abort trap: 6 (core dumped) gmake: *** Deleting file 'utils/probes.o' *** [do-build] Error code 2 on 10-CURRENT there are warnings generated but the build completes installs pgstat.c:2538:36: warning: passing 'const char *' to parameter of type 'char *' discards qualifiers [-Wincompatible-pointer-types-discards-qualifiers] TRACE_POSTGRESQL_STATEMENT_STATUS(cmd_str); ../../../src/include/utils/probes.h:424:42: note: expanded from macro 'TRACE_POSTGRESQL_STATEMENT_STATUS' __dtrace_postgresql___statement__status(arg0) ../../../src/include/utils/probes.h:803:59: note: passing argument to parameter here extern void __dtrace_postgresql___statement__status(char *); postgres.c:559:37: warning: passing 'const char *' to parameter of type 'char *' discards qualifiers [-Wincompatible-pointer-types-discards-qualifiers] TRACE_POSTGRESQL_QUERY_PARSE_START(query_string); ../../../src/include/utils/probes.h:316:44: note: expanded from macro 'TRACE_POSTGRESQL_QUERY_PARSE_START' __dtrace_postgresql___query__parse__start(arg0) ../../../src/include/utils/probes.h:731:61: note: passing argument to parameter here extern void __dtrace_postgresql___query__parse__start(char *); postgres.c:582:36: warning: passing 'const char *' to parameter of type 'char *' discards qualifiers [-Wincompatible-pointer-types-discards-qualifiers] TRACE_POSTGRESQL_QUERY_PARSE_DONE(query_string); ../../../src/include/utils/probes.h:307:43: note: expanded from macro 'TRACE_POSTGRESQL_QUERY_PARSE_DONE' __dtrace_postgresql___query__parse__done(arg0) ../../../src/include/utils/probes.h:725:60: note: passing argument to parameter here extern void __dtrace_postgresql___query__parse__done(char *); postgres.c:603:39: warning: passing 'const char *' to parameter of type 'char *' discards qualifiers [-Wincompatible-pointer-types-discards-qualifiers] TRACE_POSTGRESQL_QUERY_REWRITE_START(query_string); ../../../src/include/utils/probes.h:352:46: note: expanded from macro 'TRACE_POSTGRESQL_QUERY_REWRITE_START' __dtrace_postgresql___query__rewrite__start(arg0) ../../../src/include/utils/probes.h:755:63: note: passing argument to parameter here extern void __dtrace_postgresql___query__rewrite__start(char *); postgres.c:621:38: warning: passing 'const char *' to parameter of type 'char *' discards qualifiers [-Wincompatible-pointer-types-discards-qualifiers] TRACE_POSTGRESQL_QUERY_REWRITE_DONE(query_string); ../../../src/include/utils/probes.h:343:45: note: expanded from macro 'TRACE_POSTGRESQL_QUERY_REWRITE_DONE' __dtrace_postgresql___query__rewrite__done(arg0) ../../../src/include/utils/probes.h:749:62: note: passing argument to parameter here extern void __dtrace_postgresql___query__rewrite__done(char *); postgres.c:643:39: warning: passing 'const char *' to parameter of type 'char *' discards qualifiers [-Wincompatible-pointer-types-discards-qualifiers] TRACE_POSTGRESQL_QUERY_REWRITE_START(query_string); ../../../src/include/utils/probes.h:352:46: note: expanded from macro 'TRACE_POSTGRESQL_QUERY_REWRITE_START' __dtrace_postgresql___query__rewrite__start(arg0) ../../../src/include/utils/probes.h:755:63: note: passing argument to parameter here extern void __dtrace_postgresql___query__rewrite__start(char *); postgres.c:670:38: warning: passing 'const char *' to parameter of type 'char *' discards qualifiers [-Wincompatible-pointer-types-discards-qualifiers] TRACE_POSTGRESQL_QUERY_REWRITE_DONE(query_string); ../../../src/include/utils/probes.h:343:45: note: expanded from macro 'TRACE_POSTGRESQL_QUERY_REWRITE_DONE' __dtrace_postgresql___query__rewrite__done(arg0) ../../../src/include/utils/probes.h:749:62: note: passing argument to parameter here extern void __dtrace_postgresql___query__rewrite__done(char *); ^ postgres.c:845:31: warning: passing 'const char *' to parameter of type 'char *' discards qualifiers [-Wincompatible-pointer-types-discards-qualifiers] TRACE_POSTGRESQL_QUERY_START(query_string); ../../../src/include/utils/probes.h:361:37: note: expanded from macro 'TRACE_POSTGRESQL_QUERY_START' __dtrace_postgresql___query__start(arg0) ../../../src/include/utils/probes.h:761:54: note: passing argument to parameter here extern void __dtrace_postgresql___query__start(char *); postgres.c:1130:30: warning: passing 'const char *' to parameter of type 'char *' discards qualifiers
Disable FIFO on UART
Hi! Back in FreeBSD 7 there was a flag to disable the FIFO on the sio device driver. From http://www.freebsd.org/cgi/man.cgi?query=sioapropos=0sektion=0manpath=FreeBSD+7.4-stablearch=defaultformat=html: Meaning of flags: 0x1 shared IRQs 0x2 disable FIFO 0x4 no AST/4 compatible IRQ control register 0x8 recover sooner from lost output interrupts 0x00010 device is potential system console 0x00020 device is forced to become system console 0x00040 device is reserved for low-level IO (e.g. for remote kernel debugging) 0x00080 use this port for remote kernel debugging 0x0??00 minor number of master port 0x1 PPS timestamping on CTS instead of DCD 0x2 device is assumed to use a 16650A-type (extended FIFO) chip Now with FreeBSD 8 which uses the UART device driver there's no option for that. I am looking to reduce the jitter I am getting on the serial port when connecting a GPS to the server. Can anyone help? Regards, Miguel ___ 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: ZFS on MBR does not boot at all
On Mon, 29 Apr 2013 13:29:18 +0200, David Demelier demelier.da...@gmail.com wrote: 2013/4/18 David Demelier demelier.da...@gmail.com: Hello, I would like to use ZFS over MBR for multiboot purposes. I've followed that guide https://wiki.freebsd.org/RootOnZFS/ZFSBootPartition but it does not boot at all. The loader does not show up after choosing FreeBSD in the boot0 loader. The _ prompt appears but nothing starts. I've found many people over the web having the same problem but unfortunately no one found a solution. I think the offensive commands are ones with dd and zfsboot. Regards, So someone told me on IRC that the main problem was that I've put my partition swap as first partition in the FreeBSD slice and zfsboot *requires* that the zfs partition is the first. Can someone with right access to the wiki page may add a notice about this issue on https://wiki.freebsd.org/RootOnZFS/ZFSBootPartition please? Hi David, Thanks for following up with what the real problem was. I updated the Wiki to include this: Note that partition order is important. It seems that zfsboot requires the freebsd-zfs partition to be the first, so make sure you add if first, before your swap partition. Cheers, Giorgos pgpAGlS_lM5GA.pgp Description: PGP signature
Re: ZFS on MBR does not boot at all
On 5/5/2013 3:20 PM, Giorgos Keramidas wrote: Hi David, Thanks for following up with what the real problem was. I updated the Wiki to include this: Note that partition order is important. It seems that zfsboot requires the freebsd-zfs partition to be the first, so make sure you add if first, before your swap partition. Cheers, Giorgos What? I've been using this set up for years. = 34 976773101 ada1 GPT (465G) 34128 1 freebsd-boot (64k) 1628388608 2 freebsd-swap (4.0G) 8388770 968384365 3 freebsd-zfs (461G) = 34 976773101 ada2 GPT (465G) 34128 1 freebsd-boot (64k) 1628388608 2 freebsd-swap (4.0G) 8388770 968384365 3 freebsd-zfs (461G) ___ 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
