Re: Stunnel startup. Was "Native systemd services."

On 09/03/2025 23:15, pe...@easthope.ca wrote: https://wiki.debian.org/Pan . There we read, To enable Stunnel edit /etc/default/stunnel4 ENABLED=1 /etc/default/stunnel4 exists but lacks ENABLED. My best guess is that systemd obsoleted it. Stunnel needs https://wiki.debian.org/Stunnel with

Stunnel startup. Was "Native systemd services."

From: Greg Wooledge Date: Sat, 8 Mar 2025 23:28:24 -0500 > '... the unit definition without the argument parameter is > called a "template".' Thanks. So /lib/systemd/system/stunnel@.service is a service template file rather than service file. Here, one exe

Native systemd services.

From: Greg Wooledge Date: Thu, 13 Feb 2025 13:35:31 -0500 > [shorewall]'s a native systemd service (/lib/systemd/...) but the service is > showing as disabled. # ls -1 /lib/systemd/system/shorewall* /lib/systemd/system/shorewall-init.service /lib/systemd/system/shorew

Re: Native systemd services.

On Sat, Mar 08, 2025 at 20:04:16 -0700, pe...@easthope.ca wrote: > # ls -1 /lib/systemd/system/stunnel* > /lib/systemd/system/stunnel@.service > /lib/systemd/system/stunnel.target > > What is stunnel@.service, rather than stunnel.service? systemd.service(5): SERVICE TEMPLAT

Running containers with systemd-nspawn works, but machinectl fails

before debian 12) and I've been advised to look into machineclt and systemd-nspawn. I have absolutely no experience in running containers, systemd or otherwise, and I'm not sure how this all works with nspawn, but I created a symlink to the location of the cloned server inside of /var/li

Re: boot fails very early with a systemd-service message about failing to load kernel variables

On 2025-02-01 12:39, Andrew M.A. Cater wrote: On Sat, Feb 01, 2025 at 10:07:49AM -0700, g...@extremeground.com wrote: On 2025-02-01 09:29, g...@extremeground.com wrote: BTW: the same happens with the previous kernel. Also, this is a Debian/Buster server running on AMD64 hardware. I've fsck'd th

Re: boot fails very early with a systemd-service message about failing to load kernel variables

On Sat, Feb 01, 2025 at 10:07:49AM -0700, g...@extremeground.com wrote: > On 2025-02-01 09:29, g...@extremeground.com wrote: > > BTW: the same happens with the previous kernel. Also, this is a > Debian/Buster server running on AMD64 hardware. I've fsck'd the partition > and it's fine. > > I reboo

Re: boot fails very early with a systemd-service message about failing to load kernel variables [RESOLVED]

On 2025-02-01 11:29, g...@extremeground.com wrote: I get the message right after the boot sequence declares the / drive clean. The subject message repeats 3 times then the system boot stops. It still responds to the keyboard but there is no system to log into. When I go into the system in a ch

Re: boot fails very early with a systemd-service message about failing to load kernel variables

On 2025-02-01 09:29, g...@extremeground.com wrote: I get the message right after the boot sequence declares the / drive clean. The subject message repeats 3 times then the system boot stops. It still responds to the keyboard but there is no system to log into. When I go into the system in a ch

boot fails very early with a systemd-service message about failing to load kernel variables

I get the message right after the boot sequence declares the / drive clean. The subject message repeats 3 times then the system boot stops. It still responds to the keyboard but there is no system to log into. When I go into the system in a chroot after booting with systemrescue, I find that j

Re: remark related about package removal on bookworm providing a systemd service

On 29/01/2025 19:16, Greg Wooledge wrote: dbus-org.freedesktop.timesync1.service symlink is a service name alias for systemd-timesyncd.service. I have no idea *why* this alias was desired, but that's apparently what it is. systemd.unit(5) explains that it is to start the service on dema

Re: Re: remark related about package removal on bookworm providing a systemd service

On Wed, Jan 29, 2025 at 02:18:23 -0500, Jeffrey Walton wrote: > Some old programs use non-existent symlinks to store or persist state > information rather than create a normal file. But I don't believe > systemd uses the technique. Not on purpose, but systemd does use symbolic

Re: Re: remark related about package removal on bookworm providing a systemd service

sure no more present > whatever a removal or a purge. Or is such a symlink considered as part of > configuration files? I don't think so, but I might be wrong. Related (it does not answer your question), you can find the broken symlinks related to systemd with: symlinks -r /etc/syste

Re: remark related about package removal on bookworm providing a systemd service

On 29/01/2025 01:39, Greg Wooledge wrote: The question is about this dangling symlink: hobbit:/etc/systemd/system$ ls -l dbus-org.freedesktop.timesync1.service lrwxrwxrwx 1 root root 45 Feb 17 2024 dbus-org.freedesktop.timesync1.service -> /lib/systemd/system/systemd-timesyncd.serv

Re: remark related about package removal on bookworm providing a systemd service

Le 28/01/2025 à 23:28, David Wright a écrit : [...] But would that not be /etc/systemd/system/…/systemd-timesyncd.service? The dangling symlink is for ….timesync1.service, whatever that is. Analogously, my systemd-networkd service has two symlinks: /e/s/s/dbus-org.freedesktop.network1

Re: remark related about package removal on bookworm providing a systemd service

On Tue, Jan 28, 2025 at 3:30 PM didier gaumet wrote: > > Le 28/01/2025 à 20:42, didier gaumet a écrit : > [...] > > the installation of the package (seemly the default policy in Debian), > [...] > > sorry for my poor english: please replace "seemly" by "apparently" Don't apologize. Your English i

Re: remark related about package removal on bookworm providing a systemd service

On Tue 28 Jan 2025 at 20:42:49 (+0100), didier gaumet wrote: > Le 28/01/2025 à 19:39, Greg Wooledge a écrit : > [...] > > hobbit:/etc/systemd/system$ ls -l dbus-org.freedesktop.timesync1.service > > lrwxrwxrwx 1 root root 45 Feb 17 2024 > > dbus-org.freedesktop.timesy

Re: remark related about package removal on bookworm providing a systemd service

Le 28/01/2025 à 20:42, didier gaumet a écrit : [...] the installation of the package (seemly the default policy in Debian), [...] sorry for my poor english: please replace "seemly" by "apparently"

Re: remark related about package removal on bookworm providing a systemd service

Le 28/01/2025 à 19:39, Greg Wooledge a écrit : [...] hobbit:/etc/systemd/system$ ls -l dbus-org.freedesktop.timesync1.service lrwxrwxrwx 1 root root 45 Feb 17 2024 dbus-org.freedesktop.timesync1.service -> /lib/systemd/system/systemd-timesyncd.service [...] I'm unclear on exactly

Re: Re: remark related about package removal on bookworm providing a systemd service

for sure no more present > whatever a removal or a purge. Or is such a symlink considered as part of > configuration files? I don't think so, but I might be wrong. The question is about this dangling symlink: hobbit:/etc/systemd/system$ ls -l dbus-org.freedesktop.timesync1.service lrwx

Re: Re: remark related about package removal on bookworm providing a systemd service

Of course, maybe I misspoke but my point wasn't about the configuration files remaining as expected just removing the package and not purging it. It is about the broken symlink to its service file which is for sure no more present whatever a removal or a purge. Or is such a symlink considered as

Re: remark related about package removal on bookworm providing a systemd service

Le 27/01/2025 à 17:39, Patrice Duroux a écrit : Hi, I do not know if this is something already addressed (elsewhere or in Trixie), a package issue or something more general. On a bookworm system, removing systemd-timesyncd is leaving a broken symlink (/etc/systemd/system/dbus

remark related about package removal on bookworm providing a systemd service

Hi, I do not know if this is something already addressed (elsewhere or in Trixie), a package issue or something more general. On a bookworm system, removing systemd-timesyncd is leaving a broken symlink (/etc/systemd/system/dbus-org.freedesktop.timesync1.service). On this system, systemd

Re: Squid on Debian 12 not staring via systemd

is built in Testing/trixie - you may find that you can either install > just squid from there or at least use the Debian files as a basis for > repackaging. > > There doesn't seem to be a squid in debian-backports. > > All the very best, as ever, > > Andy > I

Re: Squid on Debian 12 not staring via systemd

On Fri, Dec 6, 2024 at 9:37 PM Timothy M Butterworth < timothy.m.butterwo...@gmail.com> wrote: > > > On Fri, Dec 6, 2024 at 5:20 PM Timothy M Butterworth < > timothy.m.butterwo...@gmail.com> wrote: > >> >> >> On Fri, Dec 6, 2024 at 4:19 PM Timothy M Butterworth < >> timothy.m.butterwo...@gmail.com

Re: Squid on Debian 12 not staring via systemd

On Fri, Dec 06, 2024 at 21:37:35 -0500, Timothy M Butterworth wrote: > 2024/12/06 21:35:05| *FATAL: Ipc::Mem::Segment::create failed to > shm_open(/squid-cf__metadata.shm): (17) File exists * A quick google search gives me

Re: Squid on Debian 12 not staring via systemd

Hi, On Fri, Dec 06, 2024 at 09:37:35PM -0500, Timothy M Butterworth wrote: > 2024/12/06 21:35:05| *FATAL: Ipc::Mem::Segment::create failed to > shm_open(/squid-cf__metadata.shm): (17) File exists * Are there files in /dev/shm left from a previous run that are owned by a different user? Thanks, A

Re: Squid on Debian 12 not staring via systemd

On Fri, Dec 6, 2024 at 5:20 PM Timothy M Butterworth < timothy.m.butterwo...@gmail.com> wrote: > > > On Fri, Dec 6, 2024 at 4:19 PM Timothy M Butterworth < > timothy.m.butterwo...@gmail.com> wrote: > >> >> >> On Fri, Dec 6, 2024 at 11:29 AM Timothy M Butterworth < >> timothy.m.butterwo...@gmail.co

Re: Squid on Debian 12 not staring via systemd

On Fri, Dec 06, 2024 at 05:20:02PM -0500, Timothy M Butterworth wrote: > On Fri, Dec 6, 2024 at 4:19 PM Timothy M Butterworth < > timothy.m.butterwo...@gmail.com> wrote: > > >> > > > > According to squid upstream version 5.7 is no longer supported. Version > > 6.7 has a workaround fix for the prob

Re: Squid on Debian 12 not staring via systemd

On Fri, Dec 6, 2024 at 4:19 PM Timothy M Butterworth < timothy.m.butterwo...@gmail.com> wrote: > > > On Fri, Dec 6, 2024 at 11:29 AM Timothy M Butterworth < > timothy.m.butterwo...@gmail.com> wrote: > >> >> >> On Fri, Dec 6, 2024 at 11:08 AM Jeffrey Walton >> wrote: >> >>> On Fri, Dec 6, 2024 at

Re: Squid on Debian 12 not staring via systemd

On Fri, Dec 6, 2024 at 11:29 AM Timothy M Butterworth < timothy.m.butterwo...@gmail.com> wrote: > > > On Fri, Dec 6, 2024 at 11:08 AM Jeffrey Walton wrote: > >> On Fri, Dec 6, 2024 at 8:27 AM Timothy M Butterworth >> wrote: >> > [...] >> > After troubleshooting a bit I found that squid is not bi

Re: Squid on Debian 12 not staring via systemd

On Fri, 6 Dec 2024 13:01:37 -0500 Jeffrey Walton wrote: > > > > Squid has a service account: "proxy" and group "proxy". > > That may be an issue. Years ago I had MySQL failures because MySQL > startup scripts checked UID and GID were mysql. Trying to start the > server as root led to failures.

Re: Squid on Debian 12 not staring via systemd

On Fri, Dec 6, 2024 at 11:56 AM Timothy M Butterworth wrote: > > On Fri, Dec 6, 2024 at 11:48 AM Jeffrey Walton wrote: >> >> On Fri, Dec 6, 2024 at 11:29 AM Timothy M Butterworth >> wrote: >> > >> > On Fri, Dec 6, 2024 at 11:08 AM Jeffrey Walton wrote: >> >> >> >> On Fri, Dec 6, 2024 at 8:27 AM

Re: Squid on Debian 12 not staring via systemd

On Fri, Dec 6, 2024 at 11:48 AM Jeffrey Walton wrote: > On Fri, Dec 6, 2024 at 11:29 AM Timothy M Butterworth > wrote: > > > > On Fri, Dec 6, 2024 at 11:08 AM Jeffrey Walton > wrote: > >> > >> On Fri, Dec 6, 2024 at 8:27 AM Timothy M Butterworth > >> wrote: > >> > [...] > >> > After troublesho

Re: Squid on Debian 12 not staring via systemd

On Fri, Dec 6, 2024 at 8:27 AM Timothy M Butterworth wrote: > [...] > After troubleshooting a bit I found that squid is not binding a socket to > 3128 when started manually. > > root@hp-debian:/home/tmb# squid -a 3128 > 2024/12/06 05:01:01| FATAL: vector::_M_range_check: __n (which is 1) >= > th

Re: Squid on Debian 12 not staring via systemd

> Is anyone running Squid on Debian 12? I installed it but I can not get it > to start via systemd. FWIW, I'm running Squid on Debian 12, yes. I don't know if I start it via systemd, but it's started at boot presumably by systemd and `systemctl status squid` gives mean sane

Re: Squid on Debian 12 not staring via systemd

On Fri, Dec 6, 2024 at 4:42 AM Timothy M Butterworth < timothy.m.butterwo...@gmail.com> wrote: > Hello, > > Is anyone running Squid on Debian 12? I installed it but I can not get it > to start via systemd. > > root@hp-debian:/home/tmb# systemctl status squid.service >

Squid on Debian 12 not staring via systemd

Hello, Is anyone running Squid on Debian 12? I installed it but I can not get it to start via systemd. root@hp-debian:/home/tmb# systemctl status squid.service × squid.service - Squid Web Proxy Server Loaded: loaded (/lib/systemd/system/squid.service; enabled; preset: enabled) Active

Re: differences between sysvinit and systemd

arlier post. What I wrote was not intended as a ready-to-use exact-equivalence one-or-the-other, but as an _illustrative example_. There are other differences between the two as well; one example of such a difference is how they handle log rotation, which is largely a non-issue with systemd +

Re: differences between sysvinit and systemd; was: where is mail.log

On Sat, Nov 30, 2024 at 13:03:32 +, Michael Kjörling wrote: > # awk '{ if($5 ~ "^postfix[[]") { print } }'

Re: differences between sysvinit and systemd; was: where is mail.log

On 30 Nov 2024 20:33 +0800, from bit...@secubox.org (Bitfox): > May I ask what's the main difference between systemd and sysv for init > system? I think it's fair to say that systemd does a great deal more, as well as that it brings things into the init system which have traditi

Re: Debugging systemd-tmpfiles

On 29/11/2024 02:24, jman wrote: Erwan David writes: However, those directories are not cleaned. What should I check ? I've not yet used systemd-tmpfiles but the first thing that comes to my mind, if I had to use it, would to be very careful and mindful of the "purge" command,

Re: Debugging systemd-tmpfiles

Erwan David writes: However, those directories are not cleaned. What should I check ? I've not yet used systemd-tmpfiles but the first thing that comes to my mind, if I had to use it, would to be very careful and mindful of the "purge" command, which can have surprising

Re: Debugging systemd-tmpfiles

On Thu, Nov 28, 2024 at 16:57:37 +0100, Erwan David wrote: > I have setup systemd-tmpfiles in user mode as follows : > > systemd-tmpfiles --user --cat-config > # /home/erwan/.config/user-tmpfiles.d/perso.conf > d /home/erwan/tmp 0755erwan erwan 60d

Debugging systemd-tmpfiles

I have setup systemd-tmpfiles in user mode as follows : systemd-tmpfiles --user --cat-config # /home/erwan/.config/user-tmpfiles.d/perso.conf d /home/erwan/tmp 0755erwan erwan 60d d /home/erwan/Downloads 0755erwan erwan 90d However, those directories

Trixie, mdadm, and systemd

Hi all, Does anyone know if the defaults for mdadm make sense anymore? In particular, the three options for: AUTOCHECK, AUTOSCAN, and START_DAEMON It would *appear* that systemd has timers for these things now. I'm confused as to whether systemd, mdadm, or both need configuring here.

Re: Bump: systemd version 256.7-2 on Debian testing disabled UTMP support

On 2024-11-15 22:19, Farblos wrote: > any comment from your side on below mail or a general pointer on > "the future of Debian and utmp"? Ok, my bad. I have been focusing on/searching in debian-user, but debian-devel would have been the more appropriate place. If anybody else comes across this

Bump: systemd version 256.7-2 on Debian testing disabled UTMP support

oked an existing discussion ...] > > systemd version 256.7-2 on Debian disabled UTMP support (from the > Debian changelog): > > ,---- > | [ Luca Boccassi ] > | * systemd-boot: depend on systemd for kernel-install (Closes: #1085012) > | * Disable utmp support, not y2038 safe. utmp

Re: systemd version 256.7-2 on Debian testing disabled UTMP support

> I am guessing from the version number that this is on trixie/sid. On Correct, thanks for guessing. > November 4th, systemd 256.7-3 came through. Have you tested whether > that fixed the issue? Nothing has changed with that version (note the "-UTMP"): , | [~]$

Re: systemd version 256.7-2 on Debian testing disabled UTMP support

On Wed, 6 Nov 2024 21:18:33 +0100 Jens Schmidt wrote: > [I hope this is the right way to address this question - apologies > if not or if I have overlooked an existing discussion ...] > > systemd version 256.7-2 on Debian disabled UTMP support (from the > Debian changelog): I a

systemd version 256.7-2 on Debian testing disabled UTMP support

[I hope this is the right way to address this question - apologies if not or if I have overlooked an existing discussion ...] systemd version 256.7-2 on Debian disabled UTMP support (from the Debian changelog): , | [ Luca Boccassi ] | * systemd-boot: depend on systemd for kernel-install

Re: Sharing NetworkManager Wi-Fi to systemd-networkd over ethernet

ction with static address instead of shared connection and either start dnsmasq and adjust nftables rules from hooks or to configure other computer (you called it "server") with static address. On the server side, I am not sure how to configure `systemd-networkd` DHCP/route settin

Sharing NetworkManager Wi-Fi to systemd-networkd over ethernet

Hi, I have a KDE Plasma desktop using `NetworkManager` and `dnscrypt-proxy` behind the scenes, connected to a wireless network. Next to it I have a "server" PC with `systemd-networkd` which I wish to connect to the internet via the desktop with an ethernet cable. On the desktop

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

  1   2   3   4   5   6   7   8   9   10   >