Boycott systemd

[imitheos]

Ωραια ολα αυτα που εγραψες, αλλα δεν εχω καν coredump! Και τωρα αγχωθηκα περισσοτερο.

Δεν έκατσα ποτέ να ασχοληθώ με το τι κάνει ο systemd-coredump. Ο systemd ίσως επέκτεινε την λειτουργία core dumping ή ίσως την ενσωμάτωσε με τα υπόλοιπά του στοιχεία. Γενικά όμως η λειτουργία δεν είναι κάτι που επινόησε ο systemd φυσικά αλλά υπάρχει χρόνια και λειτουργεί ακόμη και να μην τον έχεις εγκατεστημένο. Για αυτό έγραψα πριν ότι εξαρτάται από το πώς έχει χτιστεί ο πυρήνας σου.

Λογικά αν γράψεις "/usr/sbin/sysctl kernel.core_pattern" θα πρέπει να σου επιστρέψει "core". Αν είναι έτσι, μπορείς να την απενεργοποιήσεις τρέχοντας το 1 που έγραψα πριν.
Έπρεπε να σκεφτώ ότι δεν θα τον έχεις εγκατεστημένο από το γεγονός ότι το αρχείο λεγόταν απλά core και δεν περιείχε pids και γενικά τις πιο πολλές πληροφορίες που ενεργοποιεί ο systemd. My fault. Απλά επειδή το έγραψες στο νήμα του systemd, υπέθεσα ότι το χρησιμοποιείς.

[famous-walker]

Το systemd φερνει και αλλα... χρησιμα πραγματα.

Version 256 of systemd boasts '42% less Unix philosophy'

[jim_p]

Systemd 256.1 Fixes "systemd-tmpfiles" Unexpectedly Deleting Your /home Directory
https://www.phoronix.com/news/system...es-purge-drama

Οταν ελεγα οτι στο debian ρισκαρανε περνοντας την 256 οταν ηταν ακομα rc...

[imitheos]

Οταν ελεγα οτι στο debian ρισκαρανε περνοντας την 256 οταν ηταν ακομα rc...

Γιατί; Αν η rc είχε κάποιο bug που να έσβηνε τα αρχεία, τότε θα είχες δίκιο. Το γεγονός ότι η 256άρα έκδοση εισήγαγε κάτι που, αν εκτελεστεί χειροκίνητα, μπορεί να προκαλέσει προβλήματα δεν έχει καμμία σχέση με την rc.

Systemd 256.1 Fixes "systemd-tmpfiles" Unexpectedly Deleting Your /home Directory
https://www.phoronix.com/news/system...es-purge-drama

Λίγο υπερβολικό clickbait μου φαίνεται. Μια άτυχη στιγμή ήτανε. Ένας χρήστης ήθελε να σβήσει το /var/tmp και έψαξε να δει πώς να το κάνει. Κατά κακή τύχη, παρανόησε την λειτουργία της purge και έσβησε τα αρχεία. Απλά έτυχε να έχει την 256άρα που υλοποίησε την purge. Αν είχε παλαιότερη έκδοση θα το γλύτωνε.

Θα μπορούσε κάποιος να επιχειρηματολογήσει ότι ούτε --clean / --remove θα έπρεπε να τρέξει. Δεν νομίζω ότι η tmpfiles.d έχει σκοπό να τρέχει χειροκίνητα από τον κάθε χρήστη. Αν θέλεις το /var/tmp να σβηστεί με βάση το age του, άσε το να γίνει με βάση τον timer (που ξέρει να τρέξει --clean). Αν θέλεις να σβήσεις εκείνη τη στιγμή το /var/tmp γιατί γέμισε (ή για τον Χ, Ψ λόγο), τρέξε χειροκίνητα rm και κάνε το.

[jim_p]

Προλογος: Γενικα μου τη δινει να ακουω το fan του υπολογιστη μου, που οταν πατησει τους 40 ακουγεται καπως παραπανω. Και ειδικα για το καλοκαιρι που η κατασταση ειναι χειροτερη, εδω και ~10 χρονια βαζω τον επεξεργαστη μου σε governor powersave για να τρεχει στην ελαχιστη ταχυτητα οταν δεν κανω κατι σημαντικο. Μεχρι το 2021 ειχα για αυτη τη δουλεια το παρωχημενο cpufrequtils και ενιοτε το cpupower-gui (το οποιο ο debian maintainer το εχει παρατησει), αλλα απο το 2021 και μετα εχω παει στο linux-cpupower.

Το linux-cpupower του debian (cpupower σκετο απο δω και κατω) εχει ενα μεγαλο προβλημα. Οπως αναφερεται και στο bug report εδω, δεν εχει default configuration και systemd service, οποτε εινια μονο για να το τρεχει ο χρηστης χειροκινητα. Για αυτο το λογο λοιπον κατεβασα τα απαιτουμενα αρχεια που ποσταρε καποιος καλοθελητης στο bug report και τα "εγκατεστησα" με τις εντολες που λεει. Για να βλεπω αμεσα ποιον governor εχει, εχω βαλει το conky να μου δειχνει με την built in λειτουργια του.
https://bugs.debian.org/cgi-bin/bugr...cgi?bug=894906

Παρολα αυτα, μερικες φορες δεν τρεχει και θελω να βρω γιατι. Πχ το παρακατω output ειναι απο νωριτερα που ανοιξα το pc και ειδα το conky να λεει schedutil. Προφανως δεν ετρεξε το service σωστα στην εκκινηση, αλλα μονο στην εκκινηση, γιατι μετα που το ετρεξα με το χερι ετρεξε κανονικα. Οποτε πως μπορω να βρω τι φταιει?

$ sudo systemctl status cpupower.service 
× cpupower.service - Apply cpupower configuration
     Loaded: loaded (/usr/lib/systemd/system/cpupower.service; enabled; preset: enabled)
     Active: failed (Result: exit-code) since Sun 2024-07-07 13:12:35 EEST; 2min 6s ago
 Invocation: 5609e22dfa7548afa964bbcda554e0cb
    Process: 338 ExecStart=/usr/libexec/cpupower (code=exited, status=1/FAILURE)
   Main PID: 338 (code=exited, status=1/FAILURE)

Jul 07 13:12:35 mitsos systemd[1]: Starting cpupower.service - Apply cpupower configuration...
Jul 07 13:12:35 mitsos systemd[1]: cpupower.service: Main process exited, code=exited, status=1/FAILURE
Jul 07 13:12:35 mitsos systemd[1]: cpupower.service: Failed with result 'exit-code'.
Jul 07 13:12:35 mitsos systemd[1]: Failed to start cpupower.service - Apply cpupower configuration.

$ sudo systemctl list-units --failed 
  UNIT             LOAD   ACTIVE SUB    DESCRIPTION                 
● cpupower.service loaded failed failed Apply cpupower configuration

Legend: LOAD   → Reflects whether the unit definition was properly loaded.
        ACTIVE → The high-level unit activation state, i.e. generalization of SUB.
        SUB    → The low-level unit activation state, values depend on unit type.

1 loaded units listed.

$ sudo systemctl restart cpupower.service 
$ sudo systemctl status cpupower.service 
● cpupower.service - Apply cpupower configuration
     Loaded: loaded (/usr/lib/systemd/system/cpupower.service; enabled; preset: enabled)
     Active: active (exited) since Sun 2024-07-07 13:15:43 EEST; 3s ago
 Invocation: 8f8fcf79970a4ee1850fc8448fc97feb
    Process: 812 ExecStart=/usr/libexec/cpupower (code=exited, status=0/SUCCESS)
   Main PID: 812 (code=exited, status=0/SUCCESS)

Jul 07 13:15:43 mitsos systemd[1]: Starting cpupower.service - Apply cpupower configuration...
Jul 07 13:15:43 mitsos systemd[1]: Finished cpupower.service - Apply cpupower configuration.

[imitheos]

Αν τρέξεις journalctl -b -u cpupower.service δεν σου εμφανίζει το μήνυμα λάθους;

Ίσως υπάρχει κάποιο race για να μην τρέχει στην εκκίνηση αλλά να τρέχει μετά.

[jim_p]

Δεν ηξερα αυτες τις παραμετρους. Μολις το ξανακανει θα ξαναποσταρω.

[imitheos]

Δεν ηξερα αυτες τις παραμετρους. Μολις το ξανακανει θα ξαναποσταρω.

Και τώρα μπορείς να το τρέξεις και θα σου εμφανίσει όλο το log, εκτός αν έκανες reboot (οπότε πρέπει να φύγει η παράμετρος -b).

Ίσως όταν τρέχει το service, να μην έχει φορτωθεί η cpufreq υποδομή ακόμη και για αυτό να κολλάει. Υπάρχει νομίζω πρόνοια να πεις στο service file να τρέχει αφού φορτωθεί ένα συγκεκριμένο module αλλά δεν θυμάμαι πως. Το πιο εύκολο που μπορείς να δοκιμάσεις είναι να πεις χειροκίνητα να φορτώνει το module, πχ

echo "cpufreq_powersave" > /etc/modules-load.d/powersave.conf

Ίσως χρειαστεί πάλι να πειράξεις το αρχείο υπηρεσίας αλλά δεν νομίζω να ξεκινάει τόσο νωρίς το cpupower όσο το systemd-modules.

Στο bug report που έδωσες είχε ένα cpupower.service. Αυτό χρησιμοποιείς; Η αλλαγή που ανέφερα (αν και δεν θα πρέπει να χρειάζεται) είναι η παρακάτω.

[Unit]
Description=Apply cpupower configuration
After=systemd-modules-load.service
ConditionVirtualization=!container

[Service]
Type=oneshot
EnvironmentFile=-/etc/default/cpupower
ExecStart=/usr/libexec/cpupower
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target

Αυτό δηλαδή λέει στον systemd να εκκινήσει το cpupower αφού έχει τρέξει η υπηρεσία που φορτώνει τα χειροκίνητα-ορισμένα-modules (τα υπόλοιπα φορτώνονται μέσω udev), και με τον κώδικα που έδωσα πριν ορίζουμε να φορτώνεται χειροκίνητα ο scheduler που θέλεις.

Σημειωτέον ότι όλα αυτά χρειάζονται _μόνο_ αν είναι race condition και _μόνο_ αν είναι το συγκεκριμένο race condition που σκέφτηκα. Μπορεί να μην τρέχει για εντελώς άσχετο λόγο. Το error log θα σου πει γιατί δεν τρέχει.

[jim_p]

Λες δηλαδη να μην φορτωνεται το module αυτοματα μεσω του udev? Δεν το σκεφτηκα. Καποτε εκανα modprobe και μετα αλλαζα τον governor, αλλα μετα καταλαβα οτι αν τον αλλαξω, φορτωνει το module μονος του.
Η εντολη που λες βγαζει αυτο. Χωρις το -b, γιατι με αυτο βγαζει για το σημερινο boot και το σημερινο εγινε κανονικα.

-- Boot 14460e254b2d4e5db5495ab58f7bbc9b --
Jul 07 17:58:14 mitsos systemd[1]: Starting cpupower.service - Apply cpupower configuration...
Jul 07 17:58:14 mitsos systemd[1]: cpupower.service: Main process exited, code=exited, status=1/FAILURE
Jul 07 17:58:14 mitsos systemd[1]: cpupower.service: Failed with result 'exit-code'.
Jul 07 17:58:14 mitsos systemd[1]: Failed to start cpupower.service - Apply cpupower configuration.
Jul 07 18:00:19 mitsos systemd[1]: Starting cpupower.service - Apply cpupower configuration...
Jul 07 18:00:19 mitsos systemd[1]: Finished cpupower.service - Apply cpupower configuration.
Jul 07 21:45:01 mitsos systemd[1]: cpupower.service: Deactivated successfully.
Jul 07 21:45:01 mitsos systemd[1]: Stopped cpupower.service - Apply cpupower configuration.

[imitheos]

Λες δηλαδη να μην φορτωνεται το module αυτοματα μεσω του udev? Δεν το σκεφτηκα. Καποτε εκανα modprobe και μετα αλλαζα τον governor, αλλα μετα καταλαβα οτι αν τον αλλαξω, φορτωνει το module μονος του.

Δεν βλέπω να αναφέρει κάτι. Χωρίς logs δεν μπορώ να ξέρω τι γίνεται.

Όχι δεν είπα ότι δεν φορτώνεται αυτόματα αλλά να μην έχει φορτωθεί ακόμη όταν πάει να τρέξει το cpupower. Λογικά το systemd-udevd τρέχει νωρίς στην αρχή πολύ πριν το cpupower αλλά με την παραλληλία του systemd, πολλές φορές γίνονται races. Εναλλακτικά θα μπορούσες σε εκείνο το After που έδωσα να βάλεις να μπαίνει μετά το systemd-udevd οπότε δεν θα χρειαζόταν να βάλεις χειροκίνητα να φορτώνεται το module. Επίσης πιο αδόκιμα αλλά πιο εύκολα θα μπορούσες πριν το ExecStart, να προσθέσεις ένα "ExecStartPre=/sbin/modprobe -q cpufreq_powersave" ώστε να το φορτώνει.

[Unit]
Description=Apply cpupower configuration
ConditionVirtualization=!container

[Service]
Type=oneshot
EnvironmentFile=-/etc/default/cpupower
ExecStartPre=/sbin/modprobe -q cpufreq_powersave
ExecStart=/usr/libexec/cpupower
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target

Δοκίμασε δηλαδή να κάνεις το αρχείο υπηρεσίας έτσι. Αυτό είναι το πιο εύκολο. Δεν το σκέφτηκα χτες. Αν είναι αυτό που λέει θα φτιάξει. Αλλιώς είναι κάποια άλλη αιτία.

[jim_p]

Εκανα την αλλαγη που ειπες ωστε να φορτωνει αποκλειστικα το powersave module, και παρολο που χτες φαινεται να δουλεψε κανονικα, σημερα παλι ξεκινησε με schedutil. Που να ψαξω και τι logs να βρω?

[imitheos]

Εκανα την αλλαγη που ειπες ωστε να φορτωνει αποκλειστικα το powersave module, και παρολο που χτες φαινεται να δουλεψε κανονικα, σημερα παλι ξεκινησε με schedutil. Που να ψαξω και τι logs να βρω?

Όταν λες την αλλαγή, εννοείς αυτό το ExecStartPre με το modprobe που έδωσα; Αυτό φορτώνει χειροκίνητα το module, οπότε θα έπρεπε να παίζει, με την προϋπόθεση πάντα ότι το πρόβλημα ήταν race, όπως σκέφτηκα. Μάλλον θα φταίει κάτι άλλο.

Το /usr/libexec/cpupower που εκτελείται από το service είναι το shell script, έτσι; Αν θέλεις, δοκίμασε να αλλάξεις το shebang από /bin/sh σε /bin/sh -x ώστε, στην επόμενη εκκίνηση, να καταχωρήσει όλες τις εντολές που θα τρέξει για να δεις μήπως κάποια δεν τρέχει σωστά. Αν στην επόμενη εκκίνηση δεις ότι δεν έχει αλλάξει τον schedutil, μπορείς να δεις τα logs με το "journalctl -b -u cpupower.service" που είπαμε πριν. Μετά φυσικά αφαιρείς το -x πάλι ώστε να μην γράφει άσκοπα στα logs.

Εφόσον στο log υπάρχει μόνο ότι απέτυχε χωρίς το cpupower να εμφανίζει κανένα error, δεν ξέρω τι να προτείνω.

[jim_p]

Εκανα την αλλαγη που ειπες και περιμενω. Αν το τρεξω χειροκινητα με -x παιρνω αυτα

$ sudo bash -x /usr/libexec/cpupower 
[sudo] password for jim: 
+ ESTATUS=0
+ test '' '!=' ''
+ PARS=
+ PARS=
+ test '' '!=' ''
+ PARS=
+ test '' '!=' ''
+ exit 0

[imitheos]

Εκανα την αλλαγη που ειπες και περιμενω. Αν το τρεξω χειροκινητα με -x παιρνω αυτα

$ sudo bash -x /usr/libexec/cpupower 
[sudo] password for jim: 
+ ESTATUS=0
+ test '' '!=' ''
+ PARS=
+ PARS=
+ test '' '!=' ''
+ PARS=
+ test '' '!=' ''
+ exit 0

Το script έχει δικλείδες ώστε να μην τρέχει όταν δεν έχουν τιμή κάποιες μεταβλητές. Το service αρχείο, όπως βλέπεις παραπάνω, φορτώνει σαν "περιβάλλον" ένα αρχείο που περιέχει αυτές τις μεταβλητές. Μπορείς να το φορτώσεις και εσύ αλλά δεν θα κερδίσουμε κάτι αν το τρέξεις εσύ τώρα, εφόσον είπες ότι μόνο στην εκκίνηση δεν τρέχει.

[jim_p]

Οκ το εκανε και το journalctl βγαζει αυτα

$ sudo journalctl -b -u cpupower.service
Jul 14 06:12:05 mitsos systemd[1]: Starting cpupower.service - Apply cpupower configuration...
Jul 14 06:12:05 mitsos cpupower[343]: + ESTATUS=0
Jul 14 06:12:05 mitsos cpupower[343]: + test  !=
Jul 14 06:12:05 mitsos cpupower[343]: + PARS= -g powersave
Jul 14 06:12:05 mitsos cpupower[343]: + PARS= -g powersave
Jul 14 06:12:05 mitsos cpupower[343]: + test  -g powersave !=
Jul 14 06:12:05 mitsos cpupower[343]: + cpupower frequency-set -g powersave
Jul 14 06:12:05 mitsos cpupower[343]: + ESTATUS=1
Jul 14 06:12:05 mitsos cpupower[343]: + PARS=
Jul 14 06:12:05 mitsos cpupower[343]: + test  !=
Jul 14 06:12:05 mitsos cpupower[343]: + exit 1
Jul 14 06:12:05 mitsos systemd[1]: cpupower.service: Main process exited, code=exited, status=1/FAILURE
Jul 14 06:12:05 mitsos systemd[1]: cpupower.service: Failed with result 'exit-code'.
Jul 14 06:12:05 mitsos systemd[1]: Failed to start cpupower.service - Apply cpupower configuration.