Re: systemd-resolved resolving fails sometimes on Debian12

ian 12 cloud images. In most cases, I don't recommend removing systemd-resolved, as it is responsible for managing the contents of /etc/resolv.conf based on the information provided in the DHCP lease. If you're managing /etc/resolv.conf yourself, then you can remove systemd-resolved. > &g

Re: inconsistency in the symlinks under /etc/systemd

On Wed 10 Apr 2024 at 14:36:20 (-0400), Jeffrey Walton wrote: > On Wed, Apr 10, 2024 at 7:00 AM Vincent Lefevre wrote: > > > > On one machine, I have > > > > lrwxrwxrwx 1 root root 35 2023-10-07 13:43:24 > > /etc/systemd/system/sockets.target.wants/dm-event.sock

Re: inconsistency in the symlinks under /etc/systemd

rhaps bugs are being fixed > > in package installation support programs. You should be able > > to see the symlinks being created in /var/log/apt/term.log* > > if they haven't yet rotated away. > > On the first machine: > > Setting up dmeventd (2:1.02.185-2) ... > Created

Re: inconsistency in the symlinks under /etc/systemd

ing created in /var/log/apt/term.log* > if they haven't yet rotated away. On the first machine: Setting up dmeventd (2:1.02.185-2) ... Created symlink /etc/systemd/system/sockets.target.wants/dm-event.socket → /lib/systemd/system/dm-event.socket. Setting up lvm2 (2.03.16-2) ... Created syml

Re: inconsistency in the symlinks under /etc/systemd

On Thu 11 Apr 2024 at 03:36:59 (+0200), Vincent Lefevre wrote: > On 2024-04-10 09:52:51 -0400, Dan Purgert wrote: > > I'd hazard it's a consequence of usrmerge being the "default state" in > > one installation and not the other. > > Both machines have always been usr-merged (i.e. from the Debian

Re: inconsistency in the symlinks under /etc/systemd

On 2024-04-10 09:52:51 -0400, Dan Purgert wrote: > I'd hazard it's a consequence of usrmerge being the "default state" in > one installation and not the other. Both machines have always been usr-merged (i.e. from the Debian installation). -- Vincent Lefèvre - Web:

Re: inconsistency in the symlinks under /etc/systemd

On Wed, Apr 10, 2024 at 7:00 AM Vincent Lefevre wrote: > > On one machine, I have > > lrwxrwxrwx 1 root root 35 2023-10-07 13:43:24 > /etc/systemd/system/sockets.target.wants/dm-event.socket -> > /lib/systemd/system/dm-event.socket > > and on another one, I have &g

Re: inconsistency in the symlinks under /etc/systemd

On Wed 10 Apr 2024 at 12:33:21 (+0200), Vincent Lefevre wrote: > On one machine, I have > > lrwxrwxrwx 1 root root 35 2023-10-07 13:43:24 > /etc/systemd/system/sockets.target.wants/dm-event.socket -> > /lib/systemd/system/dm-event.socket > > and on another one, I hav

Re: inconsistency in the symlinks under /etc/systemd

On Apr 10, 2024, Vincent Lefevre wrote: > Hi, > > On one machine, I have > > lrwxrwxrwx 1 root root 35 2023-10-07 13:43:24 > /etc/systemd/system/sockets.target.wants/dm-event.socket -> > /lib/systemd/system/dm-event.socket > > and on another one, I have > &g

inconsistency in the symlinks under /etc/systemd

Hi, On one machine, I have lrwxrwxrwx 1 root root 35 2023-10-07 13:43:24 /etc/systemd/system/sockets.target.wants/dm-event.socket -> /lib/systemd/system/dm-event.socket and on another one, I have lrwxrwxrwx 1 root root 39 2024-01-05 16:54:09 /etc/systemd/system/sockets.target.wants

Re: systemd-resolved resolving fails sometimes on Debian12

ch of them with dig example.org @ If that doesn't work for one of them, this must be fixed and is not a problem of IPv6 nor of systemd-resolve. -- Gruß Marco Send spam to 1709388361mu...@cartoonies.org

Re: systemd-resolved resolving fails sometimes on Debian12

On 3/3/24 22:39, Victor Sudakov wrote: jeremy ardley wrote: On 3/3/24 12:43, Victor Sudakov wrote: Not that I would use bind9 as a caching resolver but still, how do you pass the dynamically obtained AWS DNS server address from systemd-networkd to bind9 ? The AWS DNS resolver IPs

Re: systemd-resolved resolving fails sometimes on Debian12

jeremy ardley wrote: > > On 3/3/24 12:43, Victor Sudakov wrote: > > Not that I would use bind9 as a caching resolver but still, how > > do you pass the dynamically obtained AWS DNS server address from > > systemd-networkd to bind9 ? > > > The AWS DNS resol

Re: systemd-resolved resolving fails sometimes on Debian12

On 3/3/24 12:43, Victor Sudakov wrote: Not that I would use bind9 as a caching resolver but still, how do you pass the dynamically obtained AWS DNS server address from systemd-networkd to bind9 ? The AWS DNS resolver IPs are static and are widely published. It is permissible to not use AWS

Re: systemd-resolved resolving fails sometimes on Debian12

jeremy ardley wrote: > > On 2/3/24 23:06, Victor Sudakov wrote: > > You know, the official Debian 12 AMI for AWS is built on > > systemd-resolved and systemd-networkd. I'd prefer not to have to > > modify the official AMI if I can help it, because this would probably

Re: systemd-resolved resolving fails sometimes on Debian12

On 2/3/24 23:06, Victor Sudakov wrote: You know, the official Debian 12 AMI for AWS is built on systemd-resolved and systemd-networkd. I'd prefer not to have to modify the official AMI if I can help it, because this would probably mean also replacing the systemd-networkd with some other

Re: systemd-resolved resolving fails sometimes on Debian12

jeremy ardley wrote: > > On 1/3/24 17:47, Victor Sudakov wrote: > > Has anybody encountered this problem using systemd-resolved as a > > resolver on Debian12? A DNS request via systemd-resolved fails, but > > fails only occasionally. A failure can happen once per a hundred

Re: systemd-resolved resolving fails sometimes on Debian12

On 1/3/24 17:47, Victor Sudakov wrote: Has anybody encountered this problem using systemd-resolved as a resolver on Debian12? A DNS request via systemd-resolved fails, but fails only occasionally. A failure can happen once per a hundred successful requests or so. If I run: I recall

systemd-resolved resolving fails sometimes on Debian12

Dear Colleagues, Has anybody encountered this problem using systemd-resolved as a resolver on Debian12? A DNS request via systemd-resolved fails, but fails only occasionally. A failure can happen once per a hundred successful requests or so. If I run: while resolvectl query myredis.my.domain

Re: Many systemd units do not start anymore

Am 07.02.24 um 13:07 schrieb Christoph Pleger: Hello, Am Mittwoch, dem 07.02.2024 um 12:27 +0100 schrieb Michael Biebl: Am 07.02.24 um 11:32 schrieb Christoph Pleger: Hello, systemd-time-wait-sync.service is running but has not completed. I wonder if that is https://bugs.debian.org/cgi-bin

Re: Many systemd units do not start anymore

Hello, Am Mittwoch, dem 07.02.2024 um 12:27 +0100 schrieb Michael Biebl: > Am 07.02.24 um 11:32 schrieb Christoph Pleger: > > Hello, > > > > > > > > systemd-time-wait-sync.service is running but has not completed. > > > I wonder if that is > > >

Re: Many systemd units do not start anymore

Am 07.02.24 um 11:32 schrieb Christoph Pleger: Hello, systemd-time-wait-sync.service is running but has not completed. I wonder if that is https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=940840 https://github.com/systemd/systemd/issues/14061 Which NTP service do you use? I am using

Re: Many systemd units do not start anymore

ted the machine, maybe I did something else before, but I do not remember. > - you say it is just one of your server machines. Can you draw any >   comparisons with the state of your other server machines? The difference is that this machine chrony as ntp server/client, while on most

Re: Many systemd units do not start anymore

Hello, > > systemd-time-wait-sync.service is running but has not completed. > I wonder if that is > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=940840 > https://github.com/systemd/systemd/issues/14061 > > Which NTP service do you use? I am using chrony, because t

Re: Many systemd units do not start anymore

Christoph Pleger wrote: > Hello, > > on one of my server machines, suddenly many systemd units (e.g. cron, > autofs) do not start any more, neither at boot nor when trying to > start manually with "systemctl start ", this hangs till I abort > with Ctrl-C -

Re: Many systemd units do not start anymore

On Tue 06 Feb 2024 at 09:51:02 (+0700), Max Nikulin wrote: > On 06/02/2024 03:46, Michael Biebl wrote: > > If you are not using systemd-timesyncd, you could also consider > > disabling systemd-time-wait-sync.service (via systemctl disable). > > My guess is that this board

Re: Many systemd units do not start anymore

On 06/02/2024 03:46, Michael Biebl wrote: If you are not using systemd-timesyncd, you could also consider disabling systemd-time-wait-sync.service (via systemctl disable). My guess is that this board does not have RTC, so NTP is a must have and dependency on time synchronization

Re: Many systemd units do not start anymore

tart waiting > 86 logrotate.timer start waiting > 83 man-db.timer start waiting > 84 apt-daily-upgrade.timer start waiting > 115 systemd-update-utmp-runlevel.service start waiting > 135 atd.service

Re: Many systemd units do not start anymore

  nslcd.service    start waiting 40  time-sync.target start waiting 86  logrotate.timer  start waiting 83  man-db.timer start waiting 84  apt-daily-upgrade.timer  start waiting 115 systemd-update-utmp

Re: Many systemd units do not start anymore

time-sync.target start waiting 86 logrotate.timer start waiting 83 man-db.timer start waiting 84 apt-daily-upgrade.timer start waiting 115 systemd-update-utmp-runlevel.service start waiting 135 atd.service

Re: Many systemd units do not start anymore

? systemctl --failed Is there anything suspicious in output of journalctl --boot dmesg Are there active processes in "top" output? I am unsure if the following commands will provide anything useful in such state systemd-analyze blame systemd-analyze critical-chain A

Re: Many systemd units do not start anymore

start waiting 115 systemd-update-utmp-runlevel.service start waiting 135 atd.service start waiting 79 timers.targetstart waiting 87 apt-daily.timer start waiting 39 systemd-time-wait-sync.service start running 88

Re: Many systemd units do not start anymore

пн, 5 февр. 2024 г. в 20:57, Christoph Pleger : > Unfortunately, there is no useful further information: > > systemctl status > ● autofs.service - Automounts filesystems on demand > Loaded: loaded (/lib/systemd/system/autofs.service; enabled; > vendor preset> >

Re: Many systemd units do not start anymore

Hello, Am Montag, dem 05.02.2024 um 07:18 -0500 schrieb Greg Wooledge: > On Mon, Feb 05, 2024 at 12:53:33PM +0100, Christoph Pleger wrote: > > on one of my server machines, suddenly many systemd units (e.g. cron, > > autofs) > > do not start any more, neither at boot nor

Re: Many systemd units do not start anymore

On Mon, Feb 05, 2024 at 12:53:33PM +0100, Christoph Pleger wrote: > on one of my server machines, suddenly many systemd units (e.g. cron, autofs) > do not start any more, neither at boot nor when trying to start manually > with "systemctl start ", this hangs till I abort wi

Many systemd units do not start anymore

Hello, on one of my server machines, suddenly many systemd units (e.g. cron, autofs) do not start any more, neither at boot nor when trying to start manually with "systemctl start ", this hangs till I abort with Ctrl-C - though the commands defined in ExecStart work when I type them i

Re: VAX emulation/simulation (was Re: systemd-timesyncd)

On 1/9/24 03:15, Thomas Schmitt wrote: Hi, Nicholas Geovanis wrote: You ruined my day :-) It was not my fault. Send complaints to the people who convened as "High Sierra Group" in 1986. Something similar to IBM's kludgiest relic of the early 1960s has appeared in linux? The unixoid

Re: VAX emulation/simulation (was Re: systemd-timesyncd)

Bret Busby (12024-01-09): > Whilst, as I previously made the point, this is all off-topic for a Debian > operating system users mailing list, one (and, only one) of the applications > of version numbers as part of file descriptors, with (in the case of > VAX/VMS) up to the last seven versions of a

Re: VAX emulation/simulation (was Re: systemd-timesyncd)

Hi, Bret Busby wrote: > Whilst, as I previously made the point, this is all off-topic for a Debian > operating system users mailing list But i found a premium excuse in the debian-cd and debian-live ISOs. :o) > the last seven versions of a file, being retained, was a > useful tool for software

Re: VAX emulation/simulation (was Re: systemd-timesyncd)

On 9/1/24 16:02, Thomas Schmitt wrote: Hi, Nicholas Geovanis wrote: The idea that we need version numbers embedded in filenames involuntarily may be "natural" to somebody. I have never seen any version other than ";1" (and ISOs which simply ignore the specs about file names). It's a

Re: VAX emulation/simulation (was Re: systemd-timesyncd)

Hi, Nicholas Geovanis wrote: > You ruined my day :-) It was not my fault. Send complaints to the people who convened as "High Sierra Group" in 1986. > Something similar to IBM's kludgiest relic of the early 1960s has appeared > in linux? The unixoid community added System Use Protocol and

Re: VAX emulation/simulation (was Re: systemd-timesyncd)

On Mon, Jan 8, 2024, 11:38 AM Thomas Schmitt wrote: > Hi, > > Bret Busby wrote: > > > .; > > Jeremy Nicoll wrote: > > IBM's MVS & its successors, most recently z/OS, have something > > similar called a GDG (or Generation Data Group). > > The principle made it into ISO 9660 specifications. > > To

Re: VAX emulation/simulation (was Re: systemd-timesyncd)

On 8 Jan 2024, at 9:17, Bret Busby wrote: > But, apart from the functionality that I have not seen in any other operating > system, of using an extra file descriptor of version number, so the whole > filename would be something like > .; > (I am not sure whether that syntax is correct - I have

Re: systemd-timesyncd

On 2024-01-07, Andrew M.A. Cater wrote: > >> Take care, stay warm, well, and unvaxed. >> ^^^ > > Gene - no partisan opinions, please, as per Code of Conduct? Nothing sucks like a VAX! > All best, as ever, > > Andy

Re: systemd-timesyncd

On 1/7/24 19:39, Nicholas Geovanis wrote: On Sun, Jan 7, 2024, 4:51 PM Charles Curley > wrote: On Sun, 7 Jan 2024 20:36:12 + "Andrew M.A. Cater" mailto:amaca...@einval.com>> wrote: > > Take care, stay warm, well, and unvaxed. > >   

Re: systemd-timesyncd

On 1/7/24 17:51, Charles Curley wrote: On Sun, 7 Jan 2024 20:36:12 + "Andrew M.A. Cater" wrote: Take care, stay warm, well, and unvaxed. ^^^ Gene - no partisan opinions, please, as per Code of Conduct? Oh, come on! Just because Gene doesn't like

Re: systemd-timesyncd

Is it supposed to be installed by the net-installer? There does not seem > to be any man pages other than the bog std stuff. When I found the > /etc/systemd/timesyncd I immediately asked the system for man timesyncd, > got this: > gene@coyote:/etc$ man timesyncd > No manual entr

Re: VAX emulation/simulation (was Re: systemd-timesyncd)

Hi, Bret Busby wrote: > > .; Jeremy Nicoll wrote: > IBM's MVS & its successors, most recently z/OS, have something > similar called a GDG (or Generation Data Group). The principle made it into ISO 9660 specifications. To make this thread relevant for Debian, let's assume that somebody asked

Re: VAX emulation/simulation (was Re: systemd-timesyncd)

On Mon, 8 Jan 2024, at 09:17, Bret Busby wrote: > But, apart from the functionality that I have not seen in any other > operating system, of using an extra file descriptor of version number, > so the whole filename would be something like > .; IBM's MVS & its successors, most recently z/OS,

Re: VAX emulation/simulation (was Re: systemd-timesyncd)

On 8/1/24 08:44, The Wanderer wrote: On 2024-01-07 at 19:20, Nicholas Geovanis wrote: On Sun, Jan 7, 2024, 4:51 PM Charles Curley wrote: On Sun, 7 Jan 2024 20:36:12 + "Andrew M.A. Cater" wrote: Gene - no partisan opinions, please, as per Code of Conduct? Oh, come on! Just because

Re: systemd-timesyncd

> Quit using Google search. Use DuckDuckGo. Use StartPage instead, aka ixquick.com -- System Information GTK 3.24.39 / GLib 2.78.3 Locale: en_US.UTF-8 (charset: UTF-8) Operating System: Linux 6.6.9-amd64 (x86_64)

Re: systemd-timesyncd

On Mon, 8 Jan 2024 10:02:25 +0700 Max Nikulin wrote: > Isn't it /etc/systemd/timesyncd.conf, not /etc/systemd/timesyncd? It > might be a reason why systemd-timesyncd did not follow configuration. It is indeed /etc/systemd/timesyncd.conf. However, there is also /etc/systemd/timesyncd.

Re: systemd-timesyncd

manpages (as noted in a message above earlier in the thread). Just to avoid possible confusion. Installing of the manpages package will not make man pages for all debian packages available locally. E.g. systemd-timesyncd(8) is shipped in the systemd-timesyncd package. It is great that https

Re: systemd-timesyncd

On 08/01/2024 02:51, gene heskett wrote: When I found the /etc/systemd/timesyncd I immediately asked the system for man timesyncd, got this: gene@coyote:/etc$ man timesyncd No manual entry for timesyncd Isn't it /etc/systemd/timesyncd.conf, not /etc/systemd/timesyncd? It might be a reason

VAX emulation/simulation (was Re: systemd-timesyncd)

On 2024-01-07 at 19:20, Nicholas Geovanis wrote: > On Sun, Jan 7, 2024, 4:51 PM Charles Curley > wrote: > >> On Sun, 7 Jan 2024 20:36:12 + >> >> "Andrew M.A. Cater" wrote: >>> Gene - no partisan opinions, please, as per Code of Conduct? >> >> Oh, come on! Just because Gene doesn't like

Re: systemd-timesyncd

On Sun, Jan 7, 2024, 4:51 PM Charles Curley wrote: > On Sun, 7 Jan 2024 20:36:12 + > "Andrew M.A. Cater" wrote: > > > > Take care, stay warm, well, and unvaxed. > > > ^^^ > > > > Gene - no partisan opinions, please, as per Code of Conduct? > > Oh, come

Re: systemd-timesyncd

On Sun, 7 Jan 2024 20:36:12 + "Andrew M.A. Cater" wrote: > > Take care, stay warm, well, and unvaxed. > > ^^^ > > Gene - no partisan opinions, please, as per Code of Conduct? Oh, come on! Just because Gene doesn't like certain ancient Digital Equipment

Re: systemd-timesyncd

Hi Gene, Am 07.01.2024 um 20:51 schrieb gene heskett: On 1/7/24 10:48, Max Nikulin wrote: ... systemd-timesyncd is a NTP-client, not a server. It is shipped with man pages and works out of the box (of course, if network is properly configured). Is it supposed to be installed by the net

Re: systemd-timesyncd

d stuff. When I found the > /etc/systemd/timesyncd I immediately asked the system for man timesyncd, got > this: > gene@coyote:/etc$ man timesyncd > No manual entry for timesyncd > > > What package contains the manpages for a bookworm amd64 install I expect to > do anything

Re: systemd-timesyncd

On 1/7/24 11:24, John Hasler wrote: Gene writes: Lately, everytime I go anywhere near google or a gmail link I get attacked by a virus that calls itself norton antivirus. Delete all your Firefox caches and upgrade Firefox. That phishing malware has nothing to do with Google or Norton. You

Re: systemd-timesyncd

malware you have on your machines. systemd-timesyncd is a NTP-client, not a server. It is shipped with man pages and works out of the box (of course, if network is properly configured). Is it supposed to be installed by the net-installer? There does not seem to be any man pages other than the bog

Re: systemd-boot not asking password, not resuming from hibernate

On 07.01.24 18:07, David Wright wrote: On Sat 06 Jan 2024 at 20:04:57 (+0100), Richard Rosner wrote: I just tried out systemd-boot. What I noticed, it doesn't ask for my decryption password to decrypt both my LUKS2 encrypted root and swap partition. This kinda defeats the purpose of encrypted

Re: tzdata-legacy [was: Re: systemd and timezone]

On Sat 06 Jan 2024 at 02:57:53 (-0600), Nate Bargmann wrote: > * On 2024 06 Jan 01:00 -0600, Max Nikulin wrote: > > US/Eastern & Co has been moved to tzdata-legacy as well. Currently used > > identifiers are based on cities: America/New_York. > > Ugghhh! > > I guess I'll be going to the legacy

Re: systemd-boot not asking password, not resuming from hibernate

On Sat 06 Jan 2024 at 20:04:57 (+0100), Richard Rosner wrote: > I just tried out systemd-boot. What I noticed, it doesn't ask for my > decryption password to decrypt both my LUKS2 encrypted root and swap > partition. This kinda defeats the purpose of encrypted drives. How do > I have

Re: systemd-timesyncd

Gene writes: > Lately, everytime I go anywhere near google or a gmail link I get > attacked by a virus that calls itself norton antivirus. Delete all your Firefox caches and upgrade Firefox. That phishing malware has nothing to do with Google or Norton. You acquired it by visiting an infected

systemd-timesyncd

. systemd-timesyncd is a NTP-client, not a server. It is shipped with man pages and works out of the box (of course, if network is properly configured).

manpages package [WAS Re: SOLVED FOR GENE:Re: was: Re: tzdata-legacy [was: Re: systemd and timezone]

On Sat, Jan 06, 2024 at 01:17:13PM -0600, John Hasler wrote: > Try manpages.org . > -- > John Hasler > j...@sugarbit.com > Elmwood, WI USA > If you're on a Debian system, this should already be installed but otherwise apt-get install manpages Also - manpages.debian.org gives you a searchable

Re: was: Re: tzdata-legacy [was: Re: systemd and timezone]

if you do not use search engines for some reason, have you tried to ask at least systemd itself?     systemctl help systemd-timesyncd Does not exist as I manually deleted it and installed ntpsec when I could not find any docs to help make it work. I needed a timeserver that did not depend

Re: SOLVED FOR GENE:Re: was: Re: tzdata-legacy [was: Re: systemd and timezone]

Try manpages.org . -- John Hasler j...@sugarbit.com Elmwood, WI USA

systemd-boot not asking password, not resuming from hibernate

I just tried out systemd-boot. What I noticed, it doesn't ask for my decryption password to decrypt both my LUKS2 encrypted root and swap partition. This kinda defeats the purpose of encrypted drives. How do I have systemd-boot forget and never again remember my credentials

SOLVED FOR GENE:Re: was: Re: tzdata-legacy [was: Re: systemd and timezone]

On 1/6/24 09:25, John Hasler wrote: The documentation for Chrony is: chrony.conf (5) - chronyd configuration file chronyc (1) - command-line interface for chrony daemon chronyd (8) - chrony daemon Also see /usr/share/doc/chrony . Don't use "pool" to sync to a single

Re: was: Re: tzdata-legacy [was: Re: systemd and timezone]

for some reason, have you tried to ask at least systemd itself? systemctl help systemd-timesyncd

Re: tzdata-legacy [was: Re: systemd and timezone]

On Sat, Jan 06, 2024 at 02:57:53AM -0600, Nate Bargmann wrote: > I really don't get the fascination with some city hundreds of miles > distant defining the time zone. Why Chicago for US/Central? There are > any number of cities in US/Central that could be referenced, but no, > pick the most

Re: was: Re: tzdata-legacy [was: Re: systemd and timezone]

The documentation for Chrony is: chrony.conf (5) - chronyd configuration file chronyc (1) - command-line interface for chrony daemon chronyd (8) - chrony daemon Also see /usr/share/doc/chrony . Don't use "pool" to sync to a single source. Use "server". man chrony.conf

Re: tzdata-legacy [was: Re: systemd and timezone]

On 1/6/24 04:15, Nate Bargmann wrote: * On 2024 06 Jan 01:00 -0600, Max Nikulin wrote: US/Eastern & Co has been moved to tzdata-legacy as well. Currently used identifiers are based on cities: America/New_York. Ugghhh! I guess I'll be going to the legacy package then until

was: Re: tzdata-legacy [was: Re: systemd and timezone]

On 1/6/24 01:18, Max Nikulin wrote: On 06/01/2024 12:18, gene heskett wrote: On 1/5/24 23:29, Greg Wooledge wrote: On Fri, Jan 05, 2024 at 09:01:29PM -0500, Charles Kroeger wrote: tzdata (2023d-1) unstable; urgency=medium upstream backward file) were moved to tzdata-legacy. This

Re: tzdata-legacy [was: Re: systemd and timezone]

* On 2024 06 Jan 01:00 -0600, Max Nikulin wrote: > US/Eastern & Co has been moved to tzdata-legacy as well. Currently used > identifiers are based on cities: America/New_York. Ugghhh! I guess I'll be going to the legacy package then until $WHOEVER_IS_IN_CHARGE issues a decree that it too shall

Re: tzdata-legacy [was: Re: systemd and timezone]

On 06/01/2024 13:02, Max Nikulin wrote: The change affects those who rely on POSIX-like EST5EDT timezones or on obsolete ones like Europe/Kyiv (recently renamed from Europe/Kiev). Europe/Kiev (moved to tzdata-legacy) was renamed to Europe/Kyiv. Sorry for confusion. US/Eastern & Co has been

tzdata-legacy [was: Re: systemd and timezone]

On 06/01/2024 12:18, gene heskett wrote: On 1/5/24 23:29, Greg Wooledge wrote: On Fri, Jan 05, 2024 at 09:01:29PM -0500, Charles Kroeger wrote: tzdata (2023d-1) unstable; urgency=medium upstream backward file) were moved to tzdata-legacy. This includes the What's wrong with NTP, too

Re: systemd and timezone

On 1/5/24 23:29, Greg Wooledge wrote: On Fri, Jan 05, 2024 at 09:01:29PM -0500, Charles Kroeger wrote: tzdata (2023d-1) unstable; urgency=medium From 2023c-8 on the tzdata package ships only timezones that follow the current rules of geographical region (continent or ocean) and city

Re: systemd and timezone

On Fri, Jan 05, 2024 at 09:01:29PM -0500, Charles Kroeger wrote: > tzdata (2023d-1) unstable; urgency=medium > > From 2023c-8 on the tzdata package ships only timezones that follow the > current rules of geographical region (continent or ocean) and city name. > All legacy timezone

Re: systemd and timezone

apt-listchanges: News - tzdata (2023d-1) unstable; urgency=medium From 2023c-8 on the tzdata package ships only timezones that follow the current rules of geographical region (continent or ocean) and city name. All legacy timezone symlinks (old or merged timezones

Re: mktime (was: Re: systemd and timezone)

On Sat, Dec 23, 2023 at 01:09:02PM -0500, Jeffrey Walton wrote: [...] > On Sat, Dec 23, 2023 at 11:56 AM Max Nikulin wrote: > Here's what someone on the libc mailing list suggested: [...] > The person also suggested using Gnulib. My project was not using > Gnulib, so it was not an option.

Re: mktime (was: Re: systemd and timezone)

On Sat, Dec 23, 2023 at 11:56 AM Max Nikulin wrote: > > On 23/12/2023 02:41, Jeffrey Walton wrote: > > I've found lack of per-thread timezones and libc's inability to > > convert time between timezones a bigger problem than other issues, > > like explicitly setting a timezone for a process. > >

mktime (was: Re: systemd and timezone)

On 23/12/2023 02:41, Jeffrey Walton wrote: I've found lack of per-thread timezones and libc's inability to convert time between timezones a bigger problem than other issues, like explicitly setting a timezone for a process. From my point of view the TZ environment variable makes timezone

Re: systemd and timezone

g late boot,   instead of being mounted by the initrd before switching to the rootfs)   and unmerged-usr (parallel directories /bin/ and /usr/bin/, /lib/ and   /usr/lib/, …) has been removed. For more details, see: https://lists.freedesktop.org/archives/systemd-deve

Re: Support for SysV service scripts deprecated in systemd 255 (was: systemd and timezone)

ib/, …) has been removed. For more details, see: >> https://lists.freedesktop.org/archives/systemd-devel/2022-September/048352.html >>     * Support for System V service scripts is now deprecated and >> will be >>   removed in a future release. Please make sure to update

Re: systemd and timezone

t;   and unmerged-usr (parallel directories /bin/ and /usr/bin/, > /lib/ and >   /usr/lib/, …) has been removed. For more details, see: > https://lists.freedesktop.org/archives/systemd-devel/2022-September/048352.html > > >     * Support for System V service sc

Re: systemd and timezone

On Fri 22 Dec 2023 at 14:54:13 (-0500), Greg Wooledge wrote: > On Fri, Dec 22, 2023 at 01:29:09PM -0600, David Wright wrote: > > With the proviso that I don't know what "restorecon" does in > > postinst scripts, this list of .debs has been prefixed by > > c for copy and l for link: > > > >

Re: systemd and timezone

On Fri, Dec 22, 2023 at 06:36:55PM -0600, Nate Bargmann wrote: > In Debian releases between Etch and Jessie (inclusive), It's a wiki. I assumed it would be clear in context, due to the paragraphs before and after it, but if you want to change the wording, change it.

Re: systemd and timezone

* On 2023 22 Dec 15:34 -0600, Greg Wooledge wrote: > On Fri, Dec 22, 2023 at 08:59:42PM +0100, Sven Joachim wrote: > > 1. https://bugs.debian.org/803144 > > 2. https://bugs.debian.org/346342 > > Wow, OK. Fascinating historical context in there. > > I've updated

Re: systemd and timezone

tching to the rootfs)   and unmerged-usr (parallel directories /bin/ and /usr/bin/, /lib/ and   /usr/lib/, …) has been removed. For more details, see: https://lists.freedesktop.org/archives/systemd-devel/2022-September/048352.html     * Support for System V service scripts

Re: systemd and timezone

726256) Cheers, David. Systemd no longer supports a split /usr -- Hindi madali ang maging ako

Re: systemd and timezone

On Fri 22 Dec 2023 at 16:16:07 (-0500), Greg Wooledge wrote: > On Fri, Dec 22, 2023 at 08:59:42PM +0100, Sven Joachim wrote: > > 1. https://bugs.debian.org/803144 > > 2. https://bugs.debian.org/346342 > > Wow, OK. Fascinating historical context in there. > > I've updated

Re: systemd and timezone

Jeffrey Walton (12023-12-22): > I've found lack of per-thread timezones and libc's inability to > convert time between timezones a bigger problem than other issues, > like explicitly setting a timezone for a process. Unix API makes an habit of this kind of thing. Often, it is because the feature

Re: systemd and timezone

On Fri, Dec 22, 2023 at 08:59:42PM +0100, Sven Joachim wrote: > 1. https://bugs.debian.org/803144 > 2. https://bugs.debian.org/346342 Wow, OK. Fascinating historical context in there. I've updated . I believe it's correct now, for both current and

Re: systemd and timezone

On 2023-12-22 11:11 -0500, Greg Wooledge wrote: > On Fri, Dec 22, 2023 at 09:30:23AM -0600, David Wright wrote: >> https://wiki.debian.org/TimeZoneChanges >> >> still says: >> >> "In Debian releases Etch and later, /etc/localtime is a copy of the >> original data file. Check the contents of

Re: systemd and timezone

On Fri, Dec 22, 2023 at 01:29:09PM -0600, David Wright wrote: > With the proviso that I don't know what "restorecon" does in > postinst scripts, this list of .debs has been prefixed by > c for copy and l for link: > > l-tzdata_2007b-1_all.deb > l-tzdata_2008e-1etch3_all.deb >

Re: systemd and timezone

On Fri, Dec 22, 2023 at 8:33 AM wrote: > > On Fri, Dec 22, 2023 at 07:26:37PM +0700, Max Nikulin wrote: > > [...] > > /etc/localtime is a global setting. Its change may affect all users not > > having explicit TZ. Something better than libc is required for an > > application (especially

Re: systemd and timezone

On Fri, Dec 22, 2023 at 07:56:56PM +0100, Arno Lehmann, ITS wrote: > I have Etch running here, and the /etc/localtime file is not a symlink, nor > a hardlink to a zone file: > > TomBombadil:~# ls -lhi /etc/timezone /etc/localtime > 159667 -rw-r--r-- 1 root root 842 2020-11-14 18:27 /etc/localtime

  1   2   3   4   5   6   7   8   9   10   >