Fwd: test sent date details
All the best Keith Bainbridge keithr...@gmail.com keith.bainbridge.3...@gmail.com +61 (0)447 667 468 UTC + 10:00 Forwarded Message Subject: test sent date details Date: Tue, 18 Jun 2024 17:56:41 +1000 From: Keith Bainbridge To: keithr...@gmail.com All the best Keith Bainbridge keith.bainbridge.3...@gmail.com +61 (0)447 667 468 UTC + 10:00
Re: test sent date details
It has worked All the best Keith Bainbridge keithr...@gmail.com keith.bainbridge.3...@gmail.com +61 (0)447 667 468 UTC + 10:00 On 18/6/24 17:56, Keith Bainbridge wrote: All the best Keith Bainbridge keith.bainbridge.3...@gmail.com +61 (0)447 667 468 UTC + 10:00
Re: info vs. man (was: Re: date for week)
On Tue, Jun 11, 2024 at 11:22:17PM +0700, Max Nikulin wrote: > On 11/06/2024 06:45, Greg Wooledge wrote: > > Should you ever feel a need to read the longer version of the > > documentation, it's in GNU info pages. So you would need to type > > the command "info coreutils date" to get to it. And then you'd need > > to figure out the user interface of the "info" program, which is not > > intuitive unless you happen to be an emacs power user already. > > Emacs power users can type > M-x info RET > or > M-: (info "(coreutils) date conversion specifiers") RET > or at least > emacs -f info-standalone '(coreutils) date conversion specifiers' > > I do not mind that info browsers have usability issues. For beginners I > would recommend tkinfo instead of terminal "info". I have not tried pinfo. > > Texinfo, unlike man, has a notion of hyperlink. In the case of man it is > just formatting that suggests that some part of text is a reference to > another document or another section. See, this is all fine -- you've searched for the appropriate section, and you've generated a cryptic command that someone else could type inside emacs to get to that same section. I'm sure there's an "info" equivalent that can be done from a shell without invoking emacs. None of that's useful to a person who wants to search for that information in the first place without consulting an expert who's already done the work. What I was trying to do in my reply was "teach them how to fish" -- to show them how to bring up the man page themselves, and look for basic information like "how do I get the name of the day of the week, instead of the numeric index of the day of the week" without having to bother an international mailing list. So, I gave basic instructions for how to bring up the man page, and a hint about searching for a key word related to their question. I even provided a small piece of the man page, which happens to include the answer they're looking for, because I'm also a pessimist who knows that they probably won't look it up themselves, and may become angry if we don't spoon-feed them the actual answer. I also provided a reference to the info page, and a command that would bring that up, should the need ever arise. More importantly, I revealed that info pages *exist* and *are a thing* that they need to know about. It's planting a seed for the future.
info vs. man (was: Re: date for week)
On 11/06/2024 06:45, Greg Wooledge wrote: Should you ever feel a need to read the longer version of the documentation, it's in GNU info pages. So you would need to type the command "info coreutils date" to get to it. And then you'd need to figure out the user interface of the "info" program, which is not intuitive unless you happen to be an emacs power user already. Emacs power users can type M-x info RET or M-: (info "(coreutils) date conversion specifiers") RET or at least emacs -f info-standalone '(coreutils) date conversion specifiers' I do not mind that info browsers have usability issues. For beginners I would recommend tkinfo instead of terminal "info". I have not tried pinfo. Texinfo, unlike man, has a notion of hyperlink. In the case of man it is just formatting that suggests that some part of text is a reference to another document or another section. It was created for "online" version of printed manuals. Info is more convenient for navigation in long document and makes it easier to specify a particular section. In the case of man it requires some tricks like man -P 'less -p %a' date
Re: date for week
thanks roberto. that's exactly what i am looking for. $ date +%a
Re: date for week
On Tue, Jun 11, 2024 at 07:19:42AM +0800, Jeff Peng wrote: > While I expect the output should be: > > $ date +%such_a_option > Tuesday > > or > $ date +%such_a_option > Tue > > does date command has this option? You can run the command "man date" to read the short version of the documentation. This will include the information you wanted. Search for "week" and it takes you right there: %a locale's abbreviated weekday name (e.g., Sun) %A locale's full weekday name (e.g., Sunday) %b locale's abbreviated month name (e.g., Jan) %B locale's full month name (e.g., January) %c locale's date and time (e.g., Thu Mar 3 23:05:25 2005) Should you ever feel a need to read the longer version of the documentation, it's in GNU info pages. So you would need to type the command "info coreutils date" to get to it. And then you'd need to figure out the user interface of the "info" program, which is not intuitive unless you happen to be an emacs power user already.
Re: date for week
All the format codes are documented in the man page for date. in particular: +%a gives a short form, such as Mon +%A gives full name, e.g. Monday +%^a and +%^A as above, but all capital letters. - Original Message - From: "Jeff Peng" To: "debian-user" > While I expect the output should be: > $ date +%such_a_option > Tuesday > or > $ date +%such_a_option > Tue > does date command has this option? Yes, see above. -- Bob Netzlof a/k/a Sweet Old Bob
Re: date for week
On Tue, Jun 11, 2024 at 07:19:42AM +0800, Jeff Peng wrote: > Hello, > > I run the folllowing command, > > $ date +%w > 2 > > > While I expect the output should be: > > $ date +%such_a_option > Tuesday > > or > $ date +%such_a_option > Tue > > does date command has this option? > > Thanks. > You probably want: $ date +%a Mon $ date +%A Monday -- Roberto C. Sánchez
date for week
Hello, I run the folllowing command, $ date +%w 2 While I expect the output should be: $ date +%such_a_option Tuesday or $ date +%such_a_option Tue does date command has this option? Thanks.
Yet another lick at Gmail and Google [was: Debian 12.5 up-to-date Xfce, Firefox clings to USB stick]
On Tue, Apr 16, 2024 at 01:39:34PM -, Curt wrote: [...] > It would've been clearer to have advised using another mail application, > period [...] > But no harm, no foul, and all is well. The only real mystery is how > Tomas resisted getting yet another lick in against Gmail and Google, et > al. Because it'd been off-topic, just as your little oblique stab here is ;-D Cheers -- t signature.asc Description: PGP signature
Re: Debian 12.5 up-to-date Xfce, Firefox clings to USB stick
On 2024-04-16, John Crawley wrote: > > If you do not trust Gmail as a web application, use a mail application > that supports IMAP. > Gmail supports IMAP since more or less forever. >>> >>> AIUI the OP's problem was not when reading mail, but with mail >>> submission of attachments. >> >> And in what way does that affect a true statement and a phraseology that >> clearly implies an nonexistent incompatibility? > > Loosen the interpretation of Max Nikulin's statement slightly: > "If you do not trust Gmail as a web application, use any mail application > that supports IMAP" > and it makes sense. > I've just loosened it.
Re: Debian 12.5 up-to-date Xfce, Firefox clings to USB stick
On 2024-04-16, Max Nikulin wrote: > > If you do not trust Gmail as a web application, use a mail application > that supports IMAP. Gmail supports IMAP since more or less forever. >>> >>> AIUI the OP's problem was not when reading mail, but with mail >>> submission of attachments. >> >> And in what way does that affect a true statement and a phraseology that >> clearly implies an nonexistent incompatibility? > > I am completely lost. Mail messages (with attachments) may be submitted It would've been clearer to have advised using another mail application, period, if the OP didn't trust Gmail. But the manner in which you phrased your advice implied that Gmail was a "web application" that didn't support IMAP, which is false, so I piped up (or is it in?) in my admittedly somewhat oblique (to the matter at hand) manner. But no harm, no foul, and all is well. The only real mystery is how Tomas resisted getting yet another lick in against Gmail and Google, et al. --
Re: Debian 12.5 up-to-date Xfce, Firefox clings to USB stick
On Mon 15 Apr 2024 at 18:52:33 (-), Curt wrote: > On 2024-04-15, David Wright wrote: > > On Sun 14 Apr 2024 at 14:24:29 (-), Curt wrote: > >> On 2024-04-04, Max Nikulin wrote: > >> > > >> > If you do not trust Gmail as a web application, use a mail application > >> > that supports IMAP. > >> > > >> > >> Gmail supports IMAP since more or less forever. > > > > AIUI the OP's problem was not when reading mail, but with mail > > submission of attachments. > > And in what way does that affect a true statement and a phraseology that > clearly implies an nonexistent incompatibility? It doesn't, and wasn't intended to. The OP was worried about security of the attachment process during mail submission. IMAP is not involved. I'm told that gmail offers an SMTP interface, but I don't know how well it works, or its pros and cons. That's why I wrote "the OP's problem was … with mail submission …", in case that had got forgotten with the thread drifting across to the topic of reading emails. Clearer? Cheers, David.
Re: Debian 12.5 up-to-date Xfce, Firefox clings to USB stick
On 16/04/2024 01:52, Curt wrote: On 2024-04-15, David Wright wrote: On Sun 14 Apr 2024 at 14:24:29 (-), Curt wrote: On 2024-04-04, Max Nikulin wrote: If you do not trust Gmail as a web application, use a mail application that supports IMAP. Gmail supports IMAP since more or less forever. AIUI the OP's problem was not when reading mail, but with mail submission of attachments. And in what way does that affect a true statement and a phraseology that clearly implies an nonexistent incompatibility? I am completely lost. Mail messages (with attachments) may be submitted to gmail using SMTP. Certainly it is possible to use different applications to read and to send mails, but by default I assume that users seek for a complete solution. I had a hope that my suggestion to use some mail user agent that support IMAP was clear enough. I expect that most of them (at least wide spread) support submission of mail as well. Use code you trust and protocols having specifications available. I admit that some users have troubles with OAuth2 authentication in various MUAs or with enabling application-specific passwords for their google account.
Re: Debian 12.5 up-to-date Xfce, Firefox clings to USB stick
On 16/04/2024 03:52, Curt wrote: On 2024-04-15, David Wright wrote: On Sun 14 Apr 2024 at 14:24:29 (-), Curt wrote: On 2024-04-04, Max Nikulin wrote: If you do not trust Gmail as a web application, use a mail application that supports IMAP. Gmail supports IMAP since more or less forever. AIUI the OP's problem was not when reading mail, but with mail submission of attachments. And in what way does that affect a true statement and a phraseology that clearly implies an nonexistent incompatibility? Loosen the interpretation of Max Nikulin's statement slightly: "If you do not trust Gmail as a web application, use any mail application that supports IMAP" and it makes sense. -- John
Re: Debian 12.5 up-to-date Xfce, Firefox clings to USB stick
On 2024-04-15, David Wright wrote: > On Sun 14 Apr 2024 at 14:24:29 (-), Curt wrote: >> On 2024-04-04, Max Nikulin wrote: >> > >> > If you do not trust Gmail as a web application, use a mail application >> > that supports IMAP. >> > >> >> Gmail supports IMAP since more or less forever. > > AIUI the OP's problem was not when reading mail, but with mail > submission of attachments. And in what way does that affect a true statement and a phraseology that clearly implies an nonexistent incompatibility? > Cheers, > David. > > --
Re: Debian 12.5 up-to-date Xfce, Firefox clings to USB stick
On Sun 14 Apr 2024 at 14:24:29 (-), Curt wrote: > On 2024-04-04, Max Nikulin wrote: > > > > If you do not trust Gmail as a web application, use a mail application > > that supports IMAP. > > > > Gmail supports IMAP since more or less forever. AIUI the OP's problem was not when reading mail, but with mail submission of attachments. Cheers, David.
Re: Debian 12.5 up-to-date Xfce, Firefox clings to USB stick
On 2024-04-04, Max Nikulin wrote: > > If you do not trust Gmail as a web application, use a mail application > that supports IMAP. > Gmail supports IMAP since more or less forever.
Re: Debian 12.5 up-to-date Xfce, Firefox clings to USB stick
On 31/03/2024 22:35, David Wright wrote: On Sun 31 Mar 2024 at 09:42:37 (+0300), Antti-Pekka Känsälä wrote: But I'm worried my Gmail in Firefox is capable of stealing files off my USB stick. I've no answer for that, particularly in view of Max's reply to my previous post. I've always copied files to and from USB sticks, floppy disks, CDs, etc), using the hard disk as a staging area. I think, it is a reasonable approach when combined with other measures. Frankly speaking, I am not convinced that there is something weird with Gmail and Firefox. If you do not trust Gmail as a web application, use a mail application that supports IMAP. Isolate applications you do not trust and do not expose your private files to them. There is a number of possibilities, but neither is perfect: - multiple system users and file permissions combined with ACLs - virtual machines - mount, user and other namespaces, e.g. the following options - containers - tools like firejail and bubblewrap - flatpak and snap (designed for some kind of isolation, but I am unsure if it may be configured to specific needs) Mount a USB drive to a trusted environment and copy specific files to a location available to a suspicious application.
Re: Debian 12.5 up-to-date Xfce, Firefox clings to USB stick
I filed bug report 1068122. I feel fine, despite my concern over my data. Heartfelt thanks for all the advice!
Re: Debian 12.5 up-to-date Xfce, Firefox clings to USB stick
On Sun 31 Mar 2024 at 09:42:37 (+0300), Antti-Pekka Känsälä wrote: > I'm mounting and unmounting through the stick icon's menu on Xfce desktop. > Maybe a fancy file chooser dialogue stays around analyzing the directory, > as you suspect? But I'm worried my Gmail in Firefox is capable of stealing > files off my USB stick. I've no answer for that, particularly in view of Max's reply to my previous post. I've always copied files to and from USB sticks, floppy disks, CDs, etc), using the hard disk as a staging area. That habit developed thirty years ago on account of (other's) experience with Windows, and the "stickiness" of its file choosers. This could lead to problems when you attempted to renavigate to files, but hadn't got the same devices plugged in as previously. That's not much help to you because by doing that, you'd merely be exposing your hard drive instead for analysis, to Firefox, or worse, possibly to Gmail. I run two instances of Firefox as a matter of course. One user's instance is used for banking and other administrative tasks. The other user's is for everything else. The latter is unable to read any of the former's files. (Some people use different machines to the same end.) Cheers, David.
Re: Re: Debian 12.5 up-to-date Xfce, Firefox clings to USB stick
I'm mounting and unmounting through the stick icon's menu on Xfce desktop. Maybe a fancy file chooser dialogue stays around analyzing the directory, as you suspect? But I'm worried my Gmail in Firefox is capable of stealing files off my USB stick.
Re: Debian 12.5 up-to-date Xfce, Firefox clings to USB stick
On 31/03/2024 11:46, David Wright wrote: Double-clicking on the directory mounts it and displays the files in it. Opening a text file displays it. At least for a small file, FF does not hold the file open, so I can immediately unmount the stick. Gmail may do something more fancy - https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/file - https://developer.mozilla.org/en-US/docs/Web/API/File_System_API I am not surprised that the device is busy for some interval of time.
Re: Debian 12.5 up-to-date Xfce, Firefox clings to USB stick
On Sat 30 Mar 2024 at 21:06:27 (+0200), Antti-Pekka Känsälä wrote: > I was able to replicate this, by trying to send gmail to myself in Firefox, > attaching a binary on a mounted USB stick. Did you mount the stick yourself as a user (ie there's an fstab entry for it), or as root, or does an automounter mount it for you? > After the attachment supposedly > was uploaded, I tried to unmount the stick, but it blocks. "lsof | grep -i > KINGSTON" then shows a total of 129 lines from "x-www-browser". This lasted > for about a minute, then the drive unmounted by itself. This is the behaviour I see, where (1) inserting a stick creates a mountpoint and (2) that mountpoint is referenced in /etc/fstab: After typing Ctrl-O in Firefox, I navigate to /media/foo (the mountpoint that was created). Double-clicking on the directory mounts it and displays the files in it. Opening a text file displays it. At least for a small file, FF does not hold the file open, so I can immediately unmount the stick. That may differ if, for example, a mail MUA or MTA is taking a lot of time to process an attached file. So I suspect you may be relying on an automounter to mount the stick, and you have to wait for a period of inactivity to time out before it decides you've probably finished with it. Cheers, David.
Re: Debian 12.5 up-to-date Xfce, Firefox clings to USB stick
On 3/30/24 08:17, Antti-Pekka Känsälä wrote: What could be the deal, when Firefox tries to stop me from unmounting a stick, after I've accessed files on it through Firefox? I worry about my stick security. Thanks. Linux knows what files are open on each file system. If you try to unmount a file system with open files or eject a mounted USB drive with open files, Linux will refuse and your desktop environment will display a suitable error dialog. This is a feature, not a bug. The solution is to close all the files on the file system, and then unmount it. David
Re: Re: Re: Debian 12.5 up-to-date Xfce, Firefox clings to USB stick
I'd just like to add that I have seen the problem despite reinstalls with Debian stable minor versions. Thanks!
Re: Re: Debian 12.5 up-to-date Xfce, Firefox clings to USB stick
On Sat, Mar 30, 2024 at 07:32:16PM +0200, Antti-Pekka Känsälä wrote:
> Yes, closing Firefox does allow the stick to unmount cleanly, but I still
> worry.
To get an idea of what's going on, you can use "lsof":
tomas@trotzki:~$ lsof /dev/sda1
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
bash3982 tomas cwdDIR8,1 40962 /boot
hexdump 4056 tomas0r REG8,1 33464584 28
/boot/initrd.img-5.10.0-26-amd64
hexdump 4074 tomas0r REG8,1 7044672 27
/boot/vmlinuz-5.10.0-26-amd64
There are three processes accessing my /dev/sda1 ("aka" /boot). I put
them there to have something to show :-)
Cheers
--
t
signature.asc
Description: PGP signature
Re: Re: Debian 12.5 up-to-date Xfce, Firefox clings to USB stick
I can replicate this, by trying to send Gmail to myself in Firefox, attaching a binary on a mounted USB stick. After the attachment supposedly was uploaded, I tried to unmount the stick, but it blocked. "lsof | grep -i KINGSTON" then shows a total of 129 lines from "x-www-browser". This lasted for about a minute, then the drive unmounted by itself.
Re: Re: Debian 12.5 up-to-date Xfce, Firefox clings to USB stick
I was able to replicate this, by trying to send gmail to myself in Firefox, attaching a binary on a mounted USB stick. After the attachment supposedly was uploaded, I tried to unmount the stick, but it blocks. "lsof | grep -i KINGSTON" then shows a total of 129 lines from "x-www-browser". This lasted for about a minute, then the drive unmounted by itself.
Re: Debian 12.5 up-to-date Xfce, Firefox clings to USB stick
On Sat, 30 Mar 2024 17:17:52 +0200 Antti-Pekka Känsälä wrote: > What could be the deal, when Firefox tries to stop me from unmounting > a stick, after I've accessed files on it through Firefox? I worry > about my stick security. Thanks. It sounds like Firefox has a file open on the stick. To check this, run something like lsof | grep -i offsite where offsite is in the path to the stick. -- Does anybody read signatures any more? https://charlescurley.com https://charlescurley.com/blog/
Re: Debian 12.5 up-to-date Xfce, Firefox clings to USB stick
On Sat, Mar 30, 2024 at 1:19 PM gene heskett wrote: > > On 3/30/24 11:36, Antti-Pekka Känsälä wrote: > > What could be the deal, when Firefox tries to stop me from unmounting a > > stick, after I've accessed files on it through Firefox? I worry about > > my stick security. Thanks. > > Since this is normally a root operation, I'm confused. Likely what it > means is that you have an open write path from firefox to the stick that > has not been properly closed. I get into a similar state working with > u-sd's using mc to edit something I have used mc to cd to, and forget to > cd back out of the u-sd before I eject the card to take it to its proper > home in a pi clone. Possibly fixed by stopping firefox first? The other thing I try with this is to run something like: $ mount|grep sda2 The "sda2" can be replaced with whatever else is involved. That filters out a hopefully small(er) list to show if something is unusually mounted. Running "mount" alone opens up the whole list. Going that route helped me in chroot a couple days ago. An unbelievable number of /proc, /sys, /dev, and /dev/pts mount points appeared. I only manually mounted them once each. Manually umount'ing each point until none were left fixed whatever trouble that seemed to inflict on apt-get. Cindy :) -- Cindy-Sue Causey Talking Rock, Pickens County, Georgia, USA * runs with birdseed *
Re: Re: Debian 12.5 up-to-date Xfce, Firefox clings to USB stick
Yes, closing Firefox does allow the stick to unmount cleanly, but I still worry.
Re: Debian 12.5 up-to-date Xfce, Firefox clings to USB stick
On 3/30/24 11:36, Antti-Pekka Känsälä wrote: What could be the deal, when Firefox tries to stop me from unmounting a stick, after I've accessed files on it through Firefox? I worry about my stick security. Thanks. Since this is normally a root operation, I'm confused. Likely what it means is that you have an open write path from firefox to the stick that has not been properly closed. I get into a similar state working with u-sd's using mc to edit something I have used mc to cd to, and forget to cd back out of the u-sd before I eject the card to take it to its proper home in a pi clone. Possibly fixed by stopping firefox first? Cheers, Gene Heskett, CET. -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author, 1940) If we desire respect for the law, we must first make the law respectable. - Louis D. Brandeis
Debian 12.5 up-to-date Xfce, Firefox clings to USB stick
What could be the deal, when Firefox tries to stop me from unmounting a stick, after I've accessed files on it through Firefox? I worry about my stick security. Thanks.
Re: chrony date months off
On 1/31/24 21:50, Max Nikulin wrote: On 31/01/2024 20:24, didar wrote: On Wed, Jan 31, 2024 at 05:32:26AM -0500, gene heskett wrote: How do I setup /etc/chrony/chrony.conf so it slams the system clock to the current time on the first cycle as its rebooting? There was 20 yeas back, an ntpdate command that would do that. You can use "rdate" (openrdate) as quick fix like `ntpdate'. Is there a real reason to install an extra package if chrony provides a tool similar to ntpdate? If I recall it right, the reason why chrony appeared here was just $ man timesyncd No manual entry for timesyncd If it is that box with armbian modified by a Chinese 3d printer vendor then I am surprised that, intended for boards without RTC, it does not have proper NTP setup out of the box. Despite I expect arbitrary peculiarities in this kind of a Linux distribution, I still believe that NTP troubles were caused by user actions. I'd argue that in the bigger picture, the edge distributions, some of which are one man operations or very close to it, like armbian, know these are often used in offline environments where it is not that important. But the minute you plug in the cat-# it is a different story. We are doing things with baby arm's that would normally take a 6 core i5 to do, but doing it 1/4 as fast and on only 5% of the power. That fast enough to get the job done, but lack of attention to what s/b just works stuff says bad code is still bad code. I'm finally understanding things the man pages will never tell you, about interdependentcy's. Once you begin to understand how timedatectl actually works, it all falls into place and just works. My goal in much of this is to reduce my visibility on the net, so I now have only a one machine loading at pool.debian.org, instead of 5, soon to be 7. This machine has the power to be a server, so it now has a dhcpd server, specially configured to answer only one mac address, just to give an X-Max3 printer its hostname and net address. I am also an ntp server, stratum 2, for the use of the rest of the machines on my local net. Yet each and every one has full net access. With dd-wrt standing guard. I have only one registered address you can ping. My original 20 gigabyte web page is down, left with the death of those 2 seacrate 2T's in less than 30 days service about 2 days apart. But when it comes back it will be to support a woodworkers big bench vice I have designed, the screw is about 50mm by 500mm in hard maple, buttress thread, the reminder of it is printed in PETG for its resilience. Stronger grip than anything you can get on ebay. With one bigger printer, it takes about a day on the milling machine for the screw, but 2+ weeks for the rest of the parts for a single screw. That's why the push to build a (presently 3 bigger printers, was 4 till I lost the printheads umbilical cable on a creality e5-s1 and it is not a service part) farm. Take care & stay well Max. Cheers, Gene Heskett, CET. -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author, 1940) If we desire respect for the law, we must first make the law respectable. - Louis D. Brandeis
Re: chrony date months off
On 31/01/2024 20:24, didar wrote: On Wed, Jan 31, 2024 at 05:32:26AM -0500, gene heskett wrote: How do I setup /etc/chrony/chrony.conf so it slams the system clock to the current time on the first cycle as its rebooting? There was 20 yeas back, an ntpdate command that would do that. You can use "rdate" (openrdate) as quick fix like `ntpdate'. Is there a real reason to install an extra package if chrony provides a tool similar to ntpdate? If I recall it right, the reason why chrony appeared here was just $ man timesyncd No manual entry for timesyncd If it is that box with armbian modified by a Chinese 3d printer vendor then I am surprised that, intended for boards without RTC, it does not have proper NTP setup out of the box. Despite I expect arbitrary peculiarities in this kind of a Linux distribution, I still believe that NTP troubles were caused by user actions.
Re: chrony date months off
Darac Marjal wrote: > >The script works like this: if the root device is specified on the >kernel command line AND the word "fixrtc" is specified, then get the >time that the root file system was last mounted. The script then uses >"date" to set the clock to that date stamp. > >I assume that the idea is that, rather than having the clock start at >1970, it's better to start it at, say, yesterday. You've still got quite >a lot of slewing to do if you connect to NTP, but at least there's a >chance that you can verify certificates etc. I also wrote fake-hwclock (packaged in Debian) for this kind of reason. -- Steve McIntyre, Cambridge, UK.st...@einval.com Can't keep my eyes from the circling sky, Tongue-tied & twisted, Just an earth-bound misfit, I...
Re: chrony date months off
On Wed, 2024-01-31 at 12:56 -0500, gene heskett wrote: > [...] > Dec 30 03:15:42 bpi51e5p chronyd[1936]: Could not add source 192.168.71.3 > Dec 30 03:15:42 bpi51e5p chronyd[1936]: No suitable source for initstepslew > Dec 30 03:15:42 bpi51e5p chronyd[1936]: Could not add source 192.168.71.3 > Dec 30 03:15:44 bpi51e5p systemd[1]: chrony.service: New main PID 1936 > does not exist or is a zombie. > Dec 30 03:15:44 bpi51e5p systemd[1]: chrony.service: Failed with result > 'protocol'. Perhaps uncomment one/some of the pool address(es) in its config to allow chrony to find a suitable server.
SOLVED:Re: chrony date months off
On 1/31/24 13:19, Greg Wooledge wrote: On Wed, Jan 31, 2024 at 12:56:37PM -0500, gene heskett wrote: [...] # Stop bad estimates upsetting machine clock. maxupdateskew 10.0 initstepslew 30 192.168.71.3 # This directive enables kernel synchronisation (every 11 minutes) of the # real-time clock. Note that it can’t be used along with the 'rtcfile' directive. rtcsync I'll comment that line # Step the system clock instead of slewing it if the adjustment is larger than # one second, but only in the first three clock updates. makestep 1 3000 I had tried 30, and it did it about that many time ack the tcpdump log I'm tracking. And I'll put the 300 back in, that ack the tcpdump monitor seemed to effective. but I've not found in the docs, anything that will modify how far the step will change it, The first arg is one second. chrony seems to be the fave method for the arm64's but I have had better luck using ntpsec without the security on all other wintel machines. Its ntpsec I'm using on this machine to be a stratum 2 server for the rest of my local net. So that's what all the other local machines see. timedatectl bombs when asked to set-time, regardless of how many space separated arguments is says too many arguments. Aha! the time argument needs single quotes around it! The help screen is wrong but the man page says " ". So I have it now set for about 4 hours ago. Now about 5 seconds off, but its not querying my server. More man page perusal. I am getting the impression that timedatctl ultimately uses he first time service it can find, and while I have the clock sey pretty close, it nat offer ntp until there is an available ntp client, and I used apt to purge both chrony and ntpsec. So I;ll reinstall ntpsec. Done Then I went clear around the mulberry tree and copied (because my sshnet mounts of all these machine is as a user) the /sshnet/go704/etc/ntpsec/ntp.conf to my home dir on that box, then fired up a user mc and copied that file from /sshnet/go704/home/gene to /sshnet/bpi51/home/gene. went to a different workspace, fired up a sudo mc, copied that file to that machines /etc/ntpsec dir, then fixed the perms back to 0600. Then restarted ntpsec by stopping it, then starting it again so it would read the new file. Then: gene@bpi51e5p:~$ timedatectl status Local time: Wed 2024-01-31 15:40:13 EST Universal time: Wed 2024-01-31 20:40:13 UTC RTC time: Wed 2024-01-31 20:40:13 Time zone: America/New_York (EST, -0500) System clock synchronized: yes NTP service: n/a RTC in local TZ: no And my tcpdump trace here?: 15:51:01.235371 IP bpi51e5p.coyote.den.ntp > coyote.coyote.den.ntp: NTPv4, Client, length 48 15:51:01.235523 IP coyote.coyote.den.ntp > bpi51e5p.coyote.den.ntp: NTPv4, Server, length 48 15:52:06.236633 IP bpi51e5p.coyote.den.ntp > coyote.coyote.den.ntp: NTPv4, Client, length 48 15:52:06.236701 IP coyote.coyote.den.ntp > bpi51e5p.coyote.den.ntp: NTPv4, Server, length 48 IOW, its working. And I found another off by about an hour, so I copied that same file it it, problem solved. Now, I still have more cats to skin but solving those two problems will help. Now I can get back to the real problem. Lack of docs to make a TMC-2209, a very common motor driver in the stepstick category, work in the uart interface mode in a BTT octopus Pro controller cards driver sockets 2, 3 & 4. Add about 12 jumpers and put them back in step/dir/enable mode is the next test. That's going to take some coffee I haven't made yet today. Thanks for the nudge to make me think, Greg, take care & stay well. Cheers, Gene Heskett, CET. -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author, 1940) If we desire respect for the law, we must first make the law respectable. - Louis D. Brandeis
Re: chrony date months off
On 31/01/2024 12:12, Max Nikulin wrote: On 31/01/2024 17:54, to...@tuxteam.de wrote: I think you want "maxstep". It's in the man page chrony.conf(5). But if the time is "months off" perhaps you've got another problem to fix first? I think, the problem is no RTC on some *pi board, certainly chrony out of box setup is not ready to such environment and its solution is not maxstep. Gene, are you going to complain again that some package has no man pages? For Raspberry Pi's, Ubuntu offer a script similar to the following https://github.com/Jolicloud/initramfs-tools/blob/master/scripts/local-premount/fixrtc (I couldn't find an equivalent to https://sources.debian.net for Ubuntu, but the script is simple enough that I doubt if it's very different). The script works like this: if the root device is specified on the kernel command line AND the word "fixrtc" is specified, then get the time that the root file system was last mounted. The script then uses "date" to set the clock to that date stamp. I assume that the idea is that, rather than having the clock start at 1970, it's better to start it at, say, yesterday. You've still got quite a lot of slewing to do if you connect to NTP, but at least there's a chance that you can verify certificates etc. OpenPGP_signature.asc Description: OpenPGP digital signature
Re: chrony date months off
On Wed, Jan 31, 2024 at 12:56:37PM -0500, gene heskett wrote: [...] > # Stop bad estimates upsetting machine clock. > maxupdateskew 10.0 > initstepslew 30 192.168.71.3 > # This directive enables kernel synchronisation (every 11 minutes) of the > # real-time clock. Note that it can’t be used along with the 'rtcfile' > directive. > rtcsync > > # Step the system clock instead of slewing it if the adjustment is larger > than > # one second, but only in the first three clock updates. > makestep 1 3000 I've never used chrony, so all I know about it is what I've gleaned from skimming the chrony.conf page, from Google search results, and from things that people have said here. With that in mind, I don't know what happens if you've got both initstepslew *and* makestep in the same conf file. I would imagine you only want one of them. > Dec 30 03:15:32 bpi51e5p chronyd[1936]: Using right/UTC timezone to obtain > leap second data > Dec 30 03:15:32 bpi51e5p chronyd[1936]: Loaded seccomp filter (level 1) > Dec 30 03:15:42 bpi51e5p chronyd[1936]: Could not add source 192.168.71.3 > Dec 30 03:15:42 bpi51e5p chronyd[1936]: No suitable source for initstepslew > Dec 30 03:15:42 bpi51e5p chronyd[1936]: Could not add source 192.168.71.3 That IP address clearly came from your initstepslew line. Is there an NTP service running on that host? If so, is it synchronized? And does it permit client requests (from bpi51e5p)? > Dec 30 03:15:44 bpi51e5p systemd[1]: chrony.service: New main PID 1936 does > not exist or is a zombie. > Dec 30 03:15:44 bpi51e5p systemd[1]: chrony.service: Failed with result > 'protocol'. > Dec 30 03:15:44 bpi51e5p systemd[1]: Failed to start chrony, an NTP > client/server. This appears to be important. It's failing to start, which means it's not setting the clock, or doing anything else. You'll need to figure out why it's not starting. Perhaps it's *just* the fact that it can't contact an NTP service at 192.168.71.3. Or maybe there's more to the story. I don't know.
Re: chrony date months off
:chronyc(1) man:chrony.conf(5) Process: 1908 ExecStart=/usr/lib/systemd/scripts/chronyd-starter.sh $DAEMON_OPTS (code=exited, status=0/SUCCESS) CPU: 158ms Dec 30 03:15:31 bpi51e5p chronyd[1936]: chronyd version 4.2 starting (+CMDMON +NTP +REFCLOCK +RTC +PRIVDROP +SCFILTER +SIGND +ASYNCD> Dec 30 03:15:31 bpi51e5p chronyd[1936]: Frequency -20.055 +/- 0.010 ppm read from /var/lib/chrony/chrony.drift Dec 30 03:15:32 bpi51e5p chronyd[1936]: Using right/UTC timezone to obtain leap second data Dec 30 03:15:32 bpi51e5p chronyd[1936]: Loaded seccomp filter (level 1) Dec 30 03:15:42 bpi51e5p chronyd[1936]: Could not add source 192.168.71.3 Dec 30 03:15:42 bpi51e5p chronyd[1936]: No suitable source for initstepslew Dec 30 03:15:42 bpi51e5p chronyd[1936]: Could not add source 192.168.71.3 Dec 30 03:15:44 bpi51e5p systemd[1]: chrony.service: New main PID 1936 does not exist or is a zombie. Dec 30 03:15:44 bpi51e5p systemd[1]: chrony.service: Failed with result 'protocol'. Dec 30 03:15:44 bpi51e5p systemd[1]: Failed to start chrony, an NTP client/server. What output did you get? The time as reported by "date": gene@bpi51e5p:~$ date Sat Dec 30 05:30:58 AM EST 2023 gene@bpi51e5p:~$ gene@coyote:~$ date Wed Jan 31 12:38:16 EST 2024 gene@coyote:~$ What output did you *expect* to get? The time reported by date here about a minute later: gene@coyote:~$ date Wed Jan 31 12:38:16 EST 2024 gene@coyote:~$ What other relevant details can you supply? (The identities and configurations of the NTP servers that chrony is expected to use, for example.) There was an /etc/chrony/chrony.conf file, but no chrmy installed I had to install it fresh, which is puzzling. That was an earlier install now uptodate: Linux bpi51e5p 6.1.63-current-meson64 #1 SMP PREEMPT Mon Nov 20 10:52:19 UTC 2023 aarch64 aarch64 aarch64 GNU/Linux gene@bpi51e5p:/etc$ cat issue Armbian 23.11.1 jammy \l . Did I miss anything with this wall of text? If there's still something missing, id it and I'll see if it exists and copy/paste it. Cheers, Greg, Gene Heskett, CET. -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author, 1940) If we desire respect for the law, we must first make the law respectable. - Louis D. Brandeis
Re: chrony date months off
On Wed, Jan 31, 2024 at 10:25:40AM -0500, gene heskett wrote: > On 1/31/24 08:53, John Hasler wrote: > > Gene writes: > > > How do I setup /etc/chrony/chrony.conf so it slams the system clock to > > > the current time on the first cycle as its rebooting? > > > > initstepslew > > > > man chrony.conf > > deprecated in favor of makestep, and did not work, John. *sigh* How many times do we have to say it? When something goes wrong, don't simply say "it didn't work". Give the *details*. What changes did you make to files? What do the files look like now? What commands did you run? What output did you get? What output did you *expect* to get? What other relevant details can you supply? (The identities and configurations of the NTP servers that chrony is expected to use, for example.)
Re: chrony date months off
On 1/31/24 08:53, John Hasler wrote: Gene writes: How do I setup /etc/chrony/chrony.conf so it slams the system clock to the current time on the first cycle as its rebooting? initstepslew man chrony.conf deprecated in favor of makestep, and did not work, John. Thanks, John Cheers, Gene Heskett, CET. -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author, 1940) If we desire respect for the law, we must first make the law respectable. - Louis D. Brandeis
Re: chrony date months off
Max Nikulin wrote: > I think, the problem is no RTC on some *pi board, certainly chrony out of > box setup is not ready to such environment and its solution is not > maxstep. That's what makestep (initstepslew now being deprecated) is for. -- John Hasler j...@sugarbit.com Elmwood, WI USA
Re: chrony date months off
On 1/31/24 07:13, Max Nikulin wrote: On 31/01/2024 17:54, to...@tuxteam.de wrote: I think you want "maxstep". It's in the man page chrony.conf(5). But if the time is "months off" perhaps you've got another problem to fix first? Well, I do have other probs with that machine, mostly with the physicsl config of the BTT Octopus Pro 3dprinter control card its running, but that is not os related, it just a detail I have fixed on all the other machines. I think, the problem is no RTC on some *pi board, certainly chrony out of box setup is not ready to such environment and its solution is not maxstep. Gene, are you going to complain again that some package has no man pages? Mope. Thanks Max Cheers, Gene Heskett, CET. -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author, 1940) If we desire respect for the law, we must first make the law respectable. - Louis D. Brandeis
Re: chrony date months off
On Wed, Jan 31, 2024 at 07:53:01AM -0600, John Hasler wrote: > Gene writes: > > How do I setup /etc/chrony/chrony.conf so it slams the system clock to > > the current time on the first cycle as its rebooting? > > initstepslew > > man chrony.conf Debian 12 has chrony 4.3, and in *that* version of the man page, it says initstepslew is deprecated in favor of makestep. https://chrony-project.org/doc/4.3/chrony.conf.html#makestep
Re: chrony date months off
Gene writes: > How do I setup /etc/chrony/chrony.conf so it slams the system clock to > the current time on the first cycle as its rebooting? initstepslew man chrony.conf -- John Hasler j...@sugarbit.com Elmwood, WI USA
Re: chrony date months off
On Wed, Jan 31, 2024 at 05:32:26AM -0500, gene heskett wrote: > How do I setup /etc/chrony/chrony.conf so it slams the system clock to the > current time on the first cycle as its rebooting? > There was 20 yeas back, an ntpdate command that would do that. > Now it appears to conflict with the other client/servers You can use "rdate" (openrdate) as quick fix like `ntpdate'. I resort to using it inside my virtual machines on my laptop when it wakes up from hibernation. I use chrony on my production MTAs on the internet though. -- Regards, Didar Worlds are conquered, galaxies destroyed -- but a woman is always a woman. -- Kirk, "The Conscience of the King", stardate 2818.9 Generated by Signify v1.14 (http://www.debian.org/)
Re: chrony date months off
On 31/01/2024 17:54, to...@tuxteam.de wrote: I think you want "maxstep". It's in the man page chrony.conf(5). But if the time is "months off" perhaps you've got another problem to fix first? I think, the problem is no RTC on some *pi board, certainly chrony out of box setup is not ready to such environment and its solution is not maxstep. Gene, are you going to complain again that some package has no man pages?
Re: chrony date months off
On Wed, Jan 31, 2024 at 05:32:26AM -0500, gene heskett wrote: > How do I setup /etc/chrony/chrony.conf so it slams the system clock to the > current time on the first cycle as its rebooting? > There was 20 yeas back, an ntpdate command that would do that. > Now it appears to conflict with the other client/servers I think you want "maxstep". It's in the man page chrony.conf(5). But if the time is "months off" perhaps you've got another problem to fix first? You wouldn't want chrony to slam your clock just because its only reachable server runs amok. Just sayin'. Cheers -- t signature.asc Description: PGP signature
chrony date months off
How do I setup /etc/chrony/chrony.conf so it slams the system clock to the current time on the first cycle as its rebooting? There was 20 yeas back, an ntpdate command that would do that. Now it appears to conflict with the other client/servers Thanks Cheers, Gene Heskett, CET. -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author, 1940) If we desire respect for the law, we must first make the law respectable. - Louis D. Brandeis
date can't parse its own output was: difference in seconds between two formatted dates ...)
On Mon, Dec 18, 2023 at 08:17:21AM -0500, Greg Wooledge wrote: > On Mon, Dec 18, 2023 at 02:07:14PM +0100, to...@tuxteam.de wrote: > > I'm still amazed the OP hasn't understood that "date" can output > > custom formats -- and that it's not always possible to parse back > > a date in some custom format into a meaningful timestamp. > > unicorn:~$ date +"On this the %dth day of the %mth month of the year %Y > (Common Era), at %M minutes past the %Hth hour" > On this the 18th day of the 12th month of the year 2023 (Common Era), at 15 > minutes past the 08th hour > unicorn:~$ date -d "$(date +"On this the %dth day of the %mth month of the > year %Y (Common Era), at %M minutes past the %Hth hour")" > date: invalid date ‘On this the 18th day of the 12th month of the year 2023 > (Common Era), at 15 minutes past the 08th hour’ How 'bout date -d $(date +"1582-10-08T12:31:19") ...then you'd have to have a stern talk with old Gregor ;-D Cheers -- t signature.asc Description: PGP signature
Re: Date time problem bookworm, fvwm....
On Sun, Oct 22, 2023 at 01:51:41PM +0200, Thomas Schmitt wrote: [...] > Originally it did only put out text in an xterm, but then i shamelessly > exploited code from the exploitation chain xpppload <- xisdnload <- xload > to give it a histogram in ain additional separate window. Now this one beats my weirdness by a stretch :-) Cheers -- t signature.asc Description: PGP signature
Re: Date time problem bookworm, fvwm....
On Sun, Oct 22, 2023 at 07:50:54AM -0400, The Wanderer wrote: > On 2023-10-22 at 07:24, to...@tuxteam.de wrote: > > > I better not tell. My clock is a... shell script in a tiny Xterm > > which also shows my battery status. > > Ooo, that sounds interesting. I don't currently have a laptop, so the > battery-status part wouldn't currently apply, but this sounds like > something I might like to try when that changes; any chance of sharing > the specific details? Glad to oblige. The date part is the smallest, down there in the lower right corner :-) tomas@trotzki:~$ cat ~/bin/bat #!/bin/bash # Notes: # for colors: # tput setaf 1 ; tput bold ; echo -n 123 ; tput setaf 7 ; tput sgr0 ; echo 456 # cf tput(1) terminfo(5) # do continuous mode with watch -c, possibly t BAT='/sys/class/power_supply/BAT0' AC='/sys/class/power_supply/AC' FULL=$(cat $BAT/energy_full) NOW=$(cat $BAT/energy_now) case $(cat $AC/online) in 0) online="BAT" ;; 1) online="AC " ;; *) online="???" ;; esac echo -ne "$online " ; dc -e "5k $NOW $FULL / p" ; date +"%F%a%n %T" The fun part is convincing fvwm to do its thing: # Style for bat, clock: Style bat !Borders,!Handles,!Title # NOTES if text too big, nothing to be seen; # watch -t: no title; # the -geometry is there to place the window off screen while it's # not yet swallowed. # Can we change colors? Yeah: watch lets 'em through with option -c *FvwmButtons: (2x1, Frame 2, \ Swallow bat "Exec exec xterm -class bat -bg black -fg white \ -geometry +5000+5000 \ -fn 'xft:DejaVu Sans Mono Book:pixelsize=7' \ -e watch -tn 10 bat" ) Enjoy :) I've been mulling around whether to switch to Tcl/Tk: I like the unobtrusiveness of the thing, but some more noise when the battery is on its last legs would be desirable :-) > > But I'm weird. > > I literally used to go by "Weird" as a nickname, though (sadly?) it > never became as commonly used as with Al. Weird doesn't bother me at > all. A good feeling not to be alone around here ;-) Cheers -- t signature.asc Description: PGP signature
Re: Date time problem bookworm, fvwm....
On 2023-10-22 at 07:24, to...@tuxteam.de wrote: > I better not tell. My clock is a... shell script in a tiny Xterm > which also shows my battery status. Ooo, that sounds interesting. I don't currently have a laptop, so the battery-status part wouldn't currently apply, but this sounds like something I might like to try when that changes; any chance of sharing the specific details? > But I'm weird. I literally used to go by "Weird" as a nickname, though (sadly?) it never became as commonly used as with Al. Weird doesn't bother me at all. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Date time problem bookworm, fvwm....
Hi,
to...@tuxteam.de wrote:
> My clock is a... shell script in a tiny Xterm which
> also shows my battery status.
My digital clock with date display is a C program which mainly watches the
network traffic. It even has an own date format ("A0" = 2000, now is "C3")
which has an odd history beginning in 1987, when nobody expected to live
to see year 2000.
http://scdbackup.webframe.org/pppoem
Originally it did only put out text in an xterm, but then i shamelessly
exploited code from the exploitation chain xpppload <- xisdnload <- xload
to give it a histogram in ain additional separate window.
Have a nice day :)
Thomas
Re: Date time problem bookworm, fvwm....
On Sun, Oct 22, 2023 at 11:16:25AM +0200, Thomas Schmitt wrote: > Hi, > > Charlie wrote: > > I removed the clock from the > > FVWM task bar and Gkrellm now dis[pays the right time. So a fix > > of sorts with which I can live. > > Congrats. :)) > > > > being a bit long in > > the tooth to start relearning another window manager. > > I'm using fvwm since the last century. It's configured by a ~/.fvwm2rc > which is at least 20 years old with minor changes to adapt to changed > paths and to avoid some unwanted behavior from 10 years ago. I came back to it some time last century, after a very instructive travel which encompassed Gnome (Metacity), Xfce, Awesome and other exotica (olwm, GWM...) > My clock is FvwmXclock. It's an analog-style 12 hours without date > display. I better not tell. My clock is a... shell script in a tiny Xterm which also shows my battery status. But I'm weird. > Have a nice day :) Likewise :) Cheers -- t signature.asc Description: PGP signature
Re: Date time problem bookworm, fvwm....
Hi, Charlie wrote: > I removed the clock from the > FVWM task bar and Gkrellm now dis[pays the right time. So a fix > of sorts with which I can live. Congrats. :)) > being a bit long in > the tooth to start relearning another window manager. I'm using fvwm since the last century. It's configured by a ~/.fvwm2rc which is at least 20 years old with minor changes to adapt to changed paths and to avoid some unwanted behavior from 10 years ago. My clock is FvwmXclock. It's an analog-style 12 hours without date display. Have a nice day :) Thomas
Re: Date time problem bookworm, fvwm....
On Sun, 22 Oct 2023 10:13:59 +0200 "Thomas Schmitt" wrote: > Hi, > > Charlie wrote: > > The date on that system is one day in advance and one hour late. Not > > terrible, > > However after a short period 100% of one of the CPU cores is used, > > noisy running, and top -c shows this as the user: > > /usr/libexe/fvwm2/2.7.0/FvwmScript 17 4 none 0 8 FvwmScript > > DateTime > > Looking at > > https://raw.githubusercontent.com/fvwmorg/fvwm3/main/default-config/FvwmScript-DateTime > and reading "man FvwmScript" i'd say that the promised 1-second > waiting period of "PeriodicTasks" is heavily shortened by the clock > peculiarity. > > > > Managed to get date and time right with the ntp commands, set > > location etc., on Gkrellm at least. But the fvwm clock had frozen > > up and stopped. > > That's quite normal with periodic jobs when the system time gets > changed backward. Possibly the clock would come back to life after > the last shown time is reached again 23 hours later. > > > > Then tried to set the date manually with hwclock but no joy. > > Please detail "no joy": > Does hwclock show the future time after rebooting if you have set it > to the right time before rebooting ? > (Or is it only the system clock which hops ahead ?) > Does hwclock get changed to the future time without rebooting ? > > > > Removing FvwmScript which I can't open to edit removes the clock > > from the FVWM taskbar, > > Does this solve the problem with the future time ? > > > > And haven't tried to > > but Gkrellm is now using the same time? > > (I don't understand this statement. Maybe it's important for finding > the explanation.) > > > > It would appear to be an fvwm problem > > The fast running CPU might be related to poor handling of weird times > by FvwmScript. > > But for now i doubt that fvwm sets the system date on its own. > > > Have a nice day :) > > Thomas > Thank you for the link Thomas. I removed the clock from the FVWM task bar and Gkrellm now dis[pays the right time. So a fix of sorts with which I can live. I was going to install fluxbox, which I used many years ago before FVWM just to see what that clock said. Luckily didn't need to because the clock came up correct. Dreaded doing that anyway, being a bit long in the tooth to start relearning another window manager. So thank you for your help. Charlie
Re: Date time problem bookworm, fvwm....
Hi, Charlie wrote: > The date on that system is one day in advance and one hour late. Not > terrible, > However after a short period 100% of one of the CPU cores is used, > noisy running, and top -c shows this as the user: > /usr/libexe/fvwm2/2.7.0/FvwmScript 17 4 none 0 8 FvwmScript DateTime Looking at https://raw.githubusercontent.com/fvwmorg/fvwm3/main/default-config/FvwmScript-DateTime and reading "man FvwmScript" i'd say that the promised 1-second waiting period of "PeriodicTasks" is heavily shortened by the clock peculiarity. > Managed to get date and time right with the ntp commands, set location > etc., on Gkrellm at least. But the fvwm clock had frozen up and stopped. That's quite normal with periodic jobs when the system time gets changed backward. Possibly the clock would come back to life after the last shown time is reached again 23 hours later. > Then tried to set the date manually with hwclock but no joy. Please detail "no joy": Does hwclock show the future time after rebooting if you have set it to the right time before rebooting ? (Or is it only the system clock which hops ahead ?) Does hwclock get changed to the future time without rebooting ? > Removing FvwmScript which I can't open to edit removes the clock from > the FVWM taskbar, Does this solve the problem with the future time ? > And haven't tried to > but Gkrellm is now using the same time? (I don't understand this statement. Maybe it's important for finding the explanation.) > It would appear to be an fvwm problem The fast running CPU might be related to poor handling of weird times by FvwmScript. But for now i doubt that fvwm sets the system date on its own. Have a nice day :) Thomas
Date time problem bookworm, fvwm....
Hello All, Have a a Dell Vostro laptop: Bookworm up to date and upgraded operating system to that state. Using FVWM window manager. The date on that system is one day in advance and one hour late. Not terrible, However after a short period 100% of one of the CPU cores is used, noisy running, and top -c shows this as the user: /usr/libexe/fvwm2/2.7.0/FvwmScript 17 4 none 0 8 FvwmScript DateTime Managed to get date and time right with the ntp commands, set location etc., on Gkrellm at least. But the fvwm clock had frozen up and stopped. On reboot went back to a day ahead and an hour late even on Gkrellm. Then tried to set the date manually with hwclock but no joy. Removing FvwmScript which I can't open to edit removes the clock from the FVWM taskbar, if that is what it is called. And haven't tried to but Gkrellm is now using the same time? It would appear to be an fvwm problem so I may be wise to move to another window manager. However thought I would ask here first, in case someone had the same problem or some clue to solve it. TIA Charlie [disclaimer] Any replies from me may be late because, can not afford to run my generator all day. [end disclaimer] -- Registered Linux User:- 329524 *** I scarcely remember counting upon any Happiness—I look not for it if it be not in the present hour—nothing startles me beyond the Moment. The setting sun will always set me to rights—or if a Sparrow come before my Window I take part in its existence and pick about the Gravel. JOHN KEATS *** Debian GNU/Linux - just the best way to create magic ___
Re : Re: date de sortie prévisionnelle de Debian 12 Bookworm: le 10 juin 2023
Le lundi 1 mai 2023 à 15:44, ajh-valmer a écrit : > Si c'est un bug, il sera corrigé à un moment. > C'est pourquoi j'attends toujours quelques semaines > avant de migrer, avec cette précaution de l'installer sur > une autre partition pour le tester. Je ne crois pas que c'est un bug dans la distro, j'ai fais une nouvelle install de Bookworm sur un PC il y a des mois et tout s'est bien passé. Comme dit @didier, il doit rester quelque chose d'anciennes mises à jour. Sans parler de tous les bidouillages que j'ai fais sur mon installation actuelle. -- benoit
Re: Re : date de sortie prévisionnelle de Debian 12 Bookworm: le 10 juin 2023
Merci pour l'info! J'en prend bonne note pour le prochain essai. Roger Le 2023-05-01 à 11 h 58, steve a écrit : Le 01-05-2023, à 11:26:33 -0400, Ro Bou a écrit : Pour ce problème, il faut cette entrée GRUB_DISABLE_OS_PROBER=false dans /etc/default/grub puis lancer, en root update-grub2 Ce comportement a changé entre bookworm et la stable actuelle. C'est noté quelque part dans les notes de publication (je crois). s.
Re: date de sortie prévisionnelle de Debian 12 Bookworm: le 10 juin 2023
Le 05/05/2023 à 14:00, Erwann Le Bras a écrit : [...] * si c'est le système qui démarre X et ensuite tu t'identifies sur la mire X11, c'est forcément root le propriétaire. [...] En fait ton exemple illustre le fait que lightdm, bien que pas si vieux, a une gestion à l'ancienne et ne permet donc que le lancement de X11 par le super-utilisateur, si j'ai bien suivi: https://wiki.archlinux.org/title/Xorg#Rootless_Xorg mais mon exemple précédent illustre que lorsque le système démarre en mode graphique par défaut avec la config Debian de base (DE Gnome), gdm est lancé par root, mais dans le cas de gnome-classic sous Bullseye cette session est lancée par l'utilisateur et X11 aussi (dans le cas de Gnome ordinaire il n'y aurait pas de X11) Enfin en gros tout ça c'est que je comprends mais j'ai peut-être pas tout capté :-)
Re: date de sortie prévisionnelle de Debian 12 Bookworm: le 10 juin 2023
bonjour Pour moi, ça dépend : * si tu t'identifie sur la console texte pour lancer l'interface graphique là oui, elle est lancée avec ton ID * si c'est le système qui démarre X et ensuite tu t'identifies sur la mire X11, c'est forcément root le propriétaire. Chez moi j'ai : root 6608 1 0 avril12 ? 00:00:09 /usr/sbin/lightdm root 6623 6608 0 avril12 tty7 04:51:46 /usr/lib/xorg/Xorg :0 -seat seat0 -auth /var/run/lightdm/root/:0 -nolisten tcp vt7 -novtswitch root 6968 6608 0 avril12 ? 00:00:00 lightdm --session-child 16 25 erwann 7026 6968 0 avril12 ? 00:00:02 xfce4-session erwann 7092 7026 0 avril12 ? 00:00:02 /usr/bin/ssh-agent /usr/bin/im-launch startxfce4 erwann 7160 7000 0 avril12 ? 00:00:05 /usr/lib/x86_64-linux-gnu/xfce4/xfconf/xfconfd Le système démarre X et je me loggue ensuite sur l'invite graphique. Erwann Le 04/05/2023 à 10:19, didier gaumet a écrit : mais j'avais cru comprendre qu'historiquement X11 était lancé par root surtout pour pouvoir accéder aux ressources nécessaires, et qu'au fil du temps on a découvert des failles potentielles de sécurité qui rendaient ce mode de fonctionnement indésirable. On privilégie donc a priori de nos jours un lancement de X11 par un utilisateur "ordinaire".
Re: date de sortie prévisionnelle de Debian 12 Bookworm: le 10 juin 2023
Le 04/05/2023 à 09:04, Michel Verdier a écrit : Ça dépend comment tu lance X. Xorg est toujours lancé en root, c'est normal pour éviter les failles de sécurité. J'ai eu ce problème sur Bullseye. Je lance Xorg via startx. J'ai manipé pour que /tmp/serverauth... soit créé avec l'uid de mon user. Malheureusement je n'ai pas noté la manip. Mais je crois que j'ai juste créé un ~/.xserverrc avec #!/bin/sh exec /usr/bin/X -nolisten tcp -nolisten local "$@" Selon comment tu lances X je ne sais pas si ça peut être applicable. Si tu passes par un DM pour te logguer c'est lui qui fait la bascule sur ton user. Donc regarde dans ta conf du DM utilisé si tu n'as pas une personnalisation qui casse ça. Je suis vraiment ignare pour les problématiques de sécurité en général et en environnement graphique en particulier, donc prendre ce que je dis avec le recul nécessaire :-) mais j'avais cru comprendre qu'historiquement X11 était lancé par root surtout pour pouvoir accéder aux ressources nécessaires, et qu'au fil du temps on a découvert des failles potentielles de sécurité qui rendaient ce mode de fonctionnement indésirable. On privilégie donc a priori de nos jours un lancement de X11 par un utilisateur "ordinaire". Dans le cas ed Debian 11 Bullseye, avec display manager GDM et session Gnome "Classic" (c'est important car la session Gnome "de base" avec Debian11/GDM lance une session Wayland alors que la session "Classic" lance toujours une session Xorg), Donc dans ce cas, GDM est lancé par root (UID 0) mais la session Gnome "Classic" et Xorg sont lancés par mon user (didier, UID 1000): didier@hp-notebook14:~$ ps -axl | grep -i xorg 4 100082978295 20 0 884680 85768 - Sl+ tty3 0:51 /usr/lib/xorg/Xorg vt3 -displayfd 3 -auth /run/user/1000/gdm/Xauthority -nolisten tcp -background none -noreset -keeptty -novtswitch -verbose 3 0 1000 11387 11332 20 0 19344 644 - S+ pts/0 0:00 grep -i xorg didier@hp-notebook14:~$ ps -axl | grep -i gdm 4 01064 1 20 0 252828 8912 - Ssl ? 0:00 /usr/sbin/gdm3 4 082861064 20 0 180140 10256 - Sl ? 0:00 gdm-session-worker [pam/gdm-password] 4 100082958286 20 0 175320 6532 - Ssl+ tty3 0:00 /usr/libexec/gdm-x-session --register-session --run-script gnome-session-classic 4 100082978295 20 0 884664 85768 - Sl+ tty3 0:51 /usr/lib/xorg/Xorg vt3 -displayfd 3 -auth /run/user/1000/gdm/Xauthority -nolisten tcp -background none -noreset -keeptty -novtswitch -verbose 3 0 1000 11389 11332 20 0 19212 704 - S+ pts/0 0:00 grep -i gdm le wiki Archlinux a une section sur le lancement de Xorg par un utilisateur ordinaire: https://wiki.archlinux.org/title/Xorg#Rootless_Xorg
Re: date de sortie prévisionnelle de Debian 12 Bookworm: le 10 juin 2023
Le 1 mai 2023 benoit a écrit : > J'ai essayé 2x de passer en Bookworm, mais après la mise à jour, X ne veut > plus se lancer, car il n'a pas le droit d'écrire dans /tmp:LOCKMACHIN BIDULE > (G pas noté le message d'erreur) > > Seul root peut lancer x Ça dépend comment tu lance X. Xorg est toujours lancé en root, c'est normal pour éviter les failles de sécurité. J'ai eu ce problème sur Bullseye. Je lance Xorg via startx. J'ai manipé pour que /tmp/serverauth... soit créé avec l'uid de mon user. Malheureusement je n'ai pas noté la manip. Mais je crois que j'ai juste créé un ~/.xserverrc avec #!/bin/sh exec /usr/bin/X -nolisten tcp -nolisten local "$@" Selon comment tu lances X je ne sais pas si ça peut être applicable. Si tu passes par un DM pour te logguer c'est lui qui fait la bascule sur ton user. Donc regarde dans ta conf du DM utilisé si tu n'as pas une personnalisation qui casse ça.
Re: date de sortie prévisionnelle de Debian 12 Bookworm: le 10 juin 2023
Le Mon, 01 May 2023 12:34:35 +, benoit a écrit : > J'ai essayé 2x de passer en Bookworm, mais après la mise à jour, X ne > veut plus se lancer, car il n'a pas le droit d'écrire dans > /tmp:LOCKMACHIN BIDULE (G pas noté le message d'erreur) > > Seul root peut lancer x > > Du coup j'ai restauré mon système et j'ai abandonné le projet de > passer en Bookworm Jamais eu ce genre de problème. A noter: - Je suis prudent et lis donc les messages dans la console! - J'utilise Aptitude (vieille habitude qui m'a toujours satisfait) - J'ajoute le sources.list de la testing sans enlever celui de stable - je désinstalle potentiellement les drivers problématiques (Nvidia...) - je lance l'upgrade depuis la console et non depuis un bureau graphique - une fois passé en testing j'enlève stable et ajoute unstable avec un pinning (en tout cas au début du cycle pour éviter les blocages et logiciels manquants de testing) J'ajouterais au vu des messages que je vois parfois passer: Sur les ordinateurs modernes, il ne faut pas accuser Debian ou Grub de ce qui concerne UEFI, et donc configurer UEFI en fonction de son usage, surtout quand on change d'OS ou «double-boot» avec Windows…
Re: date de sortie prévisionnelle de Debian 12 Bookworm: le 10 juin 2023
Le lundi 01 mai 2023 à 12:34 +, benoit a écrit : > > J'ai essayé 2x de passer en Bookworm, mais après la mise à jour, X ne > veut plus se lancer, car il n'a pas le droit d'écrire dans > /tmp:LOCKMACHIN BIDULE (G pas noté le message d'erreur) > > Seul root peut lancer x > > Du coup j'ai restauré mon système et j'ai abandonné le projet de > passer en Bookworm > > -- > Benoît je n'ai pas migré mon système stable réel vers Debian Bookworm, je le ferai un peu après la sortie officielle. Mais j'ai déjà installé en machine virtuelle une debian 12 et j'ai déjà mis à jour en machine virtuelle une Debian 11 vers 12, tout ça sans problème. j'aurais tendance à *supposer* que tu traînes des scories d'une installation Debian qui a été mise à jour successivement (genre Debian 7->8->...11 par exemple) sans bien faire lé ménage à chaque fois. tu peux déjà regarder avec aptitude search '~o' si tu as des vieux paquets (cette commande te renverra aussi les paquets installés localement même si ils ne sont pas obsolètes) mais c'est peut-être autre chose, hein :-)
Re: Re : date de sortie prévisionnelle de Debian 12 Bookworm: le 10 juin 2023
Le 01-05-2023, à 11:26:33 -0400, Ro Bou a écrit : Bonjour! J'ai aussi fait l'essai de bookworm. Résultat pas concluant dans mon cas. Je suis en multi boot avec le windows 10 pré-installé, une debian-facile et un disque usb externe de 4 tb pour des sauvegardes. Au redémarrage de l'installation le grub n'affichait que la bookworm. Pour ce problème, il faut cette entrée GRUB_DISABLE_OS_PROBER=false dans /etc/default/grub puis lancer, en root update-grub2 Ce comportement a changé entre bookworm et la stable actuelle. C'est noté quelque part dans les notes de publication (je crois). s.
Re: Re : date de sortie prévisionnelle de Debian 12 Bookworm: le 10 juin 2023
Bonjour! J'ai aussi fait l'essai de bookworm. Résultat pas concluant dans mon cas. Je suis en multi boot avec le windows 10 pré-installé, une debian-facile et un disque usb externe de 4 tb pour des sauvegardes. Au redémarrage de l'installation le grub n'affichait que la bookworm. Après quelques heures de boulot pour revenir à la situation précédente, le démarrage sur la debian-facile demeurait lent. J'ai donc supprimé la bookworm et réinstallé la debian. Je vais attendre quelques mois pour le prochain essai. Pour info, lors de l'installation j'avais utilisé le mode expert pour me permettre d'installer le grub sur la partition root mais je n'ai pas trouvé la façon de faire. Je vais fouiller la question. Bonne journée, Roger Le 2023-05-01 à 08 h 34, benoit a écrit : J'ai essayé 2x de passer en Bookworm, mais après la mise à jour, X ne veut plus se lancer, car il n'a pas le droit d'écrire dans /tmp:LOCKMACHIN BIDULE (G pas noté le message d'erreur) Seul root peut lancer x Du coup j'ai restauré mon système et j'ai abandonné le projet de passer en Bookworm -- Benoît Envoyé avec la messagerie sécurisée Proton Mail. --- Original Message --- Le vendredi 28 avril 2023 à 10:18, didier gaumet a écrit : date de sortie prévisionnelle de Debian 12 Bookworm: le 10 juin 2023. le message annoçant la nouvelle sur la liste Devel: https://lists.debian.org/debian-devel-announce/2023/04/msg7.html
Re: date de sortie prévisionnelle de Debian 12 Bookworm: le 10 juin 2023
On Monday 01 May 2023 14:34:35 benoit wrote: > J'ai essayé 2x de passer en Bookworm, mais après la mise à jour, > X ne veut plus se lancer, car il n'a pas le droit d'écrire > dans /tmp:LOCKMACHIN BIDULE (G pas noté le message d'erreur) > Seul root peut lancer x > Du coup j'ai restauré mon système et j'ai abandonné le projet de > passer en Bookworm J'espère pas définitivement. Si c'est un bug, il sera corrigé à un moment. C'est pourquoi j'attends toujours quelques semaines avant de migrer, avec cette précaution de l'installer sur une autre partition pour le tester.
Re : date de sortie prévisionnelle de Debian 12 Bookworm: le 10 juin 2023
J'ai essayé 2x de passer en Bookworm, mais après la mise à jour, X ne veut plus se lancer, car il n'a pas le droit d'écrire dans /tmp:LOCKMACHIN BIDULE (G pas noté le message d'erreur) Seul root peut lancer x Du coup j'ai restauré mon système et j'ai abandonné le projet de passer en Bookworm -- Benoît Envoyé avec la messagerie sécurisée Proton Mail. --- Original Message --- Le vendredi 28 avril 2023 à 10:18, didier gaumet a écrit : > date de sortie prévisionnelle de Debian 12 Bookworm: le 10 juin 2023. > > le message annoçant la nouvelle sur la liste Devel: > https://lists.debian.org/debian-devel-announce/2023/04/msg7.html
date de sortie prévisionnelle de Debian 12 Bookworm: le 10 juin 2023
date de sortie prévisionnelle de Debian 12 Bookworm: le 10 juin 2023. le message annoçant la nouvelle sur la liste Devel: https://lists.debian.org/debian-devel-announce/2023/04/msg7.html
Re: differences between hwclock <-> date due to time zone issues? ...
On 25/03/2023 10:39, Albretch Mueller wrote: You can't physically alter a DVD[+|-]R once it is burned ... Do you customize images to change preferences, e.g. to make OS aware that hardware clock is set to local time? If you do not than OS almost certainly assumes that system time is in UTC, so you may experience bizarre TLS-related errors. If you do than it is better to set actual timezone instead and to get daylight saving time transitions out of the box.
Re: differences between hwclock <-> date due to time zone issues? ...
On 25/03/2023 10:39, Albretch Mueller wrote: On 3/25/23, Max Nikulin wrote: - Both Debian and Windows installed on the hard drive ... Thank you for the steps and the logical elucidations that may certainly help someone else, but I can't do that "because" all electronic devices which I use are being kept. System clock in UTC and time offset rules from time zone database is a way to reduce maintenance burden. E.g. you do not need to learn how to synchronize hardware clock and runtime system clock. You can't physically alter a DVD[+|-]R once it is burned ... Notice that for the case of DVD I suggested timedatectl set-timezone America/Chicago when the system is booted. There may be a UI dialog to configure timezone. I have no idea concerning desktop environment on your DVD. I have never tried if timezone may be configured from DHCP response when your computer gets its IP address. Such tricks may eliminate necessity to type commands. I assume that a query to a geolocation service to guess time zone is not an option for you. Anyway you need to regularly burn new disks to have latest security updates, so tzdata should not be terribly outdated as well. Finally at least some CD-R and DVD±R formats allows to not close session and to add more files later. Perhaps it may be used to customize an image to add a script to configure time zone, add some updates, etc.
Re: differences between hwclock <-> date due to time zone issues? ...
David Wright composed on 2023-03-24 23:20 (UTC-0500): > BTW I've only really trusted reading or setting the RTC by means of > the CMOS screens, and treat it as a one-time only process (upon > acquisition), assuming the coin-cell battery never needs replacing. Lucky you. I can only dream of going more than 3 months without something needing its 2032 replaced. Unplugged old Dells devour them. -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata
Re: differences between hwclock <-> date due to time zone issues? ...
On Fri 24 Mar 2023 at 19:10:49 (-0400), Stefan Monnier wrote: > > That works great for the Live OS, but not for the fixed-disk OS. If > > the Live OS sets the HW clock to local upon shutdown, but the fixed-disk > > OS expects the HW clock to be UTC, then the fixed-disk OS is wrong > > every time it boots after the Live OS. > > AFAIK the Linux kernel is pretty careful not to change the *hour* of the > hwclock: when using NTP, it will tweak the seconds to keep the hwclock > in sync with the rest of the world, but leave the hours alone, so as to > preserve the timezone in use, regardless if it's the right one (UTC) or > something else. Minutes, rather than hours, I would have thought. After all, there are some crazy TZs out there, and even crazier daylight savings schemes. > I assume GNU/Linux distributions like Debian are similarly careful, > since dual booting with a Windows install that doesn't use UTC for the > hwclock was a very common use case at least some years ago. Cheers, David.
Re: differences between hwclock <-> date due to time zone issues? ...
On Fri 24 Mar 2023 at 17:13:31 (+), Albretch Mueller wrote:
> On 3/24/23, Andy Smith wrote:
> > As already pointed out, the hardware clock is used in very limited
> > ways and is not the same thing as the system clock, so your result
> > is as expected.
> > What are you actually trying to do?
> >
> > What "time zone issues" do you refer to?
>
> I should have pointed out that I always go into exposed mode (use the
> Internet) with a live DVD. My laptop was always 6 hours ahead and now
> that they changed to summer time, it is 5 hours ahead.
> I used logs which names a time a la:
>
> _DT=$(date +%Y%m%d%H%M%S)
> _BN=$(basename "${_SDIR}")
> _LOG_FL="${_BN}_${_DT}.log"
> ...
> If anything, timing is one of the aspects of reality which should be
> coordinated.
Hence the existence of UTC since around 1960: Coordinated Universal Time.
But to benefit from it, you also have to coordinate your computers
/and/ their OSes. I can't imagine trying to run a laptop with its RTC
on Local time, because of time zone changes when travelling. I suppose
it's just about possible to manage it on a desktop computer in Arizona.
Like Greg, I've not used Live systems to any extent, and don't know
how they handle setting a time zone.
BTW I've only really trusted reading or setting the RTC by means of
the CMOS screens, and treat it as a one-time only process (upon
acquisition), assuming the coin-cell battery never needs replacing.
(All my computers have begun life running Windows.)
Cheers,
David.
Re: differences between hwclock <-> date due to time zone issues? ...
On 3/25/23, Max Nikulin wrote: > - Both Debian and Windows installed on the hard drive ... Thank you for the steps and the logical elucidations that may certainly help someone else, but I can't do that "because" all electronic devices which I use are being kept. You can't physically alter a DVD[+|-]R once it is burned ... lbrtchx
Re: differences between hwclock <-> date due to time zone issues? ...
On 25/03/2023 07:07, Albretch Mueller wrote: I am using right now a DELL laptop which had Windows 11 installed but I expect that the following should work smoothly enough: - Hardware clock is in UTC - Both Debian and Windows installed on the hard drive are configured to your local time zone (with installed updates related to tzdata) and aware that hardware clock is in in UTC - When you boot a live image, you run a command like timedatectl set-timezone America/Chicago You might need to update tzdata package if you reside in a time zone with time offset rules have changed later than the live image was prepared. What are your issues with such workflow?
Re: differences between hwclock <-> date due to time zone issues? ...
I am using right now a DELL laptop which had Windows 11 installed but started to give me sh!t which I totally ignored and started to use my good old friend Debian in order to "keep moving". By the way, after a while as if for a magical reason the hw time changed and now it is showing to me the same time I can see on https://www.timeanddate.com/ for my time zone. Devices I use seems to develop a mind of their own ;-) lbrtchx
Re: differences between hwclock <-> date due to time zone issues? ...
> That works great for the Live OS, but not for the fixed-disk OS. If > the Live OS sets the HW clock to local upon shutdown, but the fixed-disk > OS expects the HW clock to be UTC, then the fixed-disk OS is wrong > every time it boots after the Live OS. AFAIK the Linux kernel is pretty careful not to change the *hour* of the hwclock: when using NTP, it will tweak the seconds to keep the hwclock in sync with the rest of the world, but leave the hours alone, so as to preserve the timezone in use, regardless if it's the right one (UTC) or something else. I assume GNU/Linux distributions like Debian are similarly careful, since dual booting with a Windows install that doesn't use UTC for the hwclock was a very common use case at least some years ago. Stefan
Re: differences between hwclock <-> date due to time zone issues? ...
On Fri, Mar 24, 2023 at 05:51:30PM -0400, Stefan Monnier wrote: > > If your policy choice ends up being "set HW clock to local", then you > > also have to make sure the correct time zone is set on each operating > > system, each time it boots. I have no idea how one does that on Debian > > Live, since I've never used Debian Live. So, I can hope for your sake > > that Debian Live uses a UTC HW clock. > > You may also circumvent the problem by making sure your "online" OS is > configured to set its time via NTP once it gets access to the Internet, > this way, any problem with the hwclock will only impact the "boot". That works great for the Live OS, but not for the fixed-disk OS. If the Live OS sets the HW clock to local upon shutdown, but the fixed-disk OS expects the HW clock to be UTC, then the fixed-disk OS is wrong every time it boots after the Live OS. ... unless the Live OS can be configured to shut down WITHOUT touching the HW clock at all. (Can Debian Live be configured that way? I have no idea.)
Re: differences between hwclock <-> date due to time zone issues? ...
> If your policy choice ends up being "set HW clock to local", then you > also have to make sure the correct time zone is set on each operating > system, each time it boots. I have no idea how one does that on Debian > Live, since I've never used Debian Live. So, I can hope for your sake > that Debian Live uses a UTC HW clock. You may also circumvent the problem by making sure your "online" OS is configured to set its time via NTP once it gets access to the Internet, this way, any problem with the hwclock will only impact the "boot". Many routers face a similar problem because they don't have any hwclock, so at the beginning of the boot they basically don't know what time it is (it's arbitrarily initialized to some "dummy" value like 01-Jan-1970 or to some timestamp saved at some point in the past), and they only get a valid time after they can connect to an NTP server. Stefan
Re: differences between hwclock <-> date due to time zone issues? ...
On Fri, Mar 24, 2023 at 05:13:31PM +, Albretch Mueller wrote: > I should have pointed out that I always go into exposed mode (use the > Internet) with a live DVD. My laptop was always 6 hours ahead and now > that they changed to summer time, it is 5 hours ahead. So, you have at least two operating systems that you boot on this computer: one (Debian 11) installed to fixed disk, and one (Debian Live 11) on removable media. If your two operating systems disagree over whether the HW clock should be set to UTC or to local time, you will get these issues. Most people who experience these issues are dual-booting Linux and Windows -- again, two different operating systems, which may have two different ideas of how to set the HW clock. Your case is the same, just with two different Linuxes. The solution is to decide how you want all of your operating systems to read/set the HW clock (UTC or local), and to make sure they both implement your chosen policy. Since one of your operating systems may be impossible to configure, that one's treatment of the HW clock may dictate the policy choice you need to make for the other OS. If your policy choice ends up being "set HW clock to local", then you also have to make sure the correct time zone is set on each operating system, each time it boots. I have no idea how one does that on Debian Live, since I've never used Debian Live. So, I can hope for your sake that Debian Live uses a UTC HW clock.
Re: differences between hwclock <-> date due to time zone issues? ...
On 3/24/23, Andy Smith wrote:
> As already pointed out, the hardware clock is used in very limited
> ways and is not the same thing as the system clock, so your result
> is as expected.
> What are you actually trying to do?
>
> What "time zone issues" do you refer to?
I should have pointed out that I always go into exposed mode (use the
Internet) with a live DVD. My laptop was always 6 hours ahead and now
that they changed to summer time, it is 5 hours ahead.
I used logs which names a time a la:
_DT=$(date +%Y%m%d%H%M%S)
_BN=$(basename "${_SDIR}")
_LOG_FL="${_BN}_${_DT}.log"
...
If anything, timing is one of the aspects of reality which should be
coordinated.
lbrtchx
Re: differences between hwclock <-> date due to time zone issues? ...
Hello, On Thu, Mar 23, 2023 at 09:41:40PM +, Albretch Mueller wrote: > I am using this (yes, visually cr@ppy ;-)) code snippet to set back > the time 5 hours. hwclock tells me it worked fine but the terminal > windows opened before and after running hwclock still give me the > "old" time setting? As already pointed out, the hardware clock is used in very limited ways and is not the same thing as the system clock, so your result is as expected. What are you actually trying to do? What "time zone issues" do you refer to? It is very rare to need to modify the hardware clock. Typically it's only done at shutdown time by the base OS to save the system clock to the hardware clock ready for next boot, as the system clock is assumed to be more accurate. Cheers, Andy -- https://bitfolk.com/ -- No-nonsense VPS hosting
Re: differences between hwclock <-> date due to time zone issues? ...
On Thu 23 Mar 2023 at 21:41:40 (+), Albretch Mueller wrote: > I am using this (yes, visually cr@ppy ;-)) code snippet to set back > the time 5 hours. hwclock tells me it worked fine but the terminal > windows opened before and after running hwclock still give me the > "old" time setting? You're in my time zone, aren't you, so your hardware clock (UTC) should be five hours ahead of the system clock (CDT). What are the two times on your system? # hwclock --verbose hwclock from util-linux 2.36.1 System Time: 1679611469.019755 Trying to open: /dev/rtc0 Using the rtc interface to the clock. Last drift adjustment done at 1650159782 seconds after 1969 Last calibration done at 1650159782 seconds after 1969 Hardware clock is on UTC time Assuming hardware clock is kept in UTC time. Waiting for clock tick... ...got clock tick → Time read from Hardware Clock: 2023/03/23 22:44:30 Hw clock time : 2023/03/23 22:44:30 = 1679611470 seconds since 1969 Time since last adjustment is 29451688 seconds Calculated Hardware Clock drift is 0.00 seconds → 2023-03-23 17:44:28.998946-05:00 # Cheers, David.
Re: differences between hwclock <-> date due to time zone issues? ...
On 3/23/23, Cindy Sue Causey wrote: > On 3/23/23, Albretch Mueller wrote: >> I am using this (yes, visually cr@ppy ;-)) code snippet to set back >> the time 5 hours. hwclock tells me it worked fine but the terminal >> windows opened before and after running hwclock still give me the >> "old" time setting? >> >> _HRS_PM=-5 >> < snipped for brevity > > > just battled this topic a couple months ago but can't remember which > operating system. It was fixed INSTANTLY by creating /etc/adjtime (if > it doesn't already exist) then entering the following: > > 0.0 0 0.0 > 0 > UTC > > Once saved, it takes just a few seconds then, BAM, there it is! > Everything matches.. IF the hardware clock is set to universal time. > < snipped for brevity > Not quite. I forgot to say you also need to issue the following command afterward: # dpkg-reconfigure tzdata That's where you get to pick your timezone which is the other thing I forgot to mention. I saw Stefan referenced the topic so I wasn't going to create any more noise until I realized I'd left off tzdata. The good news there is the Debian debootstrap link covers that, too: https://www.debian.org/releases/wheezy/amd64/apds03.html.en#idp7856176 Next time I'll try to remember to fully read my own offered resource before hitting "Send". Cindy :) -- Talking Rock, Pickens County, Georgia, USA * runs with birdseed *
Re: differences between hwclock <-> date due to time zone issues? ...
On 3/23/23, Albretch Mueller wrote:
> I am using this (yes, visually cr@ppy ;-)) code snippet to set back
> the time 5 hours. hwclock tells me it worked fine but the terminal
> windows opened before and after running hwclock still give me the
> "old" time setting?
>
> _HRS_PM=-5
>
> ###
> #
> https://stackoverflow.com/questions/1092631/get-current-time-in-seconds-since-the-epoch-on-linux-bash
> _DTS=$(date +%s)
> echo "// __ \$_DTS: |${_DTS}|";
> _DTF=$(date --date @${_DTS})
> echo "// __ \$_DTF: |${_DTF}|";
>
> _NEW_DTS=$((_DTS+3600*_HRS_PM))
> echo "// __ \$_NEW_DTS: |${_NEW_DTS}|";
>
> # Convert the number of seconds back to date
> _NEW_DTF=$(date --date @${_NEW_DTS})
> echo "// __ \$_NEW_DTF: |${_NEW_DTF}|";
>
> which hwclock
>
> sudo hwclock --show
> sudo hwclock --debug --set --date "${_NEW_DTF}"
> sudo hwclock --show
>
> date
>
> // __ $_DTS: |1679606975|
> // __ $_DTF: |Thu 23 Mar 2023 09:29:35 PM UTC|
> // __ $_NEW_DTS: |1679588975|
> // __ $_NEW_DTF: |Thu 23 Mar 2023 04:29:35 PM UTC|
> hwclock from util-linux 2.36.1
> Thu 23 Mar 2023 09:29:35 PM UTC
> $ sudo hwclock --show
> 2023-03-23 16:30:23.685781+00:00
> $ date
> Thu 23 Mar 2023 09:31:40 PM UTC
I left all the above because I didn't know where to safely snip. I
just battled this topic a couple months ago but can't remember which
operating system. It was fixed INSTANTLY by creating /etc/adjtime (if
it doesn't already exist) then entering the following:
0.0 0 0.0
0
UTC
Once saved, it takes just a few seconds then, BAM, there it is!
Everything matches.. IF the hardware clock is set to universal time.
Knowing to do that comes from an uncountable number of debootstrap'ed
Debian releases. The step can be found here under the "D.3.4.3.
Setting Timezone" heading:
https://www.debian.org/releases/wheezy/amd64/apds03.html.en#idp7856176
If your hardware clock is not UTC, I've never gone there so I don't
know. My CHOICE is UTC because a tip many years ago advised that doing
so helps our computers stay in sync more seamlessly with the rest of
the World. Whether that's true or not, I don't know that, either, but
going this route sure has taken the pain out of the local time keeping
end of all of this *for me*. :)
Cindy :)
Notable: If /etc/adjtime exists and has data that is anything other
than the 0.0s in there, my experience has been that occurs when I
don't have my hardware clock set up properly. When I go the UTC/0.0
route, my file never changes. That data, those numbers, is/are the
computer doing its own thing trying to keep things aligned based on
.e.g our correct and incorrect date commands issued via programs like
hwclock.
--
Talking Rock, Pickens County, Georgia, USA
* runs with birdseed *
Re: differences between hwclock <-> date due to time zone issues? ...
> I am using this (yes, visually cr@ppy ;-)) code snippet to set back > the time 5 hours. hwclock tells me it worked fine but the terminal > windows opened before and after running hwclock still give me the > "old" time setting? The hardware clock is an "external" device which the Linux kernel typically uses in very limited ways: 1- it reads it at boot to figure out what is the current time to initialize the system's own time. 2- it adjusts it every once in a while when the system's time is presumed to be more precise (because it's using NTP). If you want to change the system's time, then change the system's time, not the hardware clock. To change the system's time, use `date` (see `man date` for the format of its arguments). But changing the system's time is very rarely a good idea. If you want to change the time based on timezone issues, then change the *timezone* rather than the time this way your running applications won't be subjected to time travel, which tends to cause all kinds of odd behaviors because suddenly the timer that was supposed to fire after a handful of seconds suddenly waits 5h, or the timeout that should only fire when there's really no answer after 2min fires right away because it thinks 5h have passed. Oh, and connections on the internet may fail when your machine's time is to too far out of sync (and 5h *is* far), since some authentication algorithms rely on time constraints. Note that the timezone is not a system-wide setting. Every process can use its own timezone, e.g. by setting the `TZ` environment variable. Try for example `TZ=UTC date` and then `TZ=Pacific/Samoa date`. Browse /usr/share/zoneinfo/ to see the list of timezones your system knows about. Stefan
differences between hwclock <-> date due to time zone issues? ...
I am using this (yes, visually cr@ppy ;-)) code snippet to set back
the time 5 hours. hwclock tells me it worked fine but the terminal
windows opened before and after running hwclock still give me the
"old" time setting?
_HRS_PM=-5
###
#
https://stackoverflow.com/questions/1092631/get-current-time-in-seconds-since-the-epoch-on-linux-bash
_DTS=$(date +%s)
echo "// __ \$_DTS: |${_DTS}|";
_DTF=$(date --date @${_DTS})
echo "// __ \$_DTF: |${_DTF}|";
_NEW_DTS=$((_DTS+3600*_HRS_PM))
echo "// __ \$_NEW_DTS: |${_NEW_DTS}|";
# Convert the number of seconds back to date
_NEW_DTF=$(date --date @${_NEW_DTS})
echo "// __ \$_NEW_DTF: |${_NEW_DTF}|";
which hwclock
sudo hwclock --show
sudo hwclock --debug --set --date "${_NEW_DTF}"
sudo hwclock --show
date
// __ $_DTS: |1679606975|
// __ $_DTF: |Thu 23 Mar 2023 09:29:35 PM UTC|
// __ $_NEW_DTS: |1679588975|
// __ $_NEW_DTF: |Thu 23 Mar 2023 04:29:35 PM UTC|
hwclock from util-linux 2.36.1
Thu 23 Mar 2023 09:29:35 PM UTC
$ sudo hwclock --show
2023-03-23 16:30:23.685781+00:00
$ date
Thu 23 Mar 2023 09:31:40 PM UTC
Re: Logcheck et format de date
Le 2022-11-07 17:22, Francois Mescam a écrit : Il y a une option de rsyslog qui joue la-dessus : # Use traditional timestamp format. # To enable high precision timestamps, comment out the following line. # $ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat Il me semble que récemment sa valeur par défaut a changé ce qui expliquerait ton problème. Merci beaucoup pour l'info François, je rencontrais le même problème que David et je n'avais pas encore eu le temps d'investiguer. Au passage, pendant quelques jours, rsyslog nous a fait une autre blague qui a rendu les règles de logcheck inopérantes : le nom d'hôte a été temporairement remplacé dans les logs par la chaine « [localhost] » (les règles ne prévoient de crochets à cet endroit). Sébastien -- Sébastien Dinot Ne goutez pas au logiciel libre, vous ne pourriez plus vous en passer ! https://www.palabritudes.net/
Re: Logcheck et format de date
Merci François. C'est exactement ça !
Bonne soirée.
David.
Le 07/11/2022 à 17:22, Francois Mescam a écrit :
Il y a une option de rsyslog qui joue la-dessus :
# Use traditional timestamp format.
# To enable high precision timestamps, comment out the following line.
#
$ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat
Il me semble que récemment sa valeur par défaut a changé ce qui
expliquerait ton problème.
Francois Mescam
Le 07/11/2022 à 15:32, David BERCOT a écrit :
Bonjour,
J'utilise Logcheck sur plusieurs systèmes et je me suis rendu compte que
tous les logs remontaient (malgré les filtres "standards").
En fait, il semblerait que ceci soit lié au format de la date dans mes
logs.
Ainsi, ces derniers sont écrits sous la forme suivante :
"2022-11-07T14:02:20.160314+01:00 mamachine event[4999]:"
Or, les expressions régulières visant à filtrer une partie des logs
commencent par :
"^\w{3} [ :0-9]{11}"
Logcheck s'attend donc à trouver des dates sous la forme :
"Oct 8 23:59:33"
Je peux bien sûr faire des règles personnalisées avec les bonnes
expressions régulières mais cela m'empêche de reprendre les règles
présentes dans "server" et "workstation".
Auriez-vous une piste de résolution ?
Merci d'avance.
David.
Re: Logcheck et format de date
Il y a une option de rsyslog qui joue la-dessus :
# Use traditional timestamp format.
# To enable high precision timestamps, comment out the following line.
#
$ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat
Il me semble que récemment sa valeur par défaut a changé ce qui
expliquerait ton problème.
Francois Mescam
Le 07/11/2022 à 15:32, David BERCOT a écrit :
Bonjour,
J'utilise Logcheck sur plusieurs systèmes et je me suis rendu compte que
tous les logs remontaient (malgré les filtres "standards").
En fait, il semblerait que ceci soit lié au format de la date dans mes
logs.
Ainsi, ces derniers sont écrits sous la forme suivante :
"2022-11-07T14:02:20.160314+01:00 mamachine event[4999]:"
Or, les expressions régulières visant à filtrer une partie des logs
commencent par :
"^\w{3} [ :0-9]{11}"
Logcheck s'attend donc à trouver des dates sous la forme :
"Oct 8 23:59:33"
Je peux bien sûr faire des règles personnalisées avec les bonnes
expressions régulières mais cela m'empêche de reprendre les règles
présentes dans "server" et "workstation".
Auriez-vous une piste de résolution ?
Merci d'avance.
David.
Logcheck et format de date
Bonjour,
J'utilise Logcheck sur plusieurs systèmes et je me suis rendu compte que
tous les logs remontaient (malgré les filtres "standards").
En fait, il semblerait que ceci soit lié au format de la date dans mes logs.
Ainsi, ces derniers sont écrits sous la forme suivante :
"2022-11-07T14:02:20.160314+01:00 mamachine event[4999]:"
Or, les expressions régulières visant à filtrer une partie des logs
commencent par :
"^\w{3} [ :0-9]{11}"
Logcheck s'attend donc à trouver des dates sous la forme :
"Oct 8 23:59:33"
Je peux bien sûr faire des règles personnalisées avec les bonnes
expressions régulières mais cela m'empêche de reprendre les règles
présentes dans "server" et "workstation".
Auriez-vous une piste de résolution ?
Merci d'avance.
David.
Re: Changes in the syslog date format?
On Sat, Nov 05, 2022 at 05:12:40PM +0100, local10 wrote: > Nov 5, 2022, 15:30 by g...@wooledge.org: > > >> > > local10 wrote: > >> > > > >> > > > Any ideas as to get the old syslog date format back? > >> > > > > What caused a change? > > > > > Who knows? I suspect [UPGRADE] rsyslog:amd64 8.2210.0-1 -> 8.2210.0-3 that > happened around November 4, 2022. https://metadata.ftp-master.debian.org/changelogs//main/r/rsyslog/rsyslog_8.2210.0-3_changelog rsyslog (8.2210.0-3) unstable; urgency=medium [...] * Enable high precision timestamps with timezone information. Use the default rsyslog file format, which provides several benefits like: - sortable - time zone information - sub-second time resolution Testing and unstable users ought to expect changes, and they ought to be self-aware enough to include "I'm running testing" in their emails.
[SOLVED] Re: Changes in the syslog date format?
Nov 5, 2022, 14:53 by j...@k4vqc.com: > On Sat, 2022-11-05 at 11:34 +0100, local10 wrote: > >> Nov 5, 2022, 09:55 by scdbac...@gmx.net: >> >> > Hi, >> > >> > local10 wrote: >> > >> > > Any ideas as to get the old syslog date format back? >> > > >> > >> > The internet points to /etc/rsyslog.conf and in there: >> > >> > # >> > # Use traditional timestamp format. >> > # To enable high precision timestamps, comment out the following line. >> > # >> > $ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat >> > >> >> >> Doesn't seem to work for me. >> > > Didn't work for me earlier. To fix this I had to add > > $template normal,"<%PRI%>%TIMESTAMP% %syslogtag%%msg%" > Got it working. Apparently, the $ActionFileDefaultTemplate directive is place sensitive and must be placed under the the GLOBAL DIRECTIVES section. Didn't work for me when it was placed at the end of rsyslog.conf file. Pretty strange. ### #### GLOBAL DIRECTIVES ### # # Set the default permissions for all log files. # $FileOwner root $FileGroup adm $FileCreateMode 0640 $DirCreateMode 0755 $Umask 0022 ## Enable old syslog date format $ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat Thanks to everyone who responded.
