[Configuration de fstrim.timer] fichier stamp-fstrim.timer (Résolu)

[waitnsea]

Bonjour,

J'avais posté ici mes soucis avec fstrim.timer, service activé mais ne générant pas de log donc ne lançant probablement pas le fstrim.service associé.
Je retrouve dans mon système

Code : Tout sélectionner

asus% locate fstrim.timer
/etc/systemd/system/multi-user.target.wants/fstrim.timer
/usr/lib/systemd/system/fstrim.timer
/var/lib/systemd/timers/stamp-fstrim.timer

un fichier (il est vide) stamp-fstrim.timer qui n'existe pas dans mon 2° OS, une Debian-Sid où les fstrim.timer et fstrim.service existent aux mêmes emplacements et avec le même contenu.
Quelle est l'utilité de ce fichier ?

[benjarobin]

Ce fichier permet d'indiquer quand le timer a été déclenché (que je sache).
Sinon tu peux faire le teste suivant, quelle est la sortie de :

Code : Tout sélectionner

cat /etc/fstab
mount

systemctl start fstrim.service
journalctl -b -u fstrim.service

[waitnsea]

Bonjour Benjarobin, merci de répondre :

Code : Tout sélectionner

asus% cat /etc/fstab
# 
# /etc/fstab: static file system information
#
# <file system>                                 <dir>           <type>          <options>       <dump>  <pass>
# /dev/sda5 LABEL=OS
UUID=081004d2-d119-466b-b50a-b82b4fcaf0b2       /               ext4            rw,relatime,data=ordered        0 1

# /dev/sda6 LABEL=HOME
UUID=faf3c9fe-b7cc-4235-8d98-d16a0945cd05       /home           ext4            rw,relatime,data=ordered        0 2

# /dev/sdb5
UUID=c187ea1a-210e-4b2a-b5e4-bd988e804319       none            swap            defaults        0 0

# /dev/sdb2 LABEL=OSECOURS
UUID=57824b53-08c4-49d0-9f7d-516af89c495d       /home/jpf/DD_SDB/ ext4          defaults        0 2

# /dev/sdb7 LABEL=ARCHIVES
UUID=1bf20e2b-f6cd-4640-ac55-4e32be89b3ab       /mnt             ext4           defaults        0 2

Code : Tout sélectionner

asus% mount
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
sys on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
dev on /dev type devtmpfs (rw,nosuid,relatime,size=1980952k,nr_inodes=495238,mode=755)
run on /run type tmpfs (rw,nosuid,nodev,relatime,mode=755)
/dev/sda5 on / type ext4 (rw,relatime,data=ordered)
securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755)
cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/usr/lib/systemd/systemd-cgroups-agent,name=systemd)
pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime)
cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset)
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpu,cpuacct)
cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory)
cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices)
cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer)
cgroup on /sys/fs/cgroup/net_cls type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls)
cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=22,pgrp=1,timeout=300,minproto=5,maxproto=5,direct)
mqueue on /dev/mqueue type mqueue (rw,relatime)
debugfs on /sys/kernel/debug type debugfs (rw,relatime)
hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime)
tmpfs on /tmp type tmpfs (rw)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,relatime)
configfs on /sys/kernel/config type configfs (rw,relatime)
/dev/sda6 on /home type ext4 (rw,relatime,data=ordered)
/dev/sdb2 on /home/jpf/DD_SDB type ext4 (rw,relatime,data=ordered)
/dev/sdb6 on /mnt type ext4 (rw,relatime,data=ordered)
tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,size=396812k,mode=700,uid=1000,gid=100)
gvfsd-fuse on /run/user/1000/gvfs type fuse.gvfsd-fuse (rw,nosuid,nodev,relatime,user_id=1000,group_id=100)
fusectl on /sys/fs/fuse/connections type fusectl (rw,relatime)

Code : Tout sélectionner

[root@asus ~]# systemctl start fstrim.service

-> un temps d'arrêt et pas de retour, on en avait déjà parlé, c'est un service qui ne semble pas installable en tant que tel sur mon système :

Code : Tout sélectionner

[root@asus ~]# systemctl enable fstrim.service
The unit files have no [Install] section. They are not meant to be enabled
using systemctl.
Possible reasons for having this kind of units are:
1) A unit may be statically enabled by being symlinked from another unit's
   .wants/ or .requires/ directory.
2) A unit's purpose may be to act as a helper for some other unit which has
   a requirement dependency on it.
3) A unit may be started when needed via activation (socket, path, timer,
   D-Bus, udev, scripted systemctl call, ...).

Code : Tout sélectionner

[root@asus ~]# journalctl -b -u fstrim.service
-- Logs begin at jeu. 2014-09-18 09:54:13 CEST, end at dim. 2014-11-30 12:40:51 CET. --

[Moviuro]

Normal que ça veuille pas se enable, puisque ça n'a pas de sens : il faut enable le timer (et enlever le tien : celui de /etc ; puisque c'est mal d'avoir le même service dans /etc et /usr/lib, man 5 systemd.unit)

Le stamp n'est là que pour garder une trace de la date à laquelle le timer a été lancé la dernière fois (ls -l dessus pour s'en convaincre).

Au passage, findmnt est beaucoup plus lisible

[waitnsea]

Normal que ça veuille pas se enable, puisque ça n'a pas de sens : il faut enable le timer (et enlever le tien : celui de /etc ; puisque c'est mal d'avoir le même service dans /etc et /usr/lib, man 5 systemd.unit)

Le stamp n'est là que pour garder une trace de la date à laquelle le timer a été lancé la dernière fois (ls -l dessus pour s'en convaincre).

Au passage, findmnt est beaucoup plus lisible

Bonjour Moviuro,

Ça fait déjà quelques semaines que j'ai compris que fstrim.service ne pouvait être enable, et il ne l'est pas bien sûr : je n'ai, dans mon etc que le lien fstrim.timer (dans /etc/systemd/system/multi-user.target.wants/) pointant vers /usr/lib/systemd/system/fstrim.timer

Code : Tout sélectionner

asus% locate fstrim.service
/usr/lib/systemd/system/fstrim.service

C'est joli findmnt, merci du tuyau

Code : Tout sélectionner

asus% findmnt
TARGET                           SOURCE      FSTYPE        OPTIONS
/                                /dev/sda5   ext4          rw,relatime,data=ordered
├─/proc                          proc        proc          rw,nosuid,nodev,noexec,relatime
│ └─/proc/sys/fs/binfmt_misc     systemd-1   autofs        rw,relatime,fd=22,pgrp=1,timeout=300,minproto=5,maxproto=5,direct
│   └─/proc/sys/fs/binfmt_misc   binfmt_misc binfmt_misc   rw,relatime
├─/sys                           sys         sysfs         rw,nosuid,nodev,noexec,relatime
│ ├─/sys/kernel/security         securityfs  securityfs    rw,nosuid,nodev,noexec,relatime
│ ├─/sys/fs/cgroup               tmpfs       tmpfs         ro,nosuid,nodev,noexec,mode=755
│ │ ├─/sys/fs/cgroup/systemd     cgroup      cgroup        rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/usr/lib/systemd/sy
│ │ ├─/sys/fs/cgroup/cpuset      cgroup      cgroup        rw,nosuid,nodev,noexec,relatime,cpuset
│ │ ├─/sys/fs/cgroup/cpu,cpuacct cgroup      cgroup        rw,nosuid,nodev,noexec,relatime,cpu,cpuacct
│ │ ├─/sys/fs/cgroup/memory      cgroup      cgroup        rw,nosuid,nodev,noexec,relatime,memory
│ │ ├─/sys/fs/cgroup/devices     cgroup      cgroup        rw,nosuid,nodev,noexec,relatime,devices
│ │ ├─/sys/fs/cgroup/freezer     cgroup      cgroup        rw,nosuid,nodev,noexec,relatime,freezer
│ │ ├─/sys/fs/cgroup/net_cls     cgroup      cgroup        rw,nosuid,nodev,noexec,relatime,net_cls
│ │ └─/sys/fs/cgroup/blkio       cgroup      cgroup        rw,nosuid,nodev,noexec,relatime,blkio
│ ├─/sys/fs/pstore               pstore      pstore        rw,nosuid,nodev,noexec,relatime
│ ├─/sys/kernel/debug            debugfs     debugfs       rw,relatime
│ ├─/sys/kernel/config           configfs    configfs      rw,relatime
│ └─/sys/fs/fuse/connections     fusectl     fusectl       rw,relatime
├─/dev                           dev         devtmpfs      rw,nosuid,relatime,size=1980952k,nr_inodes=495238,mode=755
│ ├─/dev/shm                     tmpfs       tmpfs         rw,nosuid,nodev
│ ├─/dev/pts                     devpts      devpts        rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000
│ ├─/dev/hugepages               hugetlbfs   hugetlbfs     rw,relatime
│ └─/dev/mqueue                  mqueue      mqueue        rw,relatime
├─/run                           run         tmpfs         rw,nosuid,nodev,relatime,mode=755
│ └─/run/user/1000               tmpfs       tmpfs         rw,nosuid,nodev,relatime,size=396812k,mode=700,uid=1000,gid=100
│   └─/run/user/1000/gvfs        gvfsd-fuse  fuse.gvfsd-fu rw,nosuid,nodev,relatime,user_id=1000,group_id=100
├─/tmp                           tmpfs       tmpfs         rw
├─/home                          /dev/sda6   ext4          rw,relatime,data=ordered
│ └─/home/jpf/DD_SDB             /dev/sdb2   ext4          rw,relatime,data=ordered
└─/mnt                           /dev/sdb6   ext4          rw,relatime,data=ordered

[benjarobin]

Je n'ai jamais indiqué de faire un enable, car en effet cela n'a aucun sens. Mais faire un start sur ce genre de service à un sens !
Par contre ce que je ne comprend pas, c'est que suite à un start manuel, il n'y est aucune trace dans les log (journalctl)

[waitnsea]

Ça doit relever du même mystère qui empêche, ou le lancement, ou le log, au déclenchement hebdomadaire du timer....
Dans la Debian les fichiers sont absolument identiques, de même si je réinstalle util-linux
Et le timer est bien là :

Code : Tout sélectionner

asus% systemctl status fstrim.timer
● fstrim.timer - Discard unused blocks once a week
   Loaded: loaded (/usr/lib/systemd/system/fstrim.timer; enabled)
   Active: active (waiting) since dim. 2014-11-30 14:19:09 CET; 23min ago
     Docs: man:fstrim

[waitnsea]

Bonour à tous,
Je "remonte" un peu mon problème :
* Pour y voir clair sans attendre une semaine j'ai mis fstrim.timer à "daily" au lieu de weekly
* Voici donc le résultat de mon démarrage du jour :

Code : Tout sélectionner

# systemd-analyze blame
          6.577s fstrim.service
           976ms dkms.service
           641ms systemd-fsck@dev-disk-by\x2duuid-57824b53\x2d08c4\x2d49d0\x2d9f7d\x2d516af89c495d.service
           537ms systemd-networkd.service
           392ms systemd-fsck@dev-disk-by\x2duuid-1bf20e2b\x2df6cd\x2d4640\x2dac55\x2d4e32be89b3ab.service
           321ms systemd-journald.service
           ....etc....

Donc le service fstrim.service a été lancé par fstrim.timer qui a fonctionné

Code : Tout sélectionner

# systemctl status fstrim.service
● fstrim.service - Discard unused blocks
   Loaded: loaded (/usr/lib/systemd/system/fstrim.service; static)
   Active: inactive (dead) since mar. 2014-12-02 07:44:58 CET; 4h 33min ago
  Process: 464 ExecStart=/sbin/fstrim -a (code=exited, status=0/SUCCESS)
 Main PID: 464 (code=exited, status=0/SUCCESS)

Aucune commande de stop n'ayant été lancée, il s'est arrêté sans doute en fin d'éxécution - normale ? - avec le statut status=0/SUCCESS
Aurait-il fonctionné normalement et l'erreur ne serait-elle que la transmission au journal ?
Les autres services donnent des "logs" tout à fait normaux quand je questionne journalctl -u , exemple :

Code : Tout sélectionner

# journalctl -u dkms.service   
-- Logs begin at jeu. 2014-09-18 09:54:13 CEST, end at mar. 2014-12-02 12:28:26 CET. --
nov. 23 20:53:21 asus dkms[423]: Kernel preparation unnecessary for this kernel.  Skipping...
nov. 23 20:53:21 asus dkms[423]: Building module:
nov. 23 20:53:24 asus dkms[423]: cleaning build area....
nov. 23 20:54:12 asus dkms[423]: make KERNELRELEASE=3.17.3-1-ARCH -C /usr/lib/modules/3.17.3-1-ARCH/build M=/var/lib/dkms/vboxhost
nov. 23 20:54:15 asus dkms[423]: cleaning build area....
nov. 23 20:54:15 asus dkms[423]: Kernel cleanup unnecessary for this kernel.  Skipping...
nov. 23 20:54:15 asus dkms[423]: DKMS: build completed.

[benjarobin]

Normaux ? Non... Même le log de dkms.service est anormal. Il manque les lignes : Starting ... , Started ..., Stopping ... et Stopped ...

Edit: Ok... J'ai compris, voir https://bbs.archlinux.org/viewtopic.php ... 3#p1454243
Je ne démarre pas avec l'option quiet sur la ligne kernel, et cela influe sur les messages de journalctl, donc j'ai plus de détail que toi. Voir aussi : https://bugs.archlinux.org/task/41942

Donc en gros, si tu utilises quiet, systemd va avoir comme niveau notice au lieu de info. Tu peux avoir quiet et un niveau de log info, il faut juste avoir sur la ligne de boot :

Code : Tout sélectionner

quiet systemd.log_level=info

Donc en résumé, tout fonctionne normalement depuis le début... Désolé...

[waitnsea]

Merci de ta réponse
J'enlève de suite le quiet de

Code : Tout sélectionner

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash nomodeset video=vesa:off vga=normal"

j'update le grub....
Et je revois demain, en espérant que ce soit la solution...

[benjarobin]

Je n'ai pas dit d'enlever quiet... Surtout si tu utilises un boot splash...

[waitnsea]

Bon, j'ai été trop vite..., je vais le remettre (oui j'ai un boot splash), mais déjà tu as trouvé LA solution , parcequ'au reboot :

Code : Tout sélectionner

# systemctl start fstrim.service
[root@asus ~]#  journalctl -u fstrim.service
-- Logs begin at jeu. 2014-09-18 09:54:13 CEST, end at mar. 2014-12-02 13:35:33 CET. --
déc. 02 13:35:29 asus systemd[1]: Starting Discard unused blocks...
déc. 02 13:35:33 asus systemd[1]: Started Discard unused blocks.

tout rentre dans l'ordre.
Bon
je coche "Résolu"
je remets mon boot non verbeux et timer sur weekly (pas la peine de "tailler" mon SSD jusqu'à ce qu'il tombe en menus morceaux)
j'attends tranquillement la solution du bug du quiet...

Merci encore

[benjarobin]

j'attends tranquillement la solution du bug du quiet...

As tu simplement lu mon message ? Je donne la solution propre... Il n'y a jamais eu de bug, le rapport de bug indique bien que ce n'est pas un bug, et que c'est bien un comportement normal.

En gros si tu as quiet sur la ligne de boot, tu dois avoir en plus systemd.log_level=info pour avoir ce niveau de détail. Après rien ne t'oblige d'avoir ce niveau de détail dans les logs. C'est très personnel...

[waitnsea]

Merci d'avoir précisé,
Non je n'avais pas lu à fond, je comptais relire tout ça en rentrant, j'avais un travail urgent à faire...
Je complète donc le grub. Encore bravo