Bonjour,
Une image sera mieux qu'un long discours
https://i.goopics.net/DG9J4.png
Je pense que c'est en rapport, les tâches cron et anacron ne se sont pas lancées aujourd'hui.
J'ai fait des recherches, surtout en français, personne ne semble rencontrer ce problème.
Savez-vous comment remettre les choses en ordre ?
Merci d'avance pour votre aide :)
# qui a effacé le dossier ?
Posté par NeoX . Évalué à 2.
les liens pointent quelques part
si tu vas en ligne de commande, tu devrais voir vers quoi ca pointe
chez moi c'est dans /etc/systemd/
il y a des sous dossier, et dedans des fichiers xxxx.service
ainsi avec la commande
find /etc/systemd/ -iname *.service -exec ls -l {} \;on y voit par exemple
que le dernier lien /etc/systemd/system/multi-user.target.wants/cron.service
est en réalité /lib/systemd/system/cron.service
donc si cet destination n'existe plus, le lien est brisé
# La destination existe
Posté par Léa . Évalué à 1. Dernière modification le 17 septembre 2024 à 20:35.
Merci pour ta réponse ;)
j'avais regardé depuis les propriétés du fichier dans Nemo, puis en ligne de commande où pointent quelques liens, ça ne donnait rien d'exploitable
En ligne de commande, pareil :
lrwxrwxrwx 1 root root 32 avril 8 17:01 invocation:colord.service -> c34a5305a78f4867a6fd8c890bfae992
lrwxrwxrwx 1 root root 32 avril 8 17:01 invocation:console-setup.service -> ab483febcac541d7b6b8da377a92e7d3
lrwxrwxrwx 1 root root 32 avril 8 17:01 invocation:cron.service -> 56811faf3f7345bb9d95a2c8ad000cac
lrwxrwxrwx 1 root root 32 avril 9 08:38 invocation:cups-browsed.service -> 4ab084d21056487db49a3e0742804079
lrwxrwxrwx 1 root root 32 avril 9 08:38 invocation:cups.service -> 7da277e4c721481992d126d5dd5850f2
lrwxrwxrwx 1 root root 32 avril 8 17:01 invocation:dbus.service -> f80490d0da284c0eb29615d5491b693f
J'ai pu vérifier pour cron et quelques autre liens, et la destination existe.
https://i.goopics.net/lGAW4.png
Pour info, j'ai une erreur récurrente à chaque démarrage qui doit être en rapport, mais je ne sais pas quoi en faire :
-- Reboot --
avril 08 17:01:12 mia-PC5 systemd[1]: Failed to start Raise network interfaces.
Merci beaucoup pour ton aide
[^] # Re: La destination existe
Posté par Anonyme . Évalué à 2.
a mon avis il y a 2 point a faire :
est ce que avant tes pb les liens etait aussi cassé ?
ce que je fait dans ce cas, je force une resinstallation de tous les paquets, c'est brute, et cela corrige des pb sans forcement comprendre ce qui c'est passé :*)
je vais dans synaptic je selectionne les paquets deja installer et je selectionne pour reinstallation.
[^] # Re: La destination existe
Posté par Léa . Évalué à 1.
Bonjour et merci pour ta réponse,
J'avais remarqué il y a quelques semaines que le lien smartd était brisé, c'était le seul, j'avais justement un problème avec smartd.
Aujourd'hui mes 2 tâches, une cron et une anacron, se sont bien lancées !
Et l'anacron d'hier a fini par arriver, avec Undelivered Mail Returned to Sender comme sujet (unknown user), alors que le corps de texte est bien là.
La cron d'hier n'est pas arrivée.
Pour ta technique de réinstallation, j'aurais bien aimé comprendre ce qu'il s'était passé, mais avoir une solution c'est bien aussi, je vais l'appliquer, merci ;)
[^] # Re: La destination existe
Posté par Léa . Évalué à 1.
Bonjour,
J'ai essayé la réinstallation, les liens sont toujours brisés, mais à la date/heure de la réinstallation.
Il doit y avoir un truc en amont qui brise les liens, mais quoi ?
Peut-être ce message d'erreur (le seul) au démarrage :
"Raise network interface Failed"
Si vous avez d'autres idées, merci d'avance ;)
[^] # Re: La destination existe
Posté par NeoX . Évalué à 2.
il n'arrive pas à activer la carte reseau
à tout hasard, tes liens pointeraient pas sur le reseau ?
sinon c'est louche tes liens vers des IDs totalement numeriques
comme si tu avais chiffrés les fichiers
[^] # Re: La destination existe
Posté par Léa . Évalué à 1. Dernière modification le 11 avril 2020 à 10:36.
Bonjour,
Les liens pointent ne pointent pas spécialement sur le réseau.
Je n'ai pas chiffré les fichiers.
Si j'utilise la commande ls -la, j'obtiens ces iD numériques, mais si j'utilise la commande que tu as donnée plus haut, tout comme pour toi les liens pointent vers /etc/systemd/
J'ai posté plus haut une image des propriétés de cette cible :
Une autre :
[^] # Re: La destination existe
Posté par NeoX . Évalué à 2.
donc là tu me montres le /etc/system
mais ton problème serait dans le /run/systemd
il faut donc faire la meme commande dans le /run/systemd
si tu le fait à la main, les couleurs peuvent avoir une importance
exemple la partie droite de la flèche sera rouge si la destination n'existe pas
comme c'est dans le dossier /run, c'est ce qui est actuellement actif
c'est alors etrange que les liens soient "brisés"
[^] # Re: La destination existe
Posté par Léa . Évalué à 1. Dernière modification le 11 avril 2020 à 12:32.
La même commande dans /run/systemd donne ces iD numériques :
mia@mia-PC5:/run/systemd/units$ find /run/systemd/ -iname *.service -exec ls -l {} \;
find: paths must precede expression: `invocation:acpid.service'
total 0
drwxr-xr-x 2 root root 1620 avril 11 12:01 .
drwxr-xr-x 21 root root 520 avril 11 09:45 ..
lrwxrwxrwx 1 root root 32 avril 10 13:52 invocation:accounts-daemon.service -> 6d2ea96b1f27433e81be21d6c6fbfcd2
lrwxrwxrwx 1 root root 32 avril 10 13:52 invocation:acpid.service -> 53a16a19b5ec47e2bc6e7c4084bf4b83
lrwxrwxrwx 1 root root 32 avril 10 13:52 invocation:alsa-restore.service -> 8fac3028c3834a8c8ccfa76d538751dd
lrwxrwxrwx 1 root root 32 avril 10 13:52 invocation:apparmor.service -> 866e469a9a6e4e69bd9e94016e3e15e7
lrwxrwxrwx 1 root root 32 avril 10 13:52 invocation:apport.service -> 37f0508cf60741898969c13a444dafce
lrwxrwxrwx 1 root root 32 avril 10 13:52 invocation:avahi-daemon.service -> 9cee8a9008644240b101b32f37a83789
lrwxrwxrwx 1 root root 32 avril 10 13:52 invocation:blk-availability.service -> 1e5253742d2847229ed46d9a5fb3f145
lrwxrwxrwx 1 root root 32 avril 10 14:07 invocation:clamav-freshclam.service -> e3768d20e4c64f3995cbd11a6ccb7f35
lrwxrwxrwx 1 root root 32 avril 10 13:52 invocation:colord.service -> 1d1a2845635a4f47bbae4edf009dc0e1
lrwxrwxrwx 1 root root 32 avril 10 13:52 invocation:console-setup.service -> f7a18c436ef64ab8b296304afaf986b7
lrwxrwxrwx 1 root root 32 avril 10 13:52 invocation:cron.service -> 25f271bce59447c2a552e5e996a2b851
lrwxrwxrwx 1 root root 32 avril 11 09:04 invocation:cups-browsed.service -> e79a0bffd4834f2e8f3e51c089ba5878
lrwxrwxrwx 1 root root 32 avril 11 09:04 invocation:cups.service -> 37d732e2735948b5bb6b368dccc204c1
lrwxrwxrwx 1 root root 32 avril 10 13:52 invocation:dbus.service -> 8e62ff9080d04018b3fddd739b56a7ff
lrwxrwxrwx 1 root root 32 avril 10 13:52 'invocation:dev-disk-by\x2duuid-512283d8\x2d9d8c\x2d40c5\x2d975b\x2d52dbcd0fcd94.swap' -> 2cf4edeca6774db3bb8545c0d004dbf8
lrwxrwxrwx 1 root root 32 avril 10 13:52 invocation:dev-hugepages.mount -> 446583dbec484582b8de62cdd123fa84
lrwxrwxrwx 1 root root 32 avril 10 13:52 invocation:dev-mqueue.mount -> 123aa14d7b69480cb3551d608a2deeb8
lrwxrwxrwx 1 root root 32 avril 10 13:52 invocation:finalrd.service -> 4f0982d425264111b45e5e9afee00e61
lrwxrwxrwx 1 root root 32 avril 10 13:52 invocation:geoclue.service -> 405c3220bbc44bf6b1e6429a4db5932e
lrwxrwxrwx 1 root root 32 avril 10 13:52 invocation:getty@tty1.service -> ad047b5ab5454ccdba8ee1051ad37061
lrwxrwxrwx 1 root root 32 avril 10 13:52 invocation:grub-common.service -> 7894b622e97249e79ade7af1f6e94a45
lrwxrwxrwx 1 root root 32 avril 10 13:52 invocation:hddtemp.service -> 32e8a29b64d247e3947366c1acf92002
lrwxrwxrwx 1 root root 32 avril 10 13:52 invocation:home.mount -> e8857f994d1f4a2a8e3e3859ee788a82
lrwxrwxrwx 1 root root 32 avril 10 13:52 invocation:irqbalance.service -> 16fc9d346d2a445abff4c0857feef351
lrwxrwxrwx 1 root root 32 avril 10 13:52 invocation:kerneloops.service -> 6846b296d6a1479c95a0f30c29890e13
lrwxrwxrwx 1 root root 32 avril 10 13:52 invocation:keyboard-setup.service -> 7266ff2550da4a8e92c011267af55399
lrwxrwxrwx 1 root root 32 avril 10 13:52 invocation:kmod-static-nodes.service -> 420ce5ff733340d2949cff41f6893eb8
lrwxrwxrwx 1 root root 32 avril 10 13:52 invocation:lightdm.service -> 397d61e5cce64708af98242ffe0db082
lrwxrwxrwx 1 root root 32 avril 10 13:52 invocation:lm-sensors.service -> 10b872ccbd644677baa6c39ea5587a36
lrwxrwxrwx 1 root root 32 avril 10 13:52 invocation:lvm2-lvmetad.service -> d723b684c6294064a147359f640462dd
lrwxrwxrwx 1 root root 32 avril 10 13:52 invocation:lvm2-monitor.service -> 202c51f161d44751a14a5c108c75e442
lrwxrwxrwx 1 root root 32 avril 10 13:52 invocation:mnt-grsync.mount -> 6fb03b1a3fda4245a6569cf01b9ba480
lrwxrwxrwx 1 root root 32 avril 10 13:52 invocation:mnt-VMs.mount -> 27023740922b4c3cb1ab4908d57c52b8
lrwxrwxrwx 1 root root 32 avril 10 13:52 invocation:networkd-dispatcher.service -> b7455fda29cc475784c1394ee85a5939
lrwxrwxrwx 1 root root 32 avril 10 13:52 invocation:networking.service -> 6acb1ce3b38a4668aac904f797033f18
lrwxrwxrwx 1 root root 32 avril 10 13:52 invocation:NetworkManager.service -> 557014fcbd924ba78e8147f30986b84d
lrwxrwxrwx 1 root root 32 avril 10 13:52 invocation:NetworkManager-wait-online.service -> a7277ea41a7f42dfb7d300fba878f35d
lrwxrwxrwx 1 root root 32 avril 10 13:52 invocation:nvidia-persistenced.service -> 32f01873a7964f42a718e44f8f6960aa
lrwxrwxrwx 1 root root 32 avril 10 13:52 invocation:openvpn.service -> 8641ec323f5e4ab8a057d2f65e7101fd
lrwxrwxrwx 1 root root 32 avril 10 14:03 invocation:packagekit.service -> acc721c068aa45c980b30afaa84375e4
lrwxrwxrwx 1 root root 32 avril 10 13:52 invocation:polkit.service -> 0d88b5fa0c3447939772abf20e94b776
lrwxrwxrwx 1 root root 32 avril 10 13:52 invocation:postfix.service -> 14e3eebd15444c7a879d6676df7d5c33
lrwxrwxrwx 1 root root 32 avril 10 13:52 invocation:postfix@-.service -> 3f529d77c0794894b28d5b5e4ebcfc19
lrwxrwxrwx 1 root root 32 avril 10 13:52 invocation:qemu-kvm.service -> 42eb869aa0324395a5e44df83d06c7a9
lrwxrwxrwx 1 root root 32 avril 10 13:52 invocation:rsyslog.service -> 91fa279be76942428d5d559e456ae287
lrwxrwxrwx 1 root root 32 avril 10 13:52 invocation:rtkit-daemon.service -> d96b3d122dc34c7bb2e4654c59eb90cc
lrwxrwxrwx 1 root root 32 avril 10 13:52 invocation:session-c1.scope -> 8f0b66fa1e484f989961c5a89c09b460
lrwxrwxrwx 1 root root 32 avril 10 13:52 invocation:setvtrgb.service -> de7556c211274cee95cee5ec0c914f00
lrwxrwxrwx 1 root root 32 avril 10 13:52 invocation:smartd.service -> c3e816a38f8a4840a1b83964897796f0
lrwxrwxrwx 1 root root 32 avril 10 13:52 invocation:speech-dispatcher.service -> 71682a3848394e34b63bf97f71065b3e
lrwxrwxrwx 1 root root 32 avril 10 13:52 invocation:ssh.service -> 7e13b9ac4ddc4f67b92b84f8bf3d53e3
lrwxrwxrwx 1 root root 32 avril 10 13:52 invocation:sys-fs-fuse-connections.mount -> 85d300ab45c347139b3b36679b85aff5
lrwxrwxrwx 1 root root 32 avril 10 13:52 invocation:sys-kernel-config.mount -> 6323a98cb1544d93b73ca573d14d061d
lrwxrwxrwx 1 root root 32 avril 10 13:52 invocation:sys-kernel-debug.mount -> 0c933c03c001482699889ff42db83708
lrwxrwxrwx 1 root root 32 avril 10 13:52 'invocation:systemd-fsck@dev-disk-by\x2duuid-e9b11471\x2dc256\x2d4f9c\x2db21f\x2db394c6f22f7a.service' -> e8bce2e4cd334b769b9003768da22fda
lrwxrwxrwx 1 root root 32 avril 10 13:52 invocation:systemd-journald.service -> 30fda9739c2a40319dbc6e0cd5d23616
lrwxrwxrwx 1 root root 32 avril 10 13:52 invocation:systemd-journal-flush.service -> 493cf847d5954b9d81bef02bf8b917bf
lrwxrwxrwx 1 root root 32 avril 10 13:52 invocation:systemd-logind.service -> 801402035470418da2fea626d15bfe16
lrwxrwxrwx 1 root root 32 avril 10 13:52 invocation:systemd-modules-load.service -> a5a4b82a48cd4885a3a17de120115b53
lrwxrwxrwx 1 root root 32 avril 10 13:52 invocation:systemd-random-seed.service -> c9d1101274d94b81bb9687a62a7c5209
lrwxrwxrwx 1 root root 32 avril 10 13:52 invocation:systemd-remount-fs.service -> afa254fb92334443bee58b19f62e260f
lrwxrwxrwx 1 root root 32 avril 10 13:52 invocation:systemd-resolved.service -> bc34f87cf6864202a367c9ac97594a4e
lrwxrwxrwx 1 root root 32 avril 10 13:52 invocation:systemd-sysctl.service -> 4e1d5849577a40f98a9a936d4e1995c0
lrwxrwxrwx 1 root root 32 avril 10 13:52 invocation:systemd-timesyncd.service -> bb78b1ecbd644b51979c79e5a7822d3f
lrwxrwxrwx 1 root root 32 avril 10 13:52 invocation:systemd-tmpfiles-setup-dev.service -> 63bc70f364eb4e9ab663571c134a818b
lrwxrwxrwx 1 root root 32 avril 10 13:52 invocation:systemd-tmpfiles-setup.service -> 7cffb1512dd94076a34a64e9cd5fa7a2
lrwxrwxrwx 1 root root 32 avril 10 13:52 invocation:systemd-udevd.service -> 4dbda7b8b56a428d93f2c9aa52fd4bd8
lrwxrwxrwx 1 root root 32 avril 10 13:52 invocation:systemd-udev-trigger.service -> c6e23bf0f971469c84dcf3864abbd9bd
lrwxrwxrwx 1 root root 32 avril 10 13:52 invocation:systemd-update-utmp.service -> 86cdc5d8d82846808e56afd6fc7fd17a
lrwxrwxrwx 1 root root 32 avril 10 13:52 invocation:systemd-user-sessions.service -> 89894a9cc9464fd1ae8b2a7ef5c8bb57
lrwxrwxrwx 1 root root 32 avril 10 13:52 invocation:thermald.service -> cbed0f90eb1f43d4b8c4b9b9a0b7db57
lrwxrwxrwx 1 root root 32 avril 10 13:52 invocation:ubuntu-system-adjustments.service -> b7d000c4ed01498594ab6e31b6e9277f
lrwxrwxrwx 1 root root 32 avril 10 13:52 invocation:udisks2.service -> 8e99845df9734e16a299a6592335e80d
lrwxrwxrwx 1 root root 32 avril 10 13:52 invocation:ufw.service -> 8e4ce411ecbd40a5a1fb5e4d5a94b5f8
lrwxrwxrwx 1 root root 32 avril 10 13:52 invocation:upower.service -> bbb23b97c95743f5ab2016e2c0313311
lrwxrwxrwx 1 root root 32 avril 10 13:52 invocation:user@1000.service -> d47c7bd736a548b28d027fc093ddd501
lrwxrwxrwx 1 root root 32 avril 10 13:53 invocation:uuidd.service -> a0048b4b028f47ed8c982f83fed9ce15
lrwxrwxrwx 1 root root 32 avril 10 13:52 invocation:virtualbox.service -> d251f65c1f3341089ac06108ce46fe0e
lrwxrwxrwx 1 root root 32 avril 10 13:52 invocation:wpa_supplicant.service -> 51decb4502cd4092a0a39913687eb20b
mia@mia-PC5:/run/systemd/units$
Et effectivement, la partie à droite est rouge.
Désolée pour les balises code, ça ne se met pas comme je veux :/
[^] # Re: La destination existe
Posté par NeoX . Évalué à 2.
il faut preciser le langage
exemple
```sh
ton collage ici
```
dans run/systemd/units les liens ont l'air de pointé dans le meme dossier.
prends en un (wpa_supplicant) et regarde si sa cible est bien dans ce dossier ?
[^] # Re: La destination existe
Posté par Léa . Évalué à 1.
J'ai trouvé cela pour la cible de wpa_supplicant
Le contenu du dossier system :
Une recherche sur 51decb4502cd4092a0a39913687eb20b ne renvoie pas grand chose :
Il existe puisque whereis le trouve, mais aucune indication concernant son emplacement
[^] # Re: La destination existe
Posté par NeoX . Évalué à 2.
tu melanges tout.
tu regardes dans /etc/systemd/
qui te dis que le service se trouve dans /lib/systemd/…
puis tu vas lire dans /run/systemd…
ca n'a aucun sens.
tu as les fichiers de config dans /etc/systemd qui sont des liens vers /lib/systemd
et sont OK
tu as ensuite des fichiers d'executions dans /run/systemd
c'est là que tes liens apparaissent comme brisés.
c'est là qu'il faut investiguer.
le
ls -l invocation:wpa_supplicant.servicete dis que c'est un lien vers ** 51decb4502cd4092a0a39913687eb20b**c'est en rouge parfois clignotant, ce que veut dire que 51decb4502cd4092a0a39913687eb20b n'existe pas
ls -l 51decb4502cd4092a0a39913687eb20bpermettra de savoir s'il existe réellement ou non ou si ca renvoie encore ailleurs.[^] # Re: La destination existe
Posté par Léa . Évalué à 1. Dernière modification le 12 avril 2020 à 11:48.
Disons que j'ai du mal à m'y retrouver, je suis habituée aux interface graphiques…
Merci pour les précisions et explications détaillées ;)
Voilà, j'ai testé sur wpa_supplicant et cron.services, ces fichiers n'existent pas :
lrwxrwxrwx 1 root root 32 avril 10 13:52 invocation:wpa_supplicant.service -> 51decb4502cd4092a0a39913687eb20b
mia@mia-PC5:~$ ls -l 51decb4502cd4092a0a39913687eb20b
ls: impossible d'accéder à '51decb4502cd4092a0a39913687eb20b': Aucun fichier ou dossier de ce type
lrwxrwxrwx 1 root root 32 avril 10 13:52 invocation:cron.service -> 25f271bce59447c2a552e5e996a2b851
mia@mia-PC5:~$ ls -l 25f271bce59447c2a552e5e996a2b851
ls: impossible d'accéder à '25f271bce59447c2a552e5e996a2b851': Aucun fichier ou dossier de ce type
mia@mia-PC5:~$
En résumé :
les liens brisés sont dans /run/systemd/units
ls -la montre qu'ils pointent des des iD numériques en rouge
Ces cibles n'existent pas, vérification est faite ci-dessus.
Tandis que chez toi ils pointent vers /etc/systemd, ce qui est confirmé avec la commande find /etc/systemd/ -iname *.service -exec ls -l {} \;
Or cette commande me donne bien le même résultat.
Dans /etc/systemd/system/multi-users.terget.wants/
se trouve wpa_supplicant.service :
lrwxrwxrwx 1 root root 42 déc. 29 2018 /etc/systemd/system/multi-user.target.wants/wpa_supplicant.service -> /lib/systemd/system/wpa_supplicant.service
ainsi que cron.service :
lrwxrwxrwx 1 root root 32 déc. 29 2018 cron.service -> /lib/systemd/system/cron.service
clamsmtp est en rouge, ça n'apparait pas ici, je le signale en majuscules en début de ligne.
La cible n'existe donc pas d'après ce que tu as dit :
Ces liens pointent vers lib/systemd/system/
Contenu des fichiers :
Pour WPA supplicant :
[Unit]
Description=WPA supplicant
Before=network.target
After=dbus.service
Wants=network.target
IgnoreOnIsolate=true
[Service]
Type=dbus
BusName=fi.w1.wpa_supplicant1
ExecStart=/sbin/wpa_supplicant -u -s -O /run/wpa_supplicant
[Install]
WantedBy=multi-user.target
Alias=dbus-fi.w1.wpa_supplicant1.service
Pour cron :
[Unit]
Description=Regular background program processing daemon
Documentation=man:cron(8)
[Service]
EnvironmentFile=-/etc/default/cron
ExecStart=/usr/sbin/cron -f $EXTRA_OPTS
IgnoreSIGPIPE=false
KillMode=process
[Install]
WantedBy=multi-user.target
Bizarrement, ces fichiers ne sont pas exécutables, ni aucun se trouvant dans le dossier /lib/systemd/system d'ailleurs.
4 -rw-r--r-- 1 root root 251 nov. 16 2017 cron.service
4 -rw-r--r-- 1 root root 307 sept. 17 2019 wpa_supplicant.service
Bruno insiste sur le fait que tout va bien et que ces liens brisés sont un bug de Nemo.
Ça n'est pas la première fois que je passe du temps sur des problèmes qui se révèlent être des bugs au final.
[^] # Re: La destination existe
Posté par NeoX . Évalué à 2.
NON
tu as regardé dans le dossier /run/systemd/units pour savoir ou vont les liens
mais avec la commande
tu as fait le
ls -ldans TON dossier (~), pas dans le /runt/systemd/unitsdonc il faut verifier si 51dec…. existe DANS le dossier /run/systemd/units
soit en faisant
ls -l /run/systemd/units/51decb4502cd4092a0a39913687eb20bsoit en faisant
non il ne pointe pas vers /etc/systemd
ma commande cherche les fichiers services dans le dossier /etc/systemd
et il en trouve, mais qui pointe vers /lib/systemd…
[^] # Re: La destination existe
Posté par Léa . Évalué à 1. Dernière modification le 13 avril 2020 à 10:37.
Oups, en effet j'étais mal placée, je le refais ;)
Par contre quand tu dis :
Je parle des fichiers du dossier units.
C'est ce que j'avais compris quand tu disais :
Ils pointent vers quoi pour toi les fichiers du dossier units ?
[^] # Re: La destination existe
Posté par NeoX . Évalué à 2.
oui, sauf que j'étais dans /etc/systemd
pour le dossier /run/systemd/units
a priori j'ai un comportement similaire à chez toi
et pourtant ma machine fonctionne parfaitement.
c'est un serveur, je n'ai pas d'interface graphique pour tester l'affichage de ces units
[^] # Re: La destination existe
Posté par Léa . Évalué à 1. Dernière modification le 13 avril 2020 à 14:31.
Si c'est pareil pour toi, c'est donc normal.
Je me suis retrouvée à aller fouiner dans ces fichiers lorsque j'ai constaté mercredi que mes tâches cron ne s'étaient pas lancées.
Mais il n'y avait aucun rapport puisque le lendemain plus de problème de ce côté là.
Ma machine fonctionne donc bien aussi.
Du coup, je viens d'avoir l'idée de regarder si ces liens sont brisés dans une nouvelle installation en ligne (sur https://distrotest.net).
Et oui, ils sont brisés !
C'est bien un bug, j'imagine que ce fichier devait avoir une utilité à l'origine et ne doit plus servir à rien.
Merci de t'être penché sur le problème :)
[^] # Re: La destination existe
Posté par Léa . Évalué à 1. Dernière modification le 13 avril 2020 à 14:48.
Je ne peux plus éditer mon message.
Bruno disait :
Je dis donc n'importe quoi, c'est pas un bug, il doit s'agir d'un fonctionnement particulier propre à /run/systemd puisque ce sont des unités en cours d'exécution ;)
# Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Dossier units ?
Posté par Léa . Évalué à 2. Dernière modification le 11 avril 2020 à 10:38.
Bonjour,
Ce que j'ai pu trouver comme explications concernant ce dossier units :
Les taches de systemd sont organisées en tant qu'unités. Les unités les plus courantes sont les services (.services), les points de montage (.mount), les périphériques (.device), les sockets (.socket) ou les minuteurs (.timer). Par exemple, le démarrage du démon shell sécurisé est effectué par l'unité ssh.service.
Systemd place chaque service dans un groupe de contrôle (cgroup) dédié au service. Les noyaux modernes prennent en charge l'isolation des processus et l'allocation des ressources en fonction des groupes de contrôle.
Les cibles (targets) sont des groupes d'unités. Les cibles appellent les unités pour assembler le système. Par exemple, graphical.target appelle toutes les unités nécessaires pour démarrer un poste de travail avec une interface utilisateur graphique. Les cibles peuvent se superposer ou dépendre d'autres cibles. Au démarrage, systemd active la cible default.target qui est un alias pour une autre cible telle que graphic.target.
Systemd crée et gère les sockets utilisés pour la communication entre les composants du système. Par exemple, il crée d'abord le socket /dev/log puis démarre le démon syslog. Cette approche présente deux avantages. Premièrement, les processus communiquant avec syslog via /dev/log peuvent être démarrés en parallèle. Deuxièmement, les services écrasés peuvent être redémarrés sans que les processus qui communiquent via les sockets avec eux perdent leur connexion. Le noyau mettra la communication en mémoire tampon pendant que le processus redémarre.
https://wiki.debian.org/fr/systemd
L'arborescence du dossier : /run systemd/units
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Dossier units ?
Posté par Léa . Évalué à 1. Dernière modification le 11 avril 2020 à 12:52.
C'est depuis Nemo que ces liens brisés apparaissent
liens brisés vus depuis Nemo
Peut-être un bug du navigateur de fichier ?
D'autant plus que le problème qui m'a menée à ce fichier était sans rapport : les tâches cron se lancent à nouveau normalement sans que je n'ai rien modifié.
Je n'ai pas noté de problème particulier hormis cette ligne d'erreur au démarrage Raise "network interface Failed"
Je vois cependant ces 2 lignes en rouge :
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2. Dernière modification le 11 avril 2020 à 14:09.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Dossier units ?
Posté par Léa . Évalué à 1.
Ok, merci pour ton avis rassurant.
J'ouvrirai éventuellement une autre discussion pour le problème de carte réseau, mais elle semble fonctionner correctement, je vais attendre un peu.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.