- This topic has 391 replies, 17 voices, and was last updated Nov 4-12:22 pm by Brian Masinick.
-
Posts
-
Anonymous
Hello,
Another concern is that if I turn off all logging in runit and make a snapshot.
Then run the snapshot live and install to hard drive.
After install, I boot into runit of the installed system, then some runsv logging is present and burns up hard drive unnecessarily.
The only bullet proof way so far to overcome this, in my testing, is to make a backup of the /etc/sv folder
and immediately after install,
delete the /etc/sv folder in the installed system,
and copy the /etc/sv_backup to /etc/sv.
Only after this manual procedure do I get a runit without any logging same as right before I make the snapshot.
The snapshot and the live system DOES faithfully have the correct /etc/sv folder.
BUT, during installation, this /etc/sv folder is changed by the antiX installer in the INSTALLED system.
Therefore, does the antiX installer have to be modified specific for the multi init sytem?
ProwlerGr
Therefore, the does the antiX installer have to be modified specific for the multi init sytem?
The behavior is attributed to the antiX installer.
Can you perhaps send me a zip file containing the /etc/sv & /etc/sv_backup contents so I can take a look when I get the chance?Therefore, the does the antiX installer have to be modified specific for the multi init sytem?
The behavior is attributed to the antiX installer.
Can you perhaps send me a zip file containing the /etc/sv & /etc/sv_backup contents so I can take a look when I get the chance?Hello @ProwlerGr and all,
I am attaching a zip file for the /etc/sv_backup of my system that has no runsv logging in BOTH sysvinit and runit boots.
I am also attaching a screenshot of my multi init system that contains no logging based on that setup in /etc/sv_backup.
I am also attaching a screenshot of a separate system where there is a lot of logging.
In that picture, I was running live, so you will not see logging in the live system.
But if you install that live system, you will see lots of logging.
If you look at that the /etc/sv folder of that system, you will notice services that are bolded.
Those services tend to have lots of runsv logging.
Maybe that is a clue?
By the way, I like the new implementation of runit mainly because, prior to this new runit,
I would see lots of runsv logging in the SYSVINIT boot.
Now I only see runsv logging in RUNIT boot.
Edit: It was hard to make the .zip folder of the /etc/sv_backup.
So I make the .tar.gz folder.
But the forum would not let me upload this .tar.gz file.
But you can download this sv_backup.tar.gz file here:
@calciumsodium
Can you try the following before creating a snapshot?
sudo bash -c 'echo "/usr/share/runit/sv*">>/etc/iso-snapshot-exclude.list'See how it installs afterwards.
Can you try the following before creating a snapshot?
sudo bash -c 'echo "/usr/share/runit/sv*">>/etc/iso-snapshot-exclude.list'See how it installs afterwards.
Hello @ProwlerGr,
The iso-snapshot program was not happy with that change, and stopped early on with this error.
Edit: also, there was no /var/log/iso-snapshot.log file that was produced.
Brian Masinick
@ProwlerGr I just wanted to let you know that I took two other instances of “init-diversity”, used your original suggestion to
sudo mv /sbin/runit /sbin/runit-bak, then do the updates, then move them back. Not once, but TWICE this worked on two other systems. As for my original system, I had already fixed it using the @anticapitalista suggestion of copying the destroyed content in /etc/init.d from either a Flash Drive or another instance of antiX; so now I have at least three systems where I have an up-to-date “init-diversity” setup working. All is well here today.--
Brian Masinick
Alternate "Search B":
This search pageCan you try the following before creating a snapshot?
sudo bash -c 'echo "/usr/share/runit/sv*">>/etc/iso-snapshot-exclude.list'See how it installs afterwards.
Hello @ProwlerGr,
The iso-snapshot program was not happy with that change, and stopped early on with this error.
Edit: also, there was no /var/log/iso-snapshot.log file that was produced.
I also tried to explicitly write out the specific sv folders in the /usr/share/runit/ folder.
I still get the same error and the /var/log/iso-snapshot.log file was never created.
/usr/share/runit/sv/* /usr/share/runit/sv.now/* /usr/share/runit/sv.current/* /usr/share/runit/sv.src/*The iso-snapshot program is not happy with excluding these folders.
I also tried to explicitly write out the specific sv folders in the /usr/share/runit/ folder.
I still get the same error and the /var/log/iso-snapshot.log file was never created.
This is totally unexpected behaviour (I have tested this setting on a live system & it succesfully produced a test iso – however it still generated the extra service folders so no need for it).
On the other hand I have found the cause of the issue & I’ll post an update soon.
@calciumsodium, this will stop extra services appearing on runit.
I still want to do some tests before I decide if I want it on my spins (as is – or – with changes) – as logs are VERY important to me & every sysadmin – but I understand no-logs is important to you.Let me know how you go with this
@calciumsodium, this will stop extra services appearing on runit.
I still want to do some tests before I decide if I want it on my spins (as is – or – with changes) – as logs are VERY important to me & every sysadmin – but I understand no-logs is important to you.Let me know how you go with this
Hello @ProwlerGR,
Excellent results to report.
1. I applied this new change:
2. Without any manual manipulation of the newly installed partition, I rebooted into the sysvinit boot.
After some initial ext4lazyinit disk writes, logging went to ZERO.
Please see sysvinit screenshot.
You can see that after the ext4lazyinit did its work, logging went down to ZERO.
You will also see that this new change left my /etc/sv/ folder EXACTLY how I had it right before isosnapshot.
Therefore, the installation DID NOT change the /etc/sv/ folder.
For me, if there are any changes of the /etc/sv/ folder during installation, it would have been a deal breaker.
No more.
This new change is very welcome for me.
Thank you very much.
3. I then rebooted and entered the Runit boot.
As you can see, ZERO logging in runit. Please see screenshot #2.
This is REALLY GOOD NEWS for me.
Thank you.
Edit:
@ProwlerGr, can you please tell us how you were able to remove the logging in runit and how you were able to preserve the /etc/sv/ folder during installation, where that folder was changed prior to this new change?
Thanks.
Brian Masinick
Nice!
I’ll try it later too.--
Brian Masinick
Alternate "Search B":
This search page@ProwlerGr, can you please tell us how you were able to remove the logging in runit and how you were able to preserve the /etc/sv/ folder during installation, where that folder was changed prior to this new change?
I had to comment out all services under /etc/gazelle-installer-data/install.conf
This way you lose the ability to select which services you want enabled after installation, however the service state of the live iso gets replicated as-is.
@ProwlerGr, can you please tell us how you were able to remove the logging in runit and how you were able to preserve the /etc/sv/ folder during installation, where that folder was changed prior to this new change?
I had to comment out all services under /etc/gazelle-installer-data/install.conf
This way you lose the ability to select which services you want enabled after installation, however the service state of the live iso gets replicated as-is.
I think in one of my previous experiments, I unticked every service in the antiX installer, but I did not have good results.
But that is with the previous runit version.
Another evidence in support of your new runit version.
I am hoping that more users will try this latest update and see the positive results that I am seeing.
Brian Masinick
Good stuff! I added the “trick” to rename runit temporarily to my automatic script updating tool, and I added the no logging script, since I don’t need to debug anything here.
My “solution” to debugging is that I have a snapshot USB Flash Drive that does not include this, so IF I ever need debugging with logs I can bring them back. I also detected a couple of my own flaws in one of my snapshots. Some of the stuff I pulled over from another system failed to bring in all of the repo keys; I’ve been curious about why some of the repos were complaining about key while one of my stable builds does not; comparing them revealed this, so I’ve resolved the resolution of my hack, and now updates, including the runit rename, the correct keys to all repos, and the log removal all work really nicely. The proof is in the networking and the browser updates, both of which are correctly taking place. Also, got this today: Installing new version of config file /etc/iso-snapshot.conf …
So here’s my clean info report with an active, up-to-date version of the Librewolf Web Browser – the Librewolf browser, incidentally, comes courtesy of the “Privacy Edition” from @calciumsodium, which I use as the base for building my own “init-diversity” setup, so thanks to both @calciumsodium and @ProwlerGr for the work on these efforts. Of COURSE I’m ALWAYS thankful for the antiX development team for providing this fantastic distribution, and also to the Debian team and the core Linux developers and GNU application developers, who make ALL of this possible!
ps ax | head -2; sudo ps_mem.py; wp PID TTY STAT TIME COMMAND 1 ? Ss 0:00 /usr/bin/s6-svscan -X3 -- /run/service Private + Shared = RAM used Program 120.0 KiB + 10.5 KiB = 130.5 KiB s6-linux-init-shutdownd 148.0 KiB + 16.5 KiB = 164.5 KiB ucspilogd 156.0 KiB + 19.5 KiB = 175.5 KiB foreground 152.0 KiB + 23.5 KiB = 175.5 KiB seatd 188.0 KiB + 17.5 KiB = 205.5 KiB s6-svscan 232.0 KiB + 51.0 KiB = 283.0 KiB s6-ipcserverd (2) 364.0 KiB + 20.5 KiB = 384.5 KiB s6-fdholderd 372.0 KiB + 103.5 KiB = 475.5 KiB icewm-session 384.0 KiB + 94.5 KiB = 478.5 KiB dbus-launch 368.0 KiB + 147.5 KiB = 515.5 KiB udevil 664.0 KiB + 314.5 KiB = 978.5 KiB dconf-service 632.0 KiB + 382.5 KiB = 1.0 MiB devmon 820.0 KiB + 397.5 KiB = 1.2 MiB desktop-session 1.1 MiB + 186.5 KiB = 1.3 MiB s6-log (9) 956.0 KiB + 424.5 KiB = 1.3 MiB at-spi2-registryd 964.0 KiB + 418.5 KiB = 1.4 MiB agetty (7) 856.0 KiB + 530.5 KiB = 1.4 MiB at-spi-bus-launcher 908.0 KiB + 694.0 KiB = 1.6 MiB sudo (2) 1.1 MiB + 469.5 KiB = 1.6 MiB dbus-daemon (3) 1.9 MiB + 26.5 KiB = 2.0 MiB dhclient 2.0 MiB + 447.5 KiB = 2.4 MiB bash 2.2 MiB + 471.5 KiB = 2.6 MiB conky 2.1 MiB + 704.5 KiB = 2.7 MiB pipewire-pulse 3.0 MiB + 562.5 KiB = 3.5 MiB udevd 3.8 MiB + 153.5 KiB = 4.0 MiB connmand 4.1 MiB + 654.0 KiB = 4.8 MiB s6-supervise (34) 3.9 MiB + 1.2 MiB = 5.1 MiB pipewire 4.4 MiB + 900.5 KiB = 5.2 MiB slimski 5.8 MiB + 1.4 MiB = 7.2 MiB icewm 7.2 MiB + 532.5 KiB = 7.8 MiB wpa_supplicant 7.1 MiB + 1.5 MiB = 8.6 MiB wireplumber 11.4 MiB + 4.2 MiB = 15.6 MiB roxterm 13.0 MiB + 4.2 MiB = 17.2 MiB rox 50.5 MiB + 30.5 MiB = 81.0 MiB Xorg 844.4 MiB + 168.9 MiB = 1.0 GiB librewolf (12) --------------------------------- 1.2 GiB ================================= 07:33:29 AM System: Kernel: 6.14.10-1-liquorix-amd64 arch: x86_64 bits: 64 compiler: gcc v: 12.2.0 Desktop: IceWM v: 3.7.5 dm: slimski Distro: antiX-23.2_x64 May 14 2025 base: Debian GNU/Linux 12 (bookworm) Machine: Type: Laptop System: LENOVO product: 21CF003TUS v: ThinkPad T14 Gen 3 serial: <superuser required> Chassis: type: 10 serial: <superuser required> Mobo: LENOVO model: 21CF003TUS v: SDK0T76530 WIN serial: <superuser required> part-nu: LENOVO_MT_21CF_BU_Think_FM_ThinkPad T14 Gen 3 UEFI: LENOVO v: R23ET82W (1.58 ) date: 03/04/2025 Battery: ID-1: BAT0 charge: 54.6 Wh (100.0%) condition: 54.6/52.5 Wh (104.0%) volts: 16.9 min: 15.4 model: Celxpert LNV-5B10W51866�� serial: <filter> status: full CPU: Info: 8-core model: AMD Ryzen 7 PRO 6850U with Radeon Graphics bits: 64 type: MT MCP arch: Zen 3+ rev: 1 cache: L1: 512 KiB L2: 4 MiB L3: 16 MiB Speed (MHz): avg: 1396 min/max: 1600/2700 boost: enabled cores: 1: 1396 2: 1396 3: 1396 4: 1396 5: 1396 6: 1396 7: 1396 8: 1396 9: 1396 10: 1396 11: 1396 12: 1396 13: 1396 14: 1396 15: 1396 16: 1396 bogomips: 86237 Flags: avx avx2 ht lm nx pae sse sse2 sse3 sse4_1 sse4_2 sse4a ssse3 svm Graphics: Device-1: Advanced Micro Devices [AMD/ATI] Rembrandt [Radeon 680M] vendor: Lenovo driver: amdgpu v: kernel arch: RDNA-2 pcie: speed: 16 GT/s lanes: 16 ports: active: eDP-1 empty: DP-1, DP-2, DP-3, DP-4, DP-5, DP-6, HDMI-A-1, Writeback-1 bus-ID: 04:00.0 chip-ID: 1002:1681 temp: 47.0 C Device-2: Chicony Integrated Camera driver: uvcvideo type: USB rev: 2.0 speed: 480 Mb/s lanes: 1 bus-ID: 5-1:2 chip-ID: 04f2:b74f Display: server: X.Org v: 1.21.1.7 driver: X: loaded: amdgpu unloaded: fbdev,modesetting,vesa dri: radeonsi gpu: amdgpu resolution: 1920x1200~60Hz API: OpenGL v: 4.6 vendor: amd mesa v: 22.3.6 glx-v: 1.4 es-v: 3.2 direct-render: yes renderer: AMD Radeon Graphics (rembrandt LLVM 15.0.6 DRM 3.61 6.14.10-1-liquorix-amd64) device-ID: 1002:1681 Info: Tools: api: eglinfo,glxinfo x11: xdriinfo, xdpyinfo, xprop, xrandr Network: Device-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet vendor: Lenovo driver: r8169 v: kernel pcie: speed: 2.5 GT/s lanes: 1 port: 2000 bus-ID: 01:00.0 chip-ID: 10ec:8168 IF: eth0 state: down mac: <filter> Device-2: Qualcomm QCNFA765 Wireless Network Adapter vendor: Lenovo Atheros driver: ath11k_pci v: kernel pcie: speed: 5 GT/s lanes: 1 bus-ID: 02:00.0 chip-ID: 17cb:1103 IF: wlan0 state: up mac: <filter> Drives: Local Storage: total: 476.94 GiB used: 11.81 GiB (2.5%) ID-1: /dev/nvme0n1 vendor: Micron model: MTFDKBA512TFK size: 476.94 GiB speed: 63.2 Gb/s lanes: 4 serial: <filter> temp: 28.9 C Partition: ID-1: / size: 93.31 GiB used: 11.81 GiB (12.7%) fs: ext4 dev: /dev/nvme0n1p4 Unmounted: ID-1: /dev/nvme0n1p1 size: 100 MiB fs: vfat ID-2: /dev/nvme0n1p2 size: 95.37 GiB fs: ext4 ID-3: /dev/nvme0n1p3 size: 95.37 GiB fs: ext4 ID-4: /dev/nvme0n1p5 size: 95.37 GiB fs: ext4 ID-5: /dev/nvme0n1p6 size: 95.37 GiB fs: ext4 Info: Memory: total: N/A available: 14.4 GiB used: 1.55 GiB (10.8%) Processes: 339 Power: uptime: 29m wakeups: 0 Init: s6 v: N/A default: 2 Packages: pm: dpkg pkgs: 2070 Compilers: gcc: 12.2.0 Shell: Bash v: 5.2.15 running-in: roxterm pinxi: 3.3.38-3--
Brian Masinick
Alternate "Search B":
This search pageBrian Masinick
I am also going BACK to my snapshot to fix the repos that are defective, then remaster it rather than doing an ISO Snapshot of my current system; that way I have a simple base with logging, etc. should I have a need to rebuild.
Good stuff!
--
Brian Masinick
Alternate "Search B":
This search page
- You must be logged in to reply to this topic.