Re: [autofs] problems with "dirty" UFS2 partitions
In message <20170808071758.6a815...@freyja.zeit4.iv.bundesimmobilien.de>, "O. H artmann" writes: > Hello, > > we're running a NanoBSD based appliance which resides on a small SoC and > utilises a mSATA SSD for logging, database storage and mail folder. The > operating system is recent CURRENT as it is still under development. > > The problem ist, that from time to time, without knowing or seeing the reason > , > the automounted partitions become "dirty (UFS2 partitions, no ZFS dur to > memory and performance limitations). Journaling is enbaled. > > When the partitions on the SSD become "dirty", logging or accessing them isn' > t > possible anymore and for some reason I do not see any log entries reporting > this (maybe due to the fact all logs are going also to that disk since the lo > gs > would pollute the serial console/console and the console is used for > maintenance purposes/ssh terminal). > > Is it possible to - automated! - check the filesystem on bootup? As on ordina > ry > FreeBSD systems with fstab-based filesystems, this happens due to the > rc-init-infrastructure but autofs filesystems seem to be somehow standing asi > de > from this procedure. I'd be interested in finding out if your system either panicked or simply failed to unmount the filesystems in question during a boot or shutdown. Is the SSD being removed prior to FreeBSD having the chance to unmount it? I think if we answer These questions we're more than half way there. Warner has a good suggestion worth considering. Another option might be to use amd program maps. The program map being a program or script that would run fsck prior to issuing a mount. Having said that, this treats the symptom rather than addressing the cause. It's preferred to discover the cause so that autofs (or amd) can mount a clean filesystem. -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [tzsetup] can't set up local timezone if CMOS is set to UTC
On Mon, Aug 7, 2017 at 2:48 PM, Marius Strobl wrote: > On Mon, Aug 07, 2017 at 09:51:15AM +0300, Boris Samorodov wrote: > > 07.08.2017 09:44, Boris Samorodov ?: > > > Hi Marius, All, > > > > > > Subj at today's amd64-HEAD. If I use command "sudo tzsetup" and > > > choose YES (CMOS clock is set to UTC), the program just quits. > > > Yea, my clocks are at UTC but I want to get time at local timezone. :-) > > > > > > I've found a recent commit to tzsetup, is it the cause? > > > > Hm. There is a log message at r322097: > > --- > > - Make the initial UTC dialog actually work by giving the relevant files > >the necessary treatment and then exit when choosing "Yes" there > instead > >of moving on to the time zone menu regardless. > > --- > > > > I must misunderstand something. > > > > So my question is: how to set up local time zone if CMOS is set to UTC? > > Yeah, I hadn't thought of the case where one would like to set up > a configuration in which the RTC is using UTC but the timezone is > not. So I've reverted the corresponding part of r322097 for now as > I don't see an obvious way to give /etc/wall_cmos_clock appropriate > treatment in all 3 relevant cases (UTC/UTC, !UTC/UTC and !UTC/!UTC > regarding RTC/timezone) for all interactive and non-interactive > ways of using tzsetup(8). > > Marius Thanks for the quick fix, Marius. FWIW, it the system is not running Windows (dual boot), it has long been standard BSD practice to set the RTC to UTC and then set the timezone to local time. I've seen this back to the days of at least BSD4.3 (NOT FreeBSD) but 20 or more years ago. I have worked at two places with hundreds of systems, all running this way, including all of "my" systems. The practice of setting RTC on Unix-only platforms to local time really started with dual-boot systems, especially Windows. (I first saw this on a BSD Unix/VMS dual boot system.) -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [autofs] problems with "dirty" UFS2 partitions
On Mon, Aug 7, 2017 at 11:17 PM, O. Hartmann wrote: > Hello, > > we're running a NanoBSD based appliance which resides on a small SoC and > utilises a mSATA SSD for logging, database storage and mail folder. The > operating system is recent CURRENT as it is still under development. > > The problem ist, that from time to time, without knowing or seeing the > reason, > the automounted partitions become "dirty (UFS2 partitions, no ZFS dur to > memory and performance limitations). Journaling is enbaled. > > When the partitions on the SSD become "dirty", logging or accessing them > isn't > possible anymore and for some reason I do not see any log entries reporting > this (maybe due to the fact all logs are going also to that disk since the > logs > would pollute the serial console/console and the console is used for > maintenance purposes/ssh terminal). > > Is it possible to - automated! - check the filesystem on bootup? As on > ordinary > FreeBSD systems with fstab-based filesystems, this happens due to the > rc-init-infrastructure but autofs filesystems seem to be somehow standing > aside > from this procedure. > Can't you just list them in /etc/fstab with the noauto option, but with a non-zero number listed in the 'pass' number column? I know nanobsd doesn't generate things this way, but maybe it should Warner ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
[autofs] problems with "dirty" UFS2 partitions
Hello, we're running a NanoBSD based appliance which resides on a small SoC and utilises a mSATA SSD for logging, database storage and mail folder. The operating system is recent CURRENT as it is still under development. The problem ist, that from time to time, without knowing or seeing the reason, the automounted partitions become "dirty (UFS2 partitions, no ZFS dur to memory and performance limitations). Journaling is enbaled. When the partitions on the SSD become "dirty", logging or accessing them isn't possible anymore and for some reason I do not see any log entries reporting this (maybe due to the fact all logs are going also to that disk since the logs would pollute the serial console/console and the console is used for maintenance purposes/ssh terminal). Is it possible to - automated! - check the filesystem on bootup? As on ordinary FreeBSD systems with fstab-based filesystems, this happens due to the rc-init-infrastructure but autofs filesystems seem to be somehow standing aside from this procedure. Thanks in advance, Oliver ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [tzsetup] can't set up local timezone if CMOS is set to UTC
On Mon, Aug 07, 2017 at 09:51:15AM +0300, Boris Samorodov wrote: > 07.08.2017 09:44, Boris Samorodov ?: > > Hi Marius, All, > > > > Subj at today's amd64-HEAD. If I use command "sudo tzsetup" and > > choose YES (CMOS clock is set to UTC), the program just quits. > > Yea, my clocks are at UTC but I want to get time at local timezone. :-) > > > > I've found a recent commit to tzsetup, is it the cause? > > Hm. There is a log message at r322097: > --- > - Make the initial UTC dialog actually work by giving the relevant files >the necessary treatment and then exit when choosing "Yes" there instead >of moving on to the time zone menu regardless. > --- > > I must misunderstand something. > > So my question is: how to set up local time zone if CMOS is set to UTC? Yeah, I hadn't thought of the case where one would like to set up a configuration in which the RTC is using UTC but the timezone is not. So I've reverted the corresponding part of r322097 for now as I don't see an obvious way to give /etc/wall_cmos_clock appropriate treatment in all 3 relevant cases (UTC/UTC, !UTC/UTC and !UTC/!UTC regarding RTC/timezone) for all interactive and non-interactive ways of using tzsetup(8). Marius ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Would O_APPEND for /dev/null be possible?
I can open a file with "a+", which, for this software, means "O_RDWR | O_APPEND | O_CREAT | n_O_NOFOLLOW" on Linux, Solaris and OpenBSD, but FreeBSD complains, i think because O_APPEND. (I think only because the VM does not survive resumes and other pauses here, which frustrated me over time. It is old VM.) I mean, it seems i have to sprinkle more /dev/null string comparisons all over the place, but i wonder whether that really belongs there.. for /dev/null? Well, now that i am here. I have installed pcc and tcc ports because clang is much too slow, especially in VM, but they cannot be used because of mysterious attributes in some system header. I usually compile them on my own, but that did not help on FreeBSD too, at least not last time i tried. This is a bit of a pity, i have not tried it myself but one of the core developers of the tiny CC, who was part of ELF development, said, once that happened, that he made it compile the Linux kernel (!) again and "that seems to work", so it is a *real* pity that not even rather primitive C89 user programs can be compiled (with those compilers). That on v11.1, and with pkg stuff. Ciao! --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [tzsetup] can't set up local timezone if CMOS is set to UTC
07.08.2017 10:54, Trond Endrestøl пишет: On Mon, 7 Aug 2017 09:51+0300, Boris Samorodov wrote: So my question is: how to set up local time zone if CMOS is set to UTC? My timezone is Europe/Oslo, adjust to fit your timezone: rm -f /etc/wall_cmos_clock cp -p /usr/share/zoneinfo/Europe/Oslo /etc/localtime echo Europe/Oslo > /var/db/zoneinfo Done. Got UTC time marked as local time. (Five minutes later) Ntpdate fixed it, now local time is OK. Thank you, Trond. And (seems to be) the final question: can that be done via tzsetup (as it used to be)? -- WBR, Boris Samorodov (bsam) FreeBSD Committer, http://www.FreeBSD.org The Power To Serve ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [tzsetup] can't set up local timezone if CMOS is set to UTC
On Mon, 7 Aug 2017 09:51+0300, Boris Samorodov wrote: > So my question is: how to set up local time zone if CMOS is set to UTC? My timezone is Europe/Oslo, adjust to fit your timezone: rm -f /etc/wall_cmos_clock cp -p /usr/share/zoneinfo/Europe/Oslo /etc/localtime echo Europe/Oslo > /var/db/zoneinfo -- Trond. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [tzsetup] can't set up local timezone if CMOS is set to UTC
07.08.2017 09:44, Boris Samorodov пишет: Hi Marius, All, Subj at today's amd64-HEAD. If I use command "sudo tzsetup" and choose YES (CMOS clock is set to UTC), the program just quits. Yea, my clocks are at UTC but I want to get time at local timezone. :-) I've found a recent commit to tzsetup, is it the cause? Hm. There is a log message at r322097: --- - Make the initial UTC dialog actually work by giving the relevant files the necessary treatment and then exit when choosing "Yes" there instead of moving on to the time zone menu regardless. --- I must misunderstand something. So my question is: how to set up local time zone if CMOS is set to UTC? -- WBR, Boris Samorodov (bsam) FreeBSD Committer, http://www.FreeBSD.org The Power To Serve ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
[tzsetup] can't set up local timezone if CMOS is set to UTC
Hi Marius, All, Subj at today's amd64-HEAD. If I use command "sudo tzsetup" and choose YES (CMOS clock is set to UTC), the program just quits. Yea, my clocks are at UTC but I want to get time at local timezone. :-) I've found a recent commit to tzsetup, is it the cause? -- WBR, Boris Samorodov (bsam) FreeBSD Committer, http://www.FreeBSD.org The Power To Serve ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
