Boycott systemd

[megahead13]

Νταξ, αυτό δεν είναι απαραίτητα κακό. Χρήσιμο για PC που η κάρτα δικτύου τους δεν υποστηρίζει PXE boot

[jim_p]

Ανοιξα νωριτερα το pc και παρατηρησα το led του σκληρου που εμεινε για πολλη ωρα αναμενο, σαν να εκανε fstrim. Στο συγκεκριμενο συστημα, το fstrim γινεται στην πρωτη εκκινηση καθε Δευτερα, οποτε σημερα ηταν λιγο νωρις για να γινει. Ηταν οντως το fstrim γιατι οταν τελειωσε, το ειχε πρωτη μουρη στο systemd-analyze blame.

3min 40.590s fstrim.service

Τωρα που τελειωσε λεει οτι οντως ετρεξε πριν λιγο (απο το systemctl status fstrim)

     Active: inactive (dead) since Sun 2025-06-01 10:41:33 EEST; 20s ago

αλλα οσο ετρεχε, το ιδιο output ελεγε για Δευτερα 2/6, στις 0:30 πχ.
Γιατι του ηρθε να τρεξει σημερα? Στο συγκεκριμενο συστημα τρεχει εδω και χρονια καθε Δευτερα πρωι στην πρωτη εκκινηση, οποτε ξερω ποτε να το περιμενω καθε φορα και δεν εκνευριζομαι. Αντιθετα, στο λαπτοπ απλα τρεχει οταν θελει, αλλα παντα μετα την ημερομηνια που λεει.

Να προσθεσω εδω πως εδω και ~1 μηνα ειμαι με alpine στο rpi3b και εχω ησυχασει απο το fstrim που εκανε το debian καθε βδομαδα στην καημενη την καρτα του. Ειμαι εμφανες πλεον πως η καρτα του εχει πεσει σε επιδοσεις λογω αυτου και συντομα θα χρειαστει αντικατασταση.

[imitheos]

Γιατι του ηρθε να τρεξει σημερα?

Τι λέει το systemctl list-timers fstrim; Επίσης τρέξε journactl -u fstrim.service και βάλε το εδώ.

Να προσθεσω εδω πως εδω και ~1 μηνα ειμαι με alpine στο rpi3b και εχω ησυχασει απο το fstrim που εκανε το debian καθε βδομαδα στην καημενη την καρτα του. Ειμαι εμφανες πλεον πως η καρτα του εχει πεσει σε επιδοσεις λογω αυτου και συντομα θα χρειαστει αντικατασταση.

Ο εγκαταστάτης δεν μπορεί να ξέρει τι τρέχεις εσύ. Αν θεωρείς ότι δεν πρέπει σε SD κάρτα να τρέχει fstrim κάθε εβδομάδα, κάνε το κάθε μήνα ή απενεργοποίησε το εντελώς.

[jim_p]

$ systemctl list-timers fstrim
NEXT                                  LEFT LAST                            PASSED UNIT         ACTIVATES     
Mon 2025-06-09 00:00:00 EEST 1 week 0 days Mon 2025-06-02 00:39:47 EEST 53min ago fstrim.timer fstrim.service

$ sudo journalctl -u fstrim.service
Jun 02 00:39:47 mitsos systemd[1]: Starting fstrim.service - Discard unused blocks...
Jun 01 10:41:33 mitsos systemd[1]: fstrim.service: Deactivated successfully.
Jun 01 10:41:33 mitsos systemd[1]: Finished fstrim.service - Discard unused blocks.

Για το αλλο που λες, δεν ειναι installer, εινια image και μαλιστα επισημο απο το debian, αλλα μαλλον ο maintainer του θεωρει οτι πρεπει να τρεχει fstrim και σε sd cards.
https://raspi.debian.net/tested-images/

- - - Updated - - -

$ date
Sun Jun  1 11:41:08 AM EEST 2025
$ sudo hwclock 
[sudo] password for jim: 
2025-06-02 01:43:09.686826+03:00

Αν ειναι ποτε δυνατον! Μαλλον αυτο εγινε και ετρεξε.

[imitheos]

Για το αλλο που λες, δεν ειναι installer, εινια image και μαλιστα επισημο απο το debian, αλλα μαλλον ο maintainer του θεωρει οτι πρεπει να τρεχει fstrim και σε sd cards.
https://raspi.debian.net/tested-images/

Τα fstrim.{service,timer} έρχονται με το πακέτο util-linux και οι dev του αποφάσισαν (κατ εμέ σωστά) ότι πρέπει να τρέχει ο timer εβδομαδιαία. Οι διανομές λοιπόν πακετάρουν το συγκεκριμένο αρχείο και είτε αφήνουν το upstream default ή μπορούν να το αλλάξουν αν θεωρούν ό,τι πρέπει.

Δεν ξέρω τι είναι το συγκεκριμένο raspi image. Υπάρχουν δύο γραμμές σκέψης. Η μία είναι να δίνεις κάτι σαν "διανομή" που να έχει αλλαγμένα defaults που να ταιριάζουν σε ras-pi, οπότε έχεις δίκιο ότι φταίει ο maintainer. Η άλλη είναι ένα 100% debian που απλά το εγκαθιστά κάποιος και το παρέχει σαν image ώστε να έχεις εύκολα ένα έτοιμο μηχάνημα. Αν είναι αυτό, τότε δεν φταίει ο maintainer. Σου κάνει την εξυπηρέτηση να σου δώσει έτοιμο image ώστε να μην παιδεύεσαι και εξαρτάται από εσένα να το σενιάρεις στα μέτρα σου (όπως και σε x86 debian).


Όσον αφορά τι το έπιασε και έτρεξε σήμερα.

Μαΐ 12 10:17:23 tardis.home.arpa systemd[1]: Starting Discard unused blocks on filesystems from /etc/fstab...
Μαΐ 12 10:17:23 tardis.home.arpa systemd[1]: fstrim.service: Deactivated successfully.
Μαΐ 12 10:17:23 tardis.home.arpa systemd[1]: Finished Discard unused blocks on filesystems from /etc/fstab.
-- Boot 357ee440d60b4d3898ae2faad1d23d73 --
Μαΐ 19 10:52:58 tardis.home.arpa systemd[1]: Starting Discard unused blocks on filesystems from /etc/fstab...
Μαΐ 19 10:52:58 tardis.home.arpa systemd[1]: fstrim.service: Deactivated successfully.
Μαΐ 19 10:52:58 tardis.home.arpa systemd[1]: Finished Discard unused blocks on filesystems from /etc/fstab.
-- Boot 04e1ed75c76e4a628ad279e39a84b3d4 --
Μαΐ 26 07:09:17 tardis.home.arpa systemd[1]: Starting Discard unused blocks on filesystems from /etc/fstab...
Μαΐ 26 07:09:17 tardis.home.arpa systemd[1]: fstrim.service: Deactivated successfully.
Μαΐ 26 07:09:17 tardis.home.arpa systemd[1]: Finished Discard unused blocks on filesystems from /etc/fstab.

Όπως βλέπεις, σε εμένα τρέχει κανονικά κάθε εβδομάδα. Αν στις 26 δεν άνοιγα καθόλου το μηχάνημα για όλη την ημέρα, τότε θα έτρεχε στις 27 με το που θα το άνοιγα και μετά θα συνέχιζε 7 ημέρες από τις 27.

$ systemctl list-timers fstrim
NEXT                                  LEFT LAST                            PASSED UNIT         ACTIVATES     
Mon 2025-06-09 00:00:00 EEST 1 week 0 days Mon 2025-06-02 00:39:47 EEST 53min ago fstrim.timer fstrim.service

$ sudo journalctl -u fstrim.service
Jun 02 00:39:47 mitsos systemd[1]: Starting fstrim.service - Discard unused blocks...
Jun 01 10:41:33 mitsos systemd[1]: fstrim.service: Deactivated successfully.
Jun 01 10:41:33 mitsos systemd[1]: Finished fstrim.service - Discard unused blocks.

Όπως βλέπεις, το timer έτρεξε κανονικά την δευτέρα. Κάτι έγινε με το ρολόι σου και δεν είχε σωστή ώρα. Έδειχνε 02 Ιουνίου και μετά γύρισε 01 Ιουνίου. Υποθέτω ότι αν τρέξεις σκέτο journalctl και κοιτάξεις την έξοδο θα δεις κάποια στιγμή να τρέχει κάποια υπηρεσία συγχρονισμού (πχ ntpdate) και ξαφνικά να πηγαίνει από 02 Ιουνίου πίσω σε 01.

[jim_p]

Εδω παντως δεν ισχυει αυτο που λες με τις ημερομηνιες. Στο pc, που ειναι 100% σιγουρο οτι τρεχει στην πρωτη εκκινηση καθε Δευτερα, αν δεν το ανοιγα την Δευτερα και το ανοιγα την Τριτη θα ετρεχε την Τριτη. Αν δεν το ανοιγα ουτε την Τριτη και το ανοιγα την Τεταρτη, θα ετρεχε την Τεταρτη κοκ.
Αντιθετα, στο λαπτοπ (και στο rpi) εχει διαφορετικο σκεπτικο, μαλλον γιατι εινια νεοτερες οι εγκαταστασεις αρα και νεοτερο καποιο configuration file. Δεν το κανει με την εκκινηση την Δευτερα, αλλα καποια τυχαια στιγμη μεσα στη μερα. Αν δεν του κατσει, γιατι πχ μπορει να κανω τερματισμο ως τοτε, το βαζει αλλη στιγμη στην επομενη εκκινηση και παει οπως παραπανω. Για προφανεις λογους, θα ποσταρω αυριο το output του "systemctl list-timers fstrim" και των 2.

[imitheos]

Εδω παντως δεν ισχυει αυτο πουθ λες με τις ημερομηνιες. Στο pc, που ειναι 100% σιγουρο οτι τρεχει στην πρωτη εκκινηση καθε Δευτερα, αν δεν το ανοιγα την Δευτερα και το ανοιγα την Τριτη θα ετρεχε την Τριτη. Αν δεν το ανοιγα ουτε την Τριτη και το ανοιγα την Τεταρτη, θα ετρεχε την Τεταρτη κοκ.
Αντιθετα, στο λαπτοπ (και στο rpi) εχει διαφορετικο σκεπτικο, μαλλον γιατι εινια νεοτερες οι εγκαταστασεις αρα και νεοτερο καποιο configuration file. Δεν το κανει με την εκκινηση την Δευτερα, αλλα καποια τυχαια στιγμη μεσα στη μερα. Αν δεν του κατσει, γιατι πχ μπορει να κανω τερματισμο ως τοτε, το βαζει αλλη στιγμη στην επομενη εκκινηση και παει οπως παραπανω. Για προφανεις λογους, θα ποσταρω αυριο το output του "systemctl list-timers fstrim" και των 2.

Δεν καταλαβαίνω τι εννοείς. Εγώ τι διαφορετικό είπα; Η λειτουργία είναι όπως της παλιάς υποδομής anacron. Υπό κανονικές συνθήκες που το μηχάνημα είναι ανοιχτό, τρέχει την ώρα που πρέπει (εν προκειμένω κάθε εβδομάδα την ίδια ημέρα / ώρα). Αν το μηχάνημα είναι κλειστό και ανοίξει σε κάποιο διάστημα > 7 * 24 * 3600, τότε βλέπει ότι πέρασε το διάστημα που έπρεπε και το τρέχει τότε.

Αν δίνεις έμφαση σε αυτό που έκανα bold, πολλοί timers έχουν randomized delay (το fstrim έχει 100 λεπτά) ώστε να μην τρέχουν όλοι μαζί (ειδικά σε τέτοιες περιπτώσεις που θα τύχουν όλοι μαζί στην εκκίνηση) και γονατίζουν το σύστημα. Για την διαφορά που λες λοιπόν μεταξύ pc και laptop, δεν νομίζω να άλλαξαν τα αρχεία timers εδώ και πολύ καιρό (οπότε θα πρέπει να μιλάμε για κάποια αρχαία διανομή). αλλά μάλλον οφείλεται σε αυτό το random που βλέπεις διαφορετικές συμπεριφορές. Και αυτές οι διακυμάνσεις θα πρέπει να είναι όμως μικρές (πχ τα 100 λεπτά που ανέφερα) και όχι ώρες μετά στην ημέρα που ανέφερες.

[jim_p]

Αυτο λεω, το randomized delay. Στο desktop δεν εχει κατι τετοιο, θα τρεξει στην εκκινηση της Δευτερας θες δεν θες. For the record, η εγκατασταση στο desktop εγινε τελη Μαϊου 2016 (ειναι 9 χρονων πλεον!), στο λαπτοπ τελη Ιουνιου 2024 και στο rpi ειχε γινει μεσα Σεπτεμβριου του 2022 (αν θυμαμαι καλα)

[imitheos]

Αυτο λεω, το randomized delay. Στο desktop δεν εχει κατι τετοιο, θα τρεξει στην εκκινηση της Δευτερας θες δεν θες. For the record, η εγκατασταση στο desktop εγινε τελη Μαϊου 2016 (ειναι 9 χρονων πλεον!), στο λαπτοπ τελη Ιουνιου 2024 και στο rpi ειχε γινει μεσα Σεπτεμβριου του 2022 (αν θυμαμαι καλα)

Αν τρέξεις cat /usr/lib/systemd/system/fstrim.timer δεν έχει το randomizedelay ; Παίζει ρόλο πότε εγκατέστησες το λειτουργικό στο desktop και όχι τι τρέχει; Αν το 2016 εγκατέστησες πχ debian testing όπως αποτυπωνόταν τότε (πχ debian 10) και με συνεχείς αναβαθμίσεις έφτασες όπως αποτυπώνεται σήμερα (σε λίγο trixie), αυτό θα έχει διαφορά από το να εγκαθιστούσες debian trixie σήμερα; (ναι κάποιες διαφορές θα έχει αλλά όχι για αυτό που συζητάμε).

[jim_p]

Εχει

$ cat /usr/lib/systemd/system/fstrim.timer
[Unit]
Description=Discard unused filesystem blocks once a week
Documentation=man:fstrim
ConditionVirtualization=!container
ConditionPathExists=!/etc/initrd-release

[Timer]
OnCalendar=weekly
AccuracySec=1h
Persistent=true
RandomizedDelaySec=100min

[Install]
WantedBy=timers.target

Εγω θελω να τρεχει καποια στανταρ ημερα και ωρα, οχι να ειναι τυχαιο, οποτε με βολευει τωρα που δεν ειναι random.

[imitheos]

Εχει

$ cat /usr/lib/systemd/system/fstrim.timer
[Unit]
Description=Discard unused filesystem blocks once a week
Documentation=man:fstrim
ConditionVirtualization=!container
ConditionPathExists=!/etc/initrd-release

[Timer]
OnCalendar=weekly
AccuracySec=1h
Persistent=true
RandomizedDelaySec=100min

[Install]
WantedBy=timers.target

Εγω θελω να τρεχει καποια στανταρ ημερα και ωρα, οχι να ειναι τυχαιο, οποτε με βολευει τωρα που δεν ειναι random.

Από αυτό που έκανες post, συμπέρανες ότι δεν είναι random;

Και το debian και τα άλλα σου λειτουργικά σου είναι μια χαρά. Η διαφορετική συμπεριφορά που βλέπεις έγκειται στο ότι κάποια ημέρα μπορεί να είναι κλειστό το ένα μηχάνημα, το άλλο να έχει μπαταρία / πυκνωτές στα τελειώματα και να χάνει ώρα, κτλ, κτλ.

[jim_p]

Η εγκατασταση εινια 9 χρονων, αρα πες ~500 εβδομαδων. Αντε πες οτι δεν ειχα παρατηρησει απο τοτε οτι γινεται στην πρωτη εκκινηση καθε Δευτερα το fstrim, αλλα μονο τα τελευταια 4-5 χρονια (επειδη ο δισκος παραεινιε γεματος και παιρνιε λιγα λεπτα για να ολοκληρωθει). Αμεσως αμεσως μιλαμε για 200+ εκκινησεις, που σε ΟΛΕΣ ετρεξε το fstrim αμεσως, αρα το random εκει δεν ειναι random στην περιπτωση μου. Ή εινια σαν να εινια 0. Και σε μενα αυτο βολευει, γιατι ξερω οτι τη Δευτερα το πρωι που θα ανοιξω το pc, θα το αφησω 5 λεπτα να κανει fstrim για να μην βριζω που θα αργει να ανοιξει brave, tb, τερματικο που ανοιγω εγω σε καθε εκκινηση (εκτος δηλαδη απο conky κλπ που ξεκινανε με το login).

Ειναι ομως random στις αλλες εγκαταστασεις. Αν θυμασαι, περυσι εψαχνα τροπο να βλεπω στο motd του rpi ποτε θα τρεξει το επομενο fstrim. Εκει δεν βολευε το να τρεχει οποτε ηθελε γιατι το fstrim εκανε τον ιδιο χρονο με το desktop και το rpi σερνοταν παρα πολυ. Φαντασου να κανεις 2+ λεπτα να συνδεθεις τοπικα με ssh ή 5+ λεπτα να εγκατασταθει κατι επειδη ταυτοχρονα τρεχει και το fstrim.

Στο λαπτοπ δεν ειναι ακομα αισθητη η καθυστερηση απο το fstrim οταν τρεχει, μιας και κανει πχ 10 δευτερα, οποτε εκει δεν με ενοχλει που ειναι random το delay.

[imitheos]

Όπως διάβασες, το 100min randomized delay υπάρχει και στο desktop. Αυτό φυσικά μπορεί να δώσει delay 1 λεπτό μια και random αλλά μου φαίνεται παράξενο 200 φορές να έδωσε χρόνους < 2min (ώστε να σου φανεί κατευθείαν στην εκκίνηση). Αυτό που λες λοιπόν δεν βγάζει νόημα αλλά αφού αυτό παρατηρείς πάω πάσο. Κακώς μπήκαμε σε αυτό το φιλοσοφικό θέμα.

Το πρόβλημά σου είναι ότι το ρολόι σου πήγε μία ημέρα μετά. Αυτό πρέπει να ψάξεις για να μην συμβεί ξανά.

[jim_p]

Δεν ειναι φιλοσοφικο θεμα, ειναι υπαρκτο. Και δεν μιλαμε για χρονους λιγοτερο απο 2 λεπτα, μιλαμε για 0. Το fstrim ξεκιναει πριν καν πεταχτει ο lightdm και κανει autologin. Μπορω να το καταλαβω οτι ξεκινησε ακομα και αν δω το tty με τα boot messages.

Για το ρολοϊ δεν ξερω. Η αληθεια ειναι πως ειχαμε μια διακοπη ρευματος πριν 2+ βδομαδες. Επειδη ξερω οτι μπορει να χαθηκε η ωρα (και οι αλλες ρυθμισεις) απο το bios, το τσεκαρα τοτε και ηταν μια χαρα. Να θυμαμαι λαθος? Μπορει. Αλλα σιγουρα τοτε θα πηγαινε πισω το ρολοϊ, οχι μπροστα. Καποτε ηθελα να βαλω στο rc.local ενα hwclock -w να ειμαι σιγουρος, αλλα μετα κοψανε το initscripts (πακετο που παρεχει το rc.local) με conflict σε οτι εχει το systemd.

$ sudo apt-get install initscripts 
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Solving dependencies... Error!
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 systemd-sysv : Conflicts: initscripts but 3.14-4 is to be installed
                Conflicts: insserv but 1.26.0-1 is to be installed
                Conflicts: startpar but 0.66-1 is to be installed
                Conflicts: sysv-rc but 3.14-4 is to be installed
E: Error, pkgProblemResolver::Resolve generated breaks, this may be caused by held packages.
E: The following information from --solver 3.0 may provide additional context:
   Unable to satisfy dependencies. Reached two conflicting decisions:
   1. systemd-sysv:amd64 is selected for install
   2. systemd-sysv:amd64 is selected for removal because:
      1. initscripts:amd64=3.14-4 is selected for install
      2. systemd-sysv:amd64 Conflicts initscripts

[Gentoo]

Btw μήπως ήρθε η ώρα ο τίτλος του νήματος να αλλάξει και να φύγει το boycott?

Μετά από 11 χρόνια, το systemd έχει γίνει το industry standard και το μποϊκοτάζ απέτυχε απ' ότι φάνηκε