Re: systemd may silently break your system!

On 2024-08-01 23:17:42 -0400, Jeffrey Walton wrote: > The reference also says: > > Only pure stable release with security updates provides the best > stability. But stable does not mean bugless. Unfortunately stable sometimes has major bugs, and the only thing to do is to wait for the nex

Re: systemd may silently break your system!

people trying to use > > this as a daily driver and having weird expectations. And then some > > sort of triggering around anything involving systemd. > > > > I feel like we see it more and more, these expectations about sid, > > and I don't understand why. > &g

Re: systemd may silently break your system!

ple trying to use > > this as a daily driver and having weird expectations. And then some > > sort of triggering around anything involving systemd. > > > > I feel like we see it more and more, these expectations about sid, > > and I don't understand why. >

Re: systemd may silently break your system!

ns. And then some > sort of triggering around anything involving systemd. > > I feel like we see it more and more, these expectations about sid, > and I don't understand why. There are people who have become invested in the idea that sid is "stable enough" and have

Re: systemd may silently break your system!

Am Do, Aug 01, 2024 at 14:08:21 + schrieb Andy Smith: I feel like we see it more and more, these expectations about sid, and I don't understand why. Maybe because these bugs have already reached testing? My testing system has this buggy version of procps. Interestingly /etc/sysctl.conf is

Re: systemd may silently break your system!

On Thu, Aug 01, 2024 at 16:03:32 +0200, Vincent Lefevre wrote: > so the silent breakage was known and done on purpose. ... OK, you're just living in a personal fantasy. There's nothing more to be gained by trying to interact with you on this topic, so I'm going to stop now.

Re: systemd may silently break your system!

Vincent Lefevre (12024-08-01): > so the silent breakage was known and done on purpose. Cutting yourself on Hanlon's Razor. -- Nicolas George

Re: systemd may silently break your system!

Hi, On Thu, Aug 01, 2024 at 09:37:54AM -0400, Greg Wooledge wrote: > I see NO reason to point fingers of blame at systemd (cf. Subject:). > > I see nothing amiss here in the order in which packages were uploaded. > > I see NO reason that these two packages have to be upgrade

Re: systemd may silently break your system!

situation: > > 1) A new procps package was uploaded, which no longer has /etc/sysctl.conf. > > 2) A new systemd package was uploaded, which removes the now-dangling > /etc/sysctl.d/99-whatever symlink. > > 3) It was discovered that the new procps package fails to remov

Re: systemd may silently break your system!

s /etc/sysctl.conf. 2) A new systemd package was uploaded, which removes the now-dangling /etc/sysctl.d/99-whatever symlink. 3) It was discovered that the new procps package fails to remove the existing /etc/sysctl.conf file when upgrading. This was filed as a bug, and will be fixed a

Re: systemd may silently break your system!

7:56 -0500, David Wright wrote: > > > > > It looks accidental to me that systemd did that tidying up before > > > > > procps had attempted to remove the file that it (procps) owned. > > > > > > > > No, the breakage was done on purpose: my bug repo

Re: systemd may silently break your system!

On 2024-07-28 22:26:10 -0500, David Wright wrote: > On Sun 28 Jul 2024 at 16:43:01 (+0200), Vincent Lefevre wrote: > > On 2024-07-28 00:07:56 -0500, David Wright wrote: > > > It looks accidental to me that systemd did that tidying up before > > > procps had attempted

Re: Upgrading systemd may silently break your Unstable/Sid system!

see this change in a > changelog and apt-listchanges didn't say a word about this. > > As far as filing a bug report? Since the symlink is now gone I'm not > even sure there's a bug to file :) Well, yes, but IMHO not against systemd, but procps, for abandoning its con

Re: Upgrading systemd may silently break your Unstable/Sid system!; was: systemd may silently break your system!

On Mon 29 Jul 2024 at 09:23:16 (+0700), Max Nikulin wrote: > On 28/07/2024 20:08, Erwan David wrote: > > I also have a 99-systcl.conf which is a copy of the former /etc/sysctl.conf > > When you are going to replace a file provided by a package, check if > it is a configuration file at first (e.g.

Re: systemd may silently break your system!

Sun, Jul 28, 2024 at 01:17:19 +0200, Vincent Lefevre wrote: > > > > > The configuration got broken by a *systemd* upgrade: > > > > > > > > > > * Drop /etc/sysctl.d/99-sysctl.conf symlink procps no longer ships > > > > > /etc/sysctl.conf (

Re: Upgrading systemd may silently break your Unstable/Sid system!; was: systemd may silently break your system!

On 28/07/2024 20:08, Erwan David wrote: I also have a 99-systcl.conf which is a copy of the former /etc/sysctl.conf When you are going to replace a file provided by a package, check if it is a configuration file at first (e.g. dpkg -s). Despite most of files in /etc/ are marked as configurati

Re: Upgrading systemd may silently break your Unstable/Sid system!

inux-sysctl-defaults > Bug fixed by upload, closed. > > 2024-07-11: procps (unstable) upload: /etc/sysctl.conf is "removed" > (but not when upgrading) > Closes #1074156 > > 2024-07-12: bug #1076190 filed against package systemd > Installs danglin

Re: Upgrading systemd may silently break your Unstable/Sid system!

l-defaults Bug fixed by upload, closed. 2024-07-11: procps (unstable) upload: /etc/sysctl.conf is "removed" (but not when upgrading) Closes #1074156 2024-07-12: bug #1076190 filed against package systemd Installs dangling symlink /etc/sysctl.d/99-sysctl.conf Bug fixe

Re: systemd may silently break your system!

On 2024-07-28 11:21:01 -0400, Greg Wooledge wrote: > On Sun, Jul 28, 2024 at 16:43:01 +0200, Vincent Lefevre wrote: > > More or less. In the systemd case, for each file, either one chooses > > it, i.e. one has all the current defaults, or one chooses to provide > > a replac

Re: Upgrading systemd may silently break your Unstable/Sid system!

On 2024-07-28 14:13:09 +, Michael Kjörling wrote: > And posting on debian-user with a bombastic Subject line which implies > that this is a widespread issue when it really only seems to exist in > Unstable is, quite frankly, in my opinion at best dishonest. No, the breakage was done *on purpos

Re: systemd may silently break your system!

On Sun, Jul 28, 2024 at 16:43:01 +0200, Vincent Lefevre wrote: > More or less. In the systemd case, for each file, either one chooses > it, i.e. one has all the current defaults, or one chooses to provide > a replacement under /etc, i.e. one entirely replaces the defaults by > one&#x

Re: Upgrading systemd may silently break your Unstable/Sid system!

I've run Sid exclusively for years; the last time I broke it badly enough to justify a reinstall was in 2013 and that was for not paying attention during an upgrade :) My heartburn is I would have expected to see this change in a changelog and apt-listchanges didn't say a word about this. As far

Re: systemd may silently break your system!

On 2024-07-28 00:07:56 -0500, David Wright wrote: > On Sun 28 Jul 2024 at 04:25:32 (+0200), Vincent Lefevre wrote: > > On 2024-07-27 20:25:54 -0400, Greg Wooledge wrote: > > > > On Sun, Jul 28, 2024 at 01:17:19 +0200, Vincent Lefevre wrote: > > > > The confi

Re: Upgrading systemd may silently break your Unstable/Sid system!

_ > When Unstable breaks, as the saying goes, you get to keep both > pieces. (The value of having regular backups is not restricted to > those running Unstable.) FWIW: I'm running testing, not unstable, and I already have the procps change. I'm not sure I ever had the systemd-su

Re: Upgrading systemd may silently break your Unstable/Sid system!

On 28 Jul 2024 15:08 +0200, from er...@rail.eu.org (Erwan David): > Le 28/07/2024 à 14:28, allan a écrit : >> I would agree with you *if* the change had been publicized. > > [...] But in my view it is a bug to remove something else than > the symlink even with the same name At the risk of repeati

Re: Upgrading systemd may silently break your Unstable/Sid system!; was: systemd may silently break your system!

Le 28/07/2024 à 14:28, allan a écrit : I would agree with you *if* the change had been publicized. I found the 99-sysctl.conf symlink accidentally. I removed the symlink and moved sysctl.conf to 99-sysctl.conf since the original config was not being read. This turned out to be a lousy idea sin

Re: Upgrading systemd may silently break your Unstable/Sid system!; was: systemd may silently break your system!

I would agree with you *if* the change had been publicized. I found the 99-sysctl.conf symlink accidentally. I removed the symlink and moved sysctl.conf to 99-sysctl.conf since the original config was not being read. This turned out to be a lousy idea since the symlink was removed with the next

Re: Upgrading systemd may silently break your Unstable/Sid system!; was: systemd may silently break your system!

On 28 Jul 2024 04:25 +0200, from vinc...@vinc17.net (Vincent Lefevre): >> A conffile is user-managed, so any changes you make to a conffile must >> be respected by the package. It can't just overwrite your changes, or >> restore a conffile if you've deleted it. > > This is rather poor design, bec

Re: systemd may silently break your system!

On Sun 28 Jul 2024 at 04:25:32 (+0200), Vincent Lefevre wrote: > On 2024-07-27 20:25:54 -0400, Greg Wooledge wrote: > > On Sun, Jul 28, 2024 at 01:17:19 +0200, Vincent Lefevre wrote: > > > The configuration got broken by a *systemd* upgrade: > > > > > >

Re: systemd may silently break your system!

Vincent Lefevre wrote: The /etc/sysctl.d/99-sysctl.conf symlink has been removed (currently in unstable) *without any announcement*, so that the /etc/sysctl.conf file (which is still documented, BTW) is no longer read. So, be careful if you have important settings there (security...). Thanks

Re: systemd may silently break your system!

/local.conf > > > > No, it does *not* recommend anything: > > > > > > Files located in this directory can set kernel parameters using the > > sysctl(8) or systemd-sysctl(8) tool which is

Re: systemd may silently break your system!

t* recommend anything: > > > Files located in this directory can set kernel parameters using the > sysctl(8) or systemd-sysctl(8) tool which is typically run with a > unit/init file started during the boot sequence. > > For details

Re: systemd may silently break your system!

nf file (which is still documented, BTW) > > > is no longer read. > > > > > > So, be careful if you have important settings there (security...). > > I kept wondering: what does this have to do with the Subject > header? The files in question belong to the procps pa

Re: systemd may silently break your system!

.d/local.conf No, it does *not* recommend anything: Files located in this directory can set kernel parameters using the sysctl(8) or systemd-sysctl(8) tool which is typically run with a unit/init file started during the boot sequence. For details regarding the config

Re: systemd may silently break your system!

tl.conf file (which is still documented, BTW) > > > is no longer read. > > > > > > So, be careful if you have important settings there (security...). > > I kept wondering: what does this have to do with the Subject > header? The files in question belong t

Re: systemd may silently break your system!

> > > So, be careful if you have important settings there (security...). I kept wondering: what does this have to do with the Subject header? The files in question belong to the procps package, not to systemd, right? As it turns out, it's a combination of the two packages. In bookwor

Re: systemd may silently break your system!

On 2024-07-26, Vincent Lefevre wrote: > The /etc/sysctl.d/99-sysctl.conf symlink has been removed > (currently in unstable) *without any announcement*, so that > the /etc/sysctl.conf file (which is still documented, BTW) > is no longer read. > > So, be careful if you have important settings there

Re: systemd-cryptsetup

On 2024-07-14 13:17:45 +0200, Lists wrote: > On 2024-07-14 11:00, Nicolas George wrote: > > Hi. > > > > In case you are running unstable or testing and it recently started > > blocking at boot waiting for encrypted swap or something to do with > > encrypted

Re: systemd may silently break your system!

e careful if you have important settings there (security...). I had to laugh when I saw the title: systemd may silently break your system! So what's new in the world according to Poettering? Jeff

Re: systemd may silently break your system!

I had already removed the symlink and migrated sysctl.conf to 99-sysctl.conf and it appears Debian deleted that file as well. On Fri, Jul 26, 2024 at 9:00 AM Vincent Lefevre wrote: > > The /etc/sysctl.d/99-sysctl.conf symlink has been removed > (currently in unstable) *without any announcement*,

systemd may silently break your system!

The /etc/sysctl.d/99-sysctl.conf symlink has been removed (currently in unstable) *without any announcement*, so that the /etc/sysctl.conf file (which is still documented, BTW) is no longer read. So, be careful if you have important settings there (security...). -- Vincent Lefèvre - Web:

Listing packages installed on broken system, was systemd errors

did that. > So I think that earlier install has a kernel now free of the nvidia > but there must be some systemd left referencing stuff I've deleted > because there is some message at boot about can't find or load a > module and X wont automatically start. > I'd quit

systemd errors

tartx" but the resolution is low. Apt let me install the 6.9.8 kernel whereas wouldn't dist-upgrade, probably as it had done that before. I saw on the net to "update-initrmfs -u" so I did that. So I think that earlier install has a kernel now free of the nvidia but there must be

Re: systemd-cryptsetup

Lists (12024-07-16): > In that case you were correct. I had found posts online where people were > pointing in the direction of systemd and due to the problem with > systemd-cryptsetup you warned us about I was inclined to take those posts at > face value. It seems that was not &

Re: systemd-cryptsetup

sage comes from /usr/lib/cryptsetup/functions, a file added by the Debian packaging. Nothing to do with systemd. In that case you were correct. I had found posts online where people were pointing in the direction of systemd and due to the problem with systemd-cryptsetup you warned us about I was i

Re: systemd-cryptsetup

b/cryptsetup/functions, a file added by the Debian packaging. Nothing to do with systemd. Regards, -- Nicolas George

Re: systemd-cryptsetup

On 2024-07-16 11:52, Nicolas George wrote: I do not know what you are referring to when you talk about x-initrd.attach, you were too terse. But I notice that you talked about it in the same paragraph that you reported the inaccurate information that systemd has its own implementation of

Re: systemd-cryptsetup

Lists (12024-07-15): > For the most part I understand your point of view. As a matter of fact I am > not even opposed to systemd as such [1], but over the years I have had my > share of problems that in the end proved to be caused by some transition to > systemd. This has made me a bi

Re: systemd-cryptsetup

Hi Nicolas, Thanks for the explanation. For the most part I understand your point of view. As a matter of fact I am not even opposed to systemd as such [1], but over the years I have had my share of problems that in the end proved to be caused by some transition to systemd. This has made me

Re: systemd-cryptsetup

Lists (12024-07-14): > When I researched the problem I encountered some posts stating that systemd > had its own implementation for cryptsetup This is not true. systemd-cryptsetup uses libcryptsetup, it is mostly only glue. > > Why the *&^%#@! it is necessary to have this borg-l

Re: systemd-cryptsetup

On 2024-07-14, Erwan David wrote: > I have a "full" disk encryption as made by the installer, thus mounted in the > initramfs, so it may be a little different If "full disk" include /boot you should be ask for password by grub. Else it is initramfs and you should be ask by cryptsetup (package cry

Re: systemd-cryptsetup

On 2024-07-14 11:00, Nicolas George wrote: Hi. In case you are running unstable or testing and it recently started blocking at boot waiting for encrypted swap or something to do with encrypted disks: Check if systemd-cryptsetup is installed. HtH Thanks for the confirmation! I downloaded

Re: systemd-cryptsetup

Le 14/07/2024 à 11:44, Nicolas George a écrit : Erwan David (12024-07-14): You are a bit cryptic here : should it be installed or should it be removed Sorry. For me it was not installed and installing it fixed the problem. ? I am running testing without problem and systemd-cryptsetup is not

Re: systemd-cryptsetup

Erwan David (12024-07-14): > You are a bit cryptic here : should it be installed or should it be removed Sorry. For me it was not installed and installing it fixed the problem. > ? I am running testing without problem and systemd-cryptsetup is not > installed. If I should install it I

Re: systemd-cryptsetup

Le 14/07/2024 à 11:00, Nicolas George a écrit : Hi. In case you are running unstable or testing and it recently started blocking at boot waiting for encrypted swap or something to do with encrypted disks: Check if systemd-cryptsetup is installed. HtH You are a bit cryptic here : should it be

systemd-cryptsetup

Hi. In case you are running unstable or testing and it recently started blocking at boot waiting for encrypted swap or something to do with encrypted disks: Check if systemd-cryptsetup is installed. HtH -- Nicolas George

Re: systemd-tmpfiles: file globbing?

On Thu, Jun 13, 2024 at 12:00:25PM +0200, Frank Van Damme wrote: > Is there a way to apply max lifetimes to files matching a pattern? I can't > find any way to tell it to, say, remove *.txt files older than a month from > /tmp/foo. If you're willing to turn away from systemd,

systemd-tmpfiles: file globbing?

systemd-tmpfiles-clean will watch directories and periodically purge old contents. eg d /var/cache/man 0755 man man 1w will delete files older than a week from /var/cache/man Is there a way to apply max lifetimes to files matching a pattern? I can't find any way to tell it to, say, remove

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. >

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

perhaps 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) ..

Re: inconsistency in the symlinks under /etc/systemd

ymlinks 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 symlink /etc/systemd/system/sockets.target.wants/dm-event.socket → /lib/systemd/system/dm-event.socket. Setting up lvm2 (2.03.16-2) .

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: 100%

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 are

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 probabl

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

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 a

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

? I rebooted 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, whil

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 - th

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 is

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 commu

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 non

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 Rock

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

  1   2   3   4   5   6   7   8   9   10   >