Boycott systemd

[Gentoo]

systemctl --user stop dunst
systemctl --user start dunst

Απενεργοποίηση/ενεργοποίηση ζήτησε. Οπότε disable/enable.

@jim αν δεν θέλεις να εκκινεί κατά το boot. Αλλιώς και το stop/start σε καλύπτει.

[MitsakosGR]

Απενεργοποίηση/ενεργοποίηση ζήτησε. Οπότε disable/enable.

@jim αν δεν θέλεις να εκκινεί κατά το boot. Αλλιώς και το stop/start σε καλύπτει.

Το είδα ότι ζήτησε ενεργοποίηση απενεργοποιηση, αλλά το comment στο reddit που έβαλε γράφει για enable/disable αλλά ότι δεν σταμάτησε το service. Για αυτό έβαλα το start/stop.

Αν θέλεις να το σταματήσεις και αμέσως, εκτός του να το απενεργοποιησεις από το boot, θέλει και disable και stop.

[Gentoo]

Το είδα ότι ζήτησε ενεργοποίηση απενεργοποιηση, αλλά το comment στο reddit που έβαλε γράφει για enable/disable αλλά ότι δεν σταμάτησε το service. Για αυτό έβαλα το start/stop.

Αν θέλεις να το σταματήσεις και αμέσως, εκτός του να το απενεργοποιησεις από το boot, θέλει και disable και stop.

Α οκ. Δεν πρόσεξα τη συζήτηση στο reddit.

[jim_p]

Να τα παρω ενα ενα...
Το service που θελω να κλεισω τρεχει για το χρηστη μονο και θελω να το κλεισω για να το τρεξω μετα απο το autostart, οπως προτεινε ο dev του. Αλλα αυτο απαιτει επανεκκινηση, οποτε το start/stop δεν εχει νοημα, μιας και στην επομενη εκκινηση θα τρεξει ξανα. Γιαυτο θελω να το κανω disable σαν χρηστης, μιας και σαν system service δεν τρεχει σιγουρα, και μετα enable αν χρειαστει.
Σκεφτηκα λοιπον τον προφανη τροπο που λεει ο Gentoo και μετα διαβασα αυτο στο reddit με τις διαγραφες και πελαγωσα!

- - - Updated - - -

Εκανα λοιπον μια δοκιμη με systemctl disable dunst --user και πηγε κουβα, μιας και ακομα ξεκιναει κανονικα σε καθε εκκινηση.

[imitheos]

Εκανα λοιπον μια δοκιμη με systemctl disable dunst --user και πηγε κουβα, μιας και ακομα ξεκιναει κανονικα σε καθε εκκινηση.

Πώς βλέπεις ότι ξεκινάει; Τρέχεις systemctl --user status dunst.service και σου εμφανίζει ότι έχει ξεκινήσει; Γιατί αν βλέπεις απλά ότι τρέχει το dunst μέσω ps, τότε μπορεί να ξεκινάει μέσω xdg autostart, μέσω bash profile και άλλους 15 τρόπους.

[jim_p]

Ναι, τρεχω αυτο που λες και το λεει ενεργο. Ενας dev λεει οτι μπορει να το ξεκινησε το dbus.

[MitsakosGR]

Αν το κάνεις mask;

systemctl --user mask dunst

[jim_p]

$ sudo systemctl mask dunst
Unit dunst.service does not exist, proceeding anyway.
Created symlink /etc/systemd/system/dunst.service → /dev/null.

$ sudo systemctl unmask dunst
Removed "/etc/systemd/system/dunst.service".

$ sudo systemctl mask dunst --user
Failed to connect to bus: No medium found

$ systemctl --user mask dunst
Created symlink /home/jim/.config/systemd/user/dunst.service → /dev/null.

Το τελευταιο δουλεψε μονο και δεν ξεκινησε.

[imitheos]

Aντί ρε συ τζίμη να παίζεις κάθε φορά το σύστημα πλημμύρα (βάρα εντολές μέχρι να παίξει), γιατί δε κάνεις ένα κόπο 4 δευτερολέπτων να σκεφτείς την σύνταξη;

$ sudo systemctl mask dunst
Unit dunst.service does not exist, proceeding anyway.
Created symlink /etc/systemd/system/dunst.service → /dev/null.
$ sudo systemctl unmask dunst
Removed "/etc/systemd/system/dunst.service".

Ήδη 3 - 4 φορές σου έχει προταθεί το "--user" οπότε ξέρεις τι διαφορά μεταξύ --user και μη. Χωρίς αυτό, δουλεύεις με system services (όπως φαίνεται και από την ανάγκη χρήσης sudo). Τα παραπάνω λοιπόν μασκάρουν την υπηρεσία συστήματος dunst (αν αυτή υπήρχε).

$ sudo systemctl mask dunst --user
Failed to connect to bus: No medium found

Εδώ έβαλες το user, οπότε πειράζεις υπηρεσίες χρήστη, αλλά έβαλες και το sudo. Χωρίς να είμαι 100% σίγουρος, επειδή, λόγω του sudo, τρέχεις σαν root την εντολή, προσπαθεί να συνδεθεί στο bus του root. Επειδή όμως ο χρήστης δεν έκανε login οπότε δεν έτρεξε το pam plugin (pam_systemd ή όποιο είναι) που ανοίγει ένα śession και δημιουργεί το bus, δεν υπάρχει bus για τον root και για αυτό παίρνεις ότι δεν μπορεί να βρει bus.

$ systemctl --user mask dunst
Created symlink /home/jim/.config/systemd/user/dunst.service → /dev/null.

Εδώ έβαλες το user, δεν έχεις sudo, οπότε δουλεύεις με τον jim_p για αυτό και επιτυγχάνει.

[jim_p]

Δεν εβαλα το --user γιατι ηθελα να μην γινει mask εντελως. Anyway, βρηκαμε τι εφταιγε στο προβλημα του dunst, παμε παρακατω. Ευχαριστω

[MitsakosGR]

Δεν εβαλα το --user γιατι ηθελα να μην γινει mask εντελως. Anyway, βρηκαμε τι εφταιγε στο προβλημα του dunst, παμε παρακατω. Ευχαριστω

Τι εννοείς ακριβώς; Πώς τρέχοντας mask δεν θα γίνει "εντελώς mask"; Και τι σημαίνει ότι κάτι δεν είναι "εντελώς mask";

[jim_p]

Εννοω να μην γινει mask σαν service του λειτουργικου.

[jim_p]

Απο τοτε που πηρα την ενημερωση σε kodi 21, εχω το kodi να σκαει οταν το κλεινω και να κανει ενα crash log. Και μετα την προσφατη ενημερωση σε systemd 256rc3 παρατηρησα οτι κανει και ενα αρχειο core στον ιδιο φακελο με το crash log (στο home μου βασικα).

$ file core 
core: ELF 64-bit LSB core file, x86-64, version 1 (SYSV), too many program headers (2183)
$ du -h core 
188M	core

Η ενημερωση μου προτεινε να αντικαταστησει το journald.conf με καινουριο, αλλα κρατησα το παλιο μου. Τα αρχεια διαφερουν σε αυτες τις γραμμες (output απο το icdiff).

MaxRetentionSec=1day                    #MaxRetentionSec=                      
MaxFileSec=1day                         #MaxFileSec=1month                     
                                        #MaxLevelSocket=debug

Η παραμετρος MaxLevelSocket=debug που λειπει απο το δικο μου (αριστερα) ειναι που δημιουργει το παραπανω αρχειο?

- - - Updated - - -

Τωρα που το ειδα, πρεπει να κανω και undo στο service του dunst που λεγαμε παραπανω. Μπηκε νεα ενημερωση και το ξανατρεχει σαν user, αλλα το τρεχω ηδη μεσω autostart, οποτε καπου σκαει.

$ systemctl --user status dunst
× dunst.service - Dunst notification daemon
     Loaded: loaded (/usr/lib/systemd/user/dunst.service; enabled; preset: enabled)
     Active: failed (Result: core-dump) since Sat 2024-06-01 06:35:51 EEST; 32min ago
 Invocation: 314831314d724e16aad3e9342ca49dfe
       Docs: man:dunst(1)
    Process: 704 ExecStart=/usr/bin/dunst (code=dumped, signal=TRAP)
   Main PID: 704 (code=dumped, signal=TRAP)

Jun 01 06:35:51 mitsos systemd[687]: Starting dunst.service - Dunst notification daemon...
Jun 01 06:35:51 mitsos dunst[704]: WARNING: Cannot open X11 display.
Jun 01 06:35:51 mitsos dunst[704]: ERROR: [  get_x11_output:0070] Couldn't initialize X11 output. Aborting...
Jun 01 06:35:51 mitsos systemd[687]: dunst.service: Main process exited, code=dumped, status=5/TRAP
Jun 01 06:35:51 mitsos systemd[687]: dunst.service: Failed with result 'core-dump'.
Jun 01 06:35:51 mitsos systemd[687]: Failed to start dunst.service - Dunst notification daemon.

[imitheos]

Απο τοτε που πηρα την ενημερωση σε kodi 21, εχω το kodi να σκαει οταν το κλεινω και να κανει ενα crash log. Και μετα την προσφατη ενημερωση σε systemd 256rc3 παρατηρησα οτι κανει και ενα αρχειο core στον ιδιο φακελο με το crash log (στο home μου βασικα).

$ file core 
core: ELF 64-bit LSB core file, x86-64, version 1 (SYSV), too many program headers (2183)
$ du -h core 
188M	core

Η ενημερωση μου προτεινε να αντικαταστησει το journald.conf με καινουριο, αλλα κρατησα το παλιο μου. Τα αρχεια διαφερουν σε αυτες τις γραμμες (output απο το icdiff).

Το journald δεν έχει σχέση με αυτό. Αυτό που θέλεις είναι το coredumpd.
1)

echo "kernel.core_pattern=|/bin/false" > /etc/sysctl.d/90-nocore.conf

Αν διαβάσεις το /path/to/kernel-source/Documentation/admin-guide/kernel.rst θα δεις ότι βάζοντας το | πετάει το core στην είσοδο της εντολής που του λες, οπότε με το παραπάνω ουσιαστικά απενεργοποιεί την αποθήκευση των αρχείων. Αυτό θα δουλέψει σε όλες τις διανομές με ή χωρίς systemd.

2)

cat > /etc/systemd/coredump.conf.d/nostorage.conf << EOF
[Coredump]
Storage=none
EOF

Αυτό δουλεύει μόνο με systemd-coredump και αυτό που κάνει είναι να απενεργοποιεί την storage. Δεν έχω εγκατεστημένο coredump οπότε ίσως να μην είναι ακριβώς έτσι. Είδα τι βάζουμε στον journald και το άλλαξα καταλλήλως. Επίσης ίσως να δημιουργεί τα αρχεία αλλά να τα στέλνει στο /run. Βαρέθηκα να κατεβάσω τον coredumpd .

3)

apt purge systemd-coredump

Αυτό θα αφαιρέσει εντελώς τον coredumpd οπότε δεν θα σώζει και τα αρχεία (ίσως όχι ανάλογα με το πώς είναι χτισμένος ο πυρήνας).

Διάλεξε και πάρε.

[jim_p]

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

$ apt-cache policy systemd-coredump 
systemd-coredump:
  Installed: (none)
  Candidate: 256~rc3-2
  Version table:
     256~rc3-6 500
        500 https://deb.debian.org/debian unstable/main amd64 Packages
     256~rc3-2 990
        990 https://deb.debian.org/debian testing/main amd64 Packages

Αν εχεις και καμια ιδεα για το δευτερο που λεω για το dunst, πες. Αυτη τη στιγμη, μετα απο φρεσκο boot και αφου εσβησα το entry του απο το autostart, το service παραπανω ξεκιναει κανονικα και λογικα αυτουνου πρεπει να εινια ενα core των 28mb που εχω στο home μου επειδη

$ dmesg | grep dunst
[   13.570268] traps: dunst[604] trap int3 ip:7febbb5a2829 sp:7ffe775e9790 error:0 in libglib-2.0.so.0.8000.2[7febbb55c000+9d000]

Αυτο ειναι γνωστο bug και το εχω αναφερει στο github τους, οποτε μια μερα θα φτιαχτει.