Bug#1020312: usrmerge: systemd file disappearing
Le 20/09/2022 à 11:41, Luca Boccassi a écrit : Most of the issues would crop up when actually attempting to move things, Interrupting a running upgrade is always problematic. Lots of packages are then in broken state (half installed). Apt has difficulties to recover from such a situation. Sometimes, it needs additional packages requiring a working network (but network-manager can be broken at this point...) so a dry-run would be a lot of work and provide little benefits I think. The goal of the dry-run would be to be run *before* the upgrade start (with the debconf framework) so that the admin can fix any conflict situation described by your matrix when they still have a working system. The other "solution" is to do an upgrade in two-stage 1) install usrmerge 2) do the real upgrade So, a kind of do-release-upgrade (as Ubuntu has) To be thorough you'd have to replicate the filesystem somewhere else and try it there first, but that requires a huge amount of disk space and a lot of time too, I do not understand this argument. While would we need to replicate the FS? I'm just thinking to explore the FS (/lib, ...) and check there is no conflicts as listed in your matrix. so it doesn't seem worth it, given in 5+ years on multiple distros this is the first case we've seen. I think what we should add is debsums -c before/after, and fail if something is not right, so that there's an immediate and clear error plus recovery step presented. I've sent a patch to Marco for this. debsums is very long to be run on a big system or on a system with old (magnetic) disks. Running it twice would lead to a very long installation time of usrmerge. But I'm glad we figured out what went wrong, as it was a very puzzling case. With my systemd maintainer hat on: you shouldn't move these files away to /etc. Units shipped in /usr|/lib are fixed vendor-provided files, and must not be modified. Local modifications should instead happen on /etc or /run. I strongly advise to fix that on your system. (of course we still need usrmerger to support the generic case, that goes without saying) You do not understand my goal. I never modified files in /etc/conffiles-out-etc/ These are the unmodified file shipped in /lib/systemd/system. My goal in putting them here is that they are tracked by etckeeper, so that I can easily see their modifications during an upgrade. It happens a few times that this help me to quickly revert a change I do not want for my system for the default settings. In this cases, the fix goes to /etc/systemd/system/ as it should. Being able to look at the history of these default configuration files is really a good point for me (hence this change done on several of my machines) Regards, Vincent
Bug#1020312: usrmerge: systemd file disappearing
Control: retitle -1 usrmerge: files in a nested symlinked directory in
/lib/foo/ are not moved to /usr/lib/foo/
On Tue, 2022-09-20 at 10:04 +0200, Vincent Danjean wrote:
> Hi,
>
> Le 20/09/2022 à 04:22, Marco d'Itri a écrit :
> > Indeed, this should be handled. Let's have a look at the code:
> [...]
> > In your case the expected outcome should have been a failure instead,
> > because /lib/systemd/system/ was a link which did not point to
> > /usr/lib/systemd/system/ :
> >
> > fatal("Both $n and /usr$n exist");
>
> So yes, I should have been informed before rebooting. My
> upgrade should have been interrupted.
>
> However, I'm not really pleased with the fact that a key package
> of the upgrade can fail on unusual but valid cases. When it appends
> in a dist-upgrade, the resulting state is often a mess to recover
> from (less than the one I suffered, but still really annoying).
>
> What about:
> 1) adding a --dry-mode to /usr/lib/usrmerge/convert-usrmerge
> that report about conflicts but do not change anything on
> the FS
> 2) embedding and using convert-usrmerge in dry-mode from the
> debconf script.
> Put a low warning notice if the script fail due to missing
> dependencies (perl, perl modules, ...)
> Put a high warning notice if the script detect a conflict
>
> This would allows one to stop the conversion in case of strange
> layout in the FS before the upgrade start.
Most of the issues would crop up when actually attempting to move
things, so a dry-run would be a lot of work and provide little benefits
I think. To be thorough you'd have to replicate the filesystem
somewhere else and try it there first, but that requires a huge amount
of disk space and a lot of time too, so it doesn't seem worth it, given
in 5+ years on multiple distros this is the first case we've seen.
I think what we should add is debsums -c before/after, and fail if
something is not right, so that there's an immediate and clear error
plus recovery step presented. I've sent a patch to Marco for this.
But I'm glad we figured out what went wrong, as it was a very puzzling
case. With my systemd maintainer hat on: you shouldn't move these files
away to /etc. Units shipped in /usr|/lib are fixed vendor-provided
files, and must not be modified. Local modifications should instead
happen on /etc or /run. I strongly advise to fix that on your system.
(of course we still need usrmerger to support the generic case, that
goes without saying)
--
Kind regards,
Luca Boccassi
signature.asc
Description: This is a digitally signed message part
Bug#1020312: usrmerge: systemd file disappearing
Hi,
Le 20/09/2022 à 04:22, Marco d'Itri a écrit :
Indeed, this should be handled. Let's have a look at the code:
[...]
In your case the expected outcome should have been a failure instead,
because /lib/systemd/system/ was a link which did not point to
/usr/lib/systemd/system/ :
fatal("Both $n and /usr$n exist");
So yes, I should have been informed before rebooting. My
upgrade should have been interrupted.
However, I'm not really pleased with the fact that a key package
of the upgrade can fail on unusual but valid cases. When it appends
in a dist-upgrade, the resulting state is often a mess to recover
from (less than the one I suffered, but still really annoying).
What about:
1) adding a --dry-mode to /usr/lib/usrmerge/convert-usrmerge
that report about conflicts but do not change anything on
the FS
2) embedding and using convert-usrmerge in dry-mode from the
debconf script.
Put a low warning notice if the script fail due to missing
dependencies (perl, perl modules, ...)
Put a high warning notice if the script detect a conflict
This would allows one to stop the conversion in case of strange
layout in the FS before the upgrade start.
Regards,
Vincent
Bug#1020312: usrmerge: systemd file disappearing
On Sep 20, Vincent Danjean wrote:
> Now that you point out this, it recalls me that years ago,
> I moved /lib/systemd/system/ to /etc/conffiles-out-etc/lib/systemd/system
> (so that the systemd configuration files are correctly tracked by etckeeper)
> and I put a /lib/systemd/system -> /etc/conffiles-out-etc/lib/systemd/system
> symlink.
>
> So, I'm downgrading the severity. But as it is allowed
> to create symlinks to other part of the disk for directory,
> usrmerge should handle this case (or, at least, give a
> preeminent message about a strange situation)
Indeed, this should be handled. Let's have a look at the code:
# both source and dest are directories
if (-d $n and -d "/usr$n") {
# so they have to be merged recursively
my $rule = File::Find::Rule->mindepth(1)->maxdepth(1)->start($n);
while (defined (my $name = $rule->match)) {
convert_file($name, $later);
}
return;
}
# both source and dest are links
if (-l $n and -l "/usr$n") {
...
}
# the source is a link
if (-l $n) {
my $l = readlink($n);
return if $l eq "/usr$n"; # and it points to dest
fatal("Both $n and /usr$n exist");
}
# the destination is a link
if (-l "/usr$n") {
...
}
But -d is true also for a symlink which points to a directory, so the
latter blocks are never reached!
And running File::Find::Rule this way on a symlink without a trailing
/ returns no matches:
my $rule = File::Find::Rule->mindepth(1)->maxdepth(1)->start('/var/lock');
while (defined (my $name = $rule->match)) {
say $name;
}
So the content of the link target was not moved to /usr, and then
the link (/lib/systemd/system/) was just deleted during the final
cleanup because at that point only valid links to their counterparts
in /usr are supposed to be left in the source directories.
In your case the expected outcome should have been a failure instead,
because /lib/systemd/system/ was a link which did not point to
/usr/lib/systemd/system/ :
fatal("Both $n and /usr$n exist");
(Also see the "CONFLICTS RESOLUTION MATRIX" section in the man page.)
While this bug is annoying and needs to be fixed, we had not noticed it
in many years so apparently it is an highly unusual case.
And thankfully no files are lost and they can just be moved manually to
the new directory.
Now I just need to figure out if the safest solution would be to move
the "both source and dest are directories" block at the end or leave it
there and make it ignore directories which are links.
--
ciao,
Marco
signature.asc
Description: PGP signature
Bug#1020312: usrmerge: systemd file disappearing
Le 20/09/2022 à 01:39, Luca Boccassi a écrit : Thanks for the logs, it looks like it's only file under /lib/systemd/system/ that went missing - can you find them anywhere else on the system? Now that you point out this, it recalls me that years ago, I moved /lib/systemd/system/ to /etc/conffiles-out-etc/lib/systemd/system (so that the systemd configuration files are correctly tracked by etckeeper) and I put a /lib/systemd/system -> /etc/conffiles-out-etc/lib/systemd/system symlink. So, I'm downgrading the severity. But as it is allowed to create symlinks to other part of the disk for directory, usrmerge should handle this case (or, at least, give a preeminent message about a strange situation) vdanjean@eyak:~$ diff -r /etc/conffiles-out-etc/lib/systemd/system/ /lib/systemd/system/ Only in /etc/conffiles-out-etc/lib/systemd/system/: cgroupfs-mount.service Only in /lib/systemd/system/: drkonqi-coredump-processor@.service Only in /etc/conffiles-out-etc/lib/systemd/system/: gitlab-ci-multi-runner.service Only in /etc/conffiles-out-etc/lib/systemd/system/: osspd.service Only in /lib/systemd/system/: pam_namespace.service Only in /lib/systemd/system/: pcscd.service Only in /lib/systemd/system/: pcscd.socket Only in /etc/conffiles-out-etc/lib/systemd/system/: pulseaudio-enable-autospawn.service Only in /etc/conffiles-out-etc/lib/systemd/system/: screen-cleanup.service diff -r /etc/conffiles-out-etc/lib/systemd/system/speech-dispatcherd.service /lib/systemd/system/speech-dispatcherd.service 1c1 < # Copyright (C) 2018 Samuel Thibault --- > # Copyright (C) 2018, 2022 Samuel Thibault 23c23 < ExecStart=/usr/bin/speech-dispatcher -d --pid-file /run/speech-dispatcher/speech-dispatcher.pid --- > ExecStart=/usr/bin/speech-dispatcher -d -t 0 --pid-file /run/speech-dispatcher/speech-dispatcher.pid Only in /etc/conffiles-out-etc/lib/systemd/system/: sudo.service vdanjean@eyak:~$ ls /etc/conffiles-out-etc/lib/systemd/system/ | wc -l 468 vdanjean@eyak:~$ ls /lib/systemd/system/ | wc -l 466 vdanjean@eyak:~$ I try to explain the difference: Files previously in /usr/lib/... Only in /lib/systemd/system/: drkonqi-coredump-processor@.service Only in /lib/systemd/system/: pam_namespace.service Only in /lib/systemd/system/: pcscd.service Only in /lib/systemd/system/: pcscd.socket Package not reinstalled Only in /etc/conffiles-out-etc/lib/systemd/system/: gitlab-ci-multi-runner.service Removed packages Only in /etc/conffiles-out-etc/lib/systemd/system/: osspd.service Only in /etc/conffiles-out-etc/lib/systemd/system/: pulseaudio-enable-autospawn.service Files not removed on package upgrade? Only in /etc/conffiles-out-etc/lib/systemd/system/: cgroupfs-mount.service Only in /etc/conffiles-out-etc/lib/systemd/system/: screen-cleanup.service Directories are merged recursively if they exist in both hierarchies, so I guess you had something that installs files in /usr/lib/systemd/system/ and something went horribly wrong somewhere. We don't delete files, so I'm thinking they might have been moved to the wrong place. We can add debsums -c before/after the conversion, so that if this happens again there's a clear message immediately. But this is very strange, I've never seen this reported in Debian or Ubuntu in ~5 years. If I understand, the bug occurs when a directory exists in both / and /usr and the directory in / is in fact a symlink to another directory elsewhere. Not a classical situation indeed, but it can exists... Regards, Vincent
Bug#1020312: usrmerge: systemd file disappearing
On Tue, 20 Sep 2022 01:11:43 +0200 Vincent Danjean wrote: > Hi, > > Le 19/09/2022 à 23:49, Luca Boccassi a écrit : > > On Mon, 2022-09-19 at 22:29 +0100, Luca Boccassi wrote: > >> On Mon, 19 Sep 2022 22:08:48 +0200 Vincent Danjean > >> wrote: > >>> Package: usrmerge > >>> Version: 30+nmu2 > >>> Severity: serious > >>> Justification: break other packages upgrades > >>> > >>> When I upgraded my system to current unstable, usrmerge has > >>> been pulled-in due to the init-system-helpers dependency. > >>> But one package fails to upgrade (fetchmail) due to > >>> /lib/systemd/system/sysinit.target missing. > >>> Reinstalling the systemd package fixes the problem. > >>> > >>> Feel free to reassign to systemd if you think the problem > >>> comes from it but usrmerge is my first guess (without any > >>> specific evidence) > >>> > >>> Note that systemd does *not* upgrade today (see at the end > >>> of the commands) > >> > >> What was the order of upgrades? Can you share the full apt log? > >> Are you sure the problem was not there beforehand? > > > > Also can you run 'debsums -c' and paste the output? > > Oh yes. I'm back online after having rebooted after the upgrade. > It took me several hours to get a bootable system again (hence, > I will upgrade the severity to serious juste after this mail). > > So, first, at reboot, I got the emergency shell of systemd. > It reports timeout when waiting for most (all?) devices. > Once in the shell, all /dev/... files reported by systemd were > there. And "mount -a" correctly mounts all filesystems that > systemd was enable to. > I "fixed" this by booting on a debian rescue disk and > running (from memory): > apt install --reinstall systemd-container systemd-sysv systemd-ui udev cryptsetup cryptsetup-bin cryptsetup-initramfs basefiles > > After this, I've been able to boot to a text-mode only system. > No gdm3 graphical prompt. > So, I've run deb5sums. Here is the result of > debsums |& cat > /tmp/debsum2.txt & > cat /tmp/debsum2.txt | grep -v ' OK$' > /tmp/debsum2-missing.txt > The 3 FAILED lines are "correct" (I manually modified these files long before) > But lots of /lib/* files was missing. > > I used sed/grep/... to reinstall all cited packages. > Then, with a reboot, I'm back again. > > I will re-run debsums (it seems that the "|&" polute the output > a litle bit, I want to be sure I reinstalled all required packages) Thanks for the logs, it looks like it's only file under /lib/systemd/system/ that went missing - can you find them anywhere else on the system? Directories are merged recursively if they exist in both hierarchies, so I guess you had something that installs files in /usr/lib/systemd/system/ and something went horribly wrong somewhere. We don't delete files, so I'm thinking they might have been moved to the wrong place. We can add debsums -c before/after the conversion, so that if this happens again there's a clear message immediately. But this is very strange, I've never seen this reported in Debian or Ubuntu in ~5 years. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1020312: usrmerge: systemd file disappearing
Le 20/09/2022 à 01:11, Vincent Danjean a écrit : Hi, Le 19/09/2022 à 23:49, Luca Boccassi a écrit : Are you sure the problem was not there beforehand? Yes. Due to the numerous missing files, I'm sure the problem comes from the apt upgrade. The FS is in a good state (no corruption) with nearly 9GB free (so no out-of-space problem). My system was perfectly booting and working before. Note that usrmerge has really run: I see this package that would be newly installed before starting the upgrade (and I read its bug page and the links to the TC decisions because initially I did not want to merge my /usr). So, I run 'ls /' in a terminal before and after the upgrade and I saw the changes. Now: vdanjean@eyak:~$ ls -l / | grep -- '->' lrwxrwxrwx 1 root root 7 19 sept. 21:34 bin -> usr/bin lrwxrwxrwx 1 root root 30 12 sept. 18:44 initrd.img -> boot/initrd.img-5.19.0-1-amd64 lrwxrwxrwx 1 root root 30 12 sept. 18:44 initrd.img.old -> boot/initrd.img-5.18.0-4-amd64 lrwxrwxrwx 1 root root 7 19 sept. 21:34 lib -> usr/lib lrwxrwxrwx 1 root root 9 19 sept. 21:34 lib32 -> usr/lib32 lrwxrwxrwx 1 root root 9 19 sept. 21:34 lib64 -> usr/lib64 lrwxrwxrwx 1 root root 10 19 sept. 21:34 libx32 -> usr/libx32 lrwxrwxrwx 1 root root 8 19 sept. 21:34 sbin -> usr/sbin lrwxrwxrwx 1 root root 27 12 sept. 18:44 vmlinuz -> boot/vmlinuz-5.19.0-1-amd64 lrwxrwxrwx 1 root root 27 12 sept. 18:44 vmlinuz.old -> boot/vmlinuz-5.18.0-4-amd64 vdanjean@eyak:~$ I will re-run debsums (it seems that the "|&" polute the output a litle bit, I want to be sure I reinstalled all required packages) Missing files are sent to stderr by debsums, hence the mess in my initial log. After a rerun of debsums, I will have to reinstall gitlab-ci-multi-runner but I need to manually download it (it is not a package from Debian). All the others seem now correct. Regards Vincent I also put in attachement the dpkg log file (I do not see anything special when I've done the initial "apt upgrade") First is my "apt upgrade" At 21:56, there is my "apt install --reinstall systemd" At 22:19, I upgraded pipewire (not done before because this requires the removal of pulseaudio) At 23:52, I reinstalled some package from the rescue system At 00:18, I installed debsums At 00:46, I reinstalled all problematic packages Regards, Vincent
Bug#1020312: usrmerge: systemd file disappearing
Control: tags -1 moreinfo On Mon, 2022-09-19 at 22:29 +0100, Luca Boccassi wrote: > On Mon, 19 Sep 2022 22:08:48 +0200 Vincent Danjean > wrote: > > Package: usrmerge > > Version: 30+nmu2 > > Severity: serious > > Justification: break other packages upgrades > > > > When I upgraded my system to current unstable, usrmerge has > > been pulled-in due to the init-system-helpers dependency. > > But one package fails to upgrade (fetchmail) due to > > /lib/systemd/system/sysinit.target missing. > > Reinstalling the systemd package fixes the problem. > > > > Feel free to reassign to systemd if you think the problem > > comes from it but usrmerge is my first guess (without any > > specific evidence) > > > > Note that systemd does *not* upgrade today (see at the end > > of the commands) > > What was the order of upgrades? Can you share the full apt log? > Are you sure the problem was not there beforehand? Tried in a sid chroot, cannot reproduce: # apt upgrade Reading package lists... Done Building dependency tree... Done Reading state information... Done Calculating upgrade... Done The following NEW packages will be installed: usrmerge The following packages will be upgraded: fetchmail init-system-helpers 2 upgraded, 1 newly installed, 0 to remove and 0 not upgraded. Need to get 412 kB/475 kB of archives. After this operation, 39.9 kB of additional disk space will be used. Do you want to continue? [Y/n] y Get:1 file:/tmp/repo ./ usrmerge 31+nmu1 [13.0 kB] Get:2 http://deb.debian.org/debian sid/main amd64 fetchmail amd64 6.4.33-2 [412 kB] Fetched 412 kB in 0s (4957 kB/s) Selecting previously unselected package usrmerge. (Reading database ... 104605 files and directories currently installed.) Preparing to unpack ..././usrmerge_31+nmu1_all.deb ... Unpacking usrmerge (31+nmu1) ... Setting up usrmerge (31+nmu1) ... The system has been successfully converted. (Reading database ... 104612 files and directories currently installed.) Preparing to unpack .../init-system-helpers_1.65.2_all.deb ... Unpacking init-system-helpers (1.65.2) over (1.64) ... Setting up init-system-helpers (1.65.2) ... (Reading database ... 104612 files and directories currently installed.) Preparing to unpack .../fetchmail_6.4.33-2_amd64.deb ... Unpacking fetchmail (6.4.33-2) over (6.4.33-1) ... Setting up fetchmail (6.4.33-2) ... invoke-rc.d: could not determine current runlevel invoke-rc.d: policy-rc.d denied execution of restart. Processing triggers for man-db (2.10.2-3) ... # ls /lib/systemd/system/sysinit.target /lib/systemd/system/sysinit.target # debsums -c # -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1020312: usrmerge: systemd file disappearing
On Mon, 2022-09-19 at 22:29 +0100, Luca Boccassi wrote: > On Mon, 19 Sep 2022 22:08:48 +0200 Vincent Danjean > wrote: > > Package: usrmerge > > Version: 30+nmu2 > > Severity: serious > > Justification: break other packages upgrades > > > > When I upgraded my system to current unstable, usrmerge has > > been pulled-in due to the init-system-helpers dependency. > > But one package fails to upgrade (fetchmail) due to > > /lib/systemd/system/sysinit.target missing. > > Reinstalling the systemd package fixes the problem. > > > > Feel free to reassign to systemd if you think the problem > > comes from it but usrmerge is my first guess (without any > > specific evidence) > > > > Note that systemd does *not* upgrade today (see at the end > > of the commands) > > What was the order of upgrades? Can you share the full apt log? > Are you sure the problem was not there beforehand? Also can you run 'debsums -c' and paste the output? -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1020312: usrmerge: systemd file disappearing
On Mon, 19 Sep 2022 22:08:48 +0200 Vincent Danjean wrote: > Package: usrmerge > Version: 30+nmu2 > Severity: serious > Justification: break other packages upgrades > > When I upgraded my system to current unstable, usrmerge has > been pulled-in due to the init-system-helpers dependency. > But one package fails to upgrade (fetchmail) due to > /lib/systemd/system/sysinit.target missing. > Reinstalling the systemd package fixes the problem. > > Feel free to reassign to systemd if you think the problem > comes from it but usrmerge is my first guess (without any > specific evidence) > > Note that systemd does *not* upgrade today (see at the end > of the commands) What was the order of upgrades? Can you share the full apt log? Are you sure the problem was not there beforehand? -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1020312: usrmerge: systemd file disappearing
Package: usrmerge Version: 30+nmu2 Severity: serious Justification: break other packages upgrades When I upgraded my system to current unstable, usrmerge has been pulled-in due to the init-system-helpers dependency. But one package fails to upgrade (fetchmail) due to /lib/systemd/system/sysinit.target missing. Reinstalling the systemd package fixes the problem. Feel free to reassign to systemd if you think the problem comes from it but usrmerge is my first guess (without any specific evidence) Note that systemd does *not* upgrade today (see at the end of the commands) vdanjean@eyak:~$ sudo apt upgrade [...] Paramétrage de fetchmail (6.4.33-2) ... insserv: warning: current stop runlevel(s) (empty) of script `fetchmail' overrides LSB defaults (0 1 6). Failed to restart fetchmail.service: Unit sysinit.target not found. invoke-rc.d: initscript fetchmail, action "restart" failed. ○ fetchmail.service - LSB: init-Script for system wide fetchmail daemon Loaded: loaded (/etc/init.d/fetchmail; generated) Active: inactive (dead) Docs: man:systemd-sysv-generator(8) sept. 19 20:27:35 eyak systemd[1]: Starting LSB: init-Script for system wide fetchmail daemon... sept. 19 20:27:35 eyak fetchmail[2556]: Not starting fetchmail daemon, disabled via /etc/default/fetchmail. sept. 19 20:27:35 eyak systemd[1]: Started LSB: init-Script for system wide fetchmail daemon. sept. 19 21:35:02 eyak systemd[1]: Stopping LSB: init-Script for system wide fetchmail daemon... sept. 19 21:35:02 eyak fetchmail[22013]: Not starting fetchmail daemon, disabled via /etc/default/fetchmail. sept. 19 21:35:02 eyak systemd[1]: fetchmail.service: Deactivated successfully. sept. 19 21:35:02 eyak systemd[1]: Stopped LSB: init-Script for system wide fetchmail daemon. dpkg: erreur de traitement du paquet fetchmail (--configure) : installed fetchmail package post-installation script subprocess returned error exit status 1 Des erreurs ont été rencontrées pendant l'exécution : fetchmail vdanjean@eyak:~$ sudo systemctl cat fetchmail # /run/systemd/generator.late/fetchmail.service # Automatically generated by systemd-sysv-generator [Unit] Documentation=man:systemd-sysv-generator(8) SourcePath=/etc/init.d/fetchmail Description=LSB: init-Script for system wide fetchmail daemon Before=multi-user.target Before=multi-user.target Before=multi-user.target Before=graphical.target After=network-online.target After=remote-fs.target After=mail-transport-agent.target After=postfix.service After=exim4.service After=nss-lookup.target Wants=network-online.target [Service] Type=forking Restart=no TimeoutSec=5min IgnoreSIGPIPE=no KillMode=process GuessMainPID=no RemainAfterExit=yes SuccessExitStatus=5 6 ExecStart=/etc/init.d/fetchmail start ExecStop=/etc/init.d/fetchmail stop vdanjean@eyak:~$ sudo systemctl restart fetchmail Failed to restart fetchmail.service: Unit sysinit.target not found. vdanjean@eyak:~$ sudo systemctl status sysinit.target ● sysinit.target Loaded: not-found (Reason: Unit sysinit.target not found.) Active: active since Mon 2022-09-19 20:27:32 CEST; 1h 16min ago Until: Mon 2022-09-19 20:27:32 CEST; 1h 16min ago sept. 19 20:27:32 eyak systemd[1]: Reached target System Initialization. vdanjean@eyak:~$ sudo systemctl daemon-reexec vdanjean@eyak:~$ sudo systemctl status sysinit.target ● sysinit.target Loaded: not-found (Reason: Unit sysinit.target not found.) Active: active since Mon 2022-09-19 20:27:32 CEST; 1h 17min ago Until: Mon 2022-09-19 20:27:32 CEST; 1h 17min ago sept. 19 20:27:32 eyak systemd[1]: Reached target System Initialization. vdanjean@eyak:~$ dpkg -S sysinit.target udev: /lib/systemd/system/sysinit.target.wants/systemd-udevd.service systemd: /lib/systemd/system/sysinit.target.wants/systemd-sysctl.service systemd: /lib/systemd/system/sysinit.target.wants/dev-hugepages.mount systemd: /lib/systemd/system/sysinit.target.wants/systemd-random-seed.service systemd: /lib/systemd/system/sysinit.target.wants/systemd-sysusers.service systemd: /lib/systemd/system/sysinit.target.wants/veritysetup.target systemd: /lib/systemd/system/sysinit.target.wants/systemd-machine-id-commit.service udev, systemd: /lib/systemd/system/sysinit.target.wants udev: /lib/systemd/system/sysinit.target.wants/systemd-udev-trigger.service systemd: /lib/systemd/system/sysinit.target.wants/systemd-journald.service systemd: /lib/systemd/system/sysinit.target.wants/systemd-update-utmp.service systemd: /lib/systemd/system/sysinit.target.wants/sys-kernel-debug.mount systemd: /lib/systemd/system/sysinit.target.wants/sys-kernel-config.mount systemd: /lib/systemd/system/sysinit.target systemd: /lib/systemd/system/sysinit.target.wants/dev-mqueue.mount systemd: /lib/systemd/system/sysinit.target.wants/sys-fs-fuse-connections.mount systemd: /lib/systemd/system/sysinit.target.wants/systemd-ask-password-console.path systemd: /lib/systemd/system/sysinit.target.wants/systemd-binfmt.service systemd:
