antiX-bullseye-a2-runit_x64-full.iso available

Forum Forums antiX-development Development antiX-bullseye-a2-runit_x64-full.iso available

  • This topic has 152 replies, 16 voices, and was last updated Jul 8-5:18 pm by Ampersand.
Viewing 15 posts - 91 through 105 (of 153 total)
  • Author
    Posts
  • #57943
    Moderator
    Brian Masinick
    Helpful
    Up
    0

    The search string “check runit logs” shows several other links.

    Brian Masinick

    #57949
    Member
    Xecure
    Helpful
    Up
    0

    Following anticapitalista’s advice, I reduced the amount of running services, and when I check the runit tree in htop I can see the error I reported above, which is what manages runsvdir.

    I will see if I can build the xsv program skidoo mentioned to see if there is a way to disable logging (or play with different options) and see if the disk writing issue is fixed with it.

    Attachments:
    #57955
    Member
    Xecure
    Helpful
    Up
    0

    Thanks to reading the man for sv, I figured out how to stop logging for services (doesn’t always work).
    sudo sv stop service-name/log
    Example:
    sudo sv stop connman/log

    You have to do this for every service that is logging (seen with sudo iotop), including services that are down. Problematic services: anacron (I have only found that exiting the service is the only thing that works).
    Sometimes, for services that are down, I need to again stop them completely (so I have to sv stop service-name and also sv stop service-name/log).

    Once I do this for each service I see in iotop, I finally get my disk to rest.

    Problem: everything starts again on restart.

    I think I compiled xsv correctly changing the default paths, but it gives no option to manage logs, as already reported by skidoo.

    Is the only solution to remove /etc/sv/service-name/log to permanently disable logging from all active and inactive services (and keep that configuration for reboots)?

    #57957
    Forum Admin
    anticapitalista
    Helpful
    Up
    0

    Is the only solution to remove /etc/sv/service-name/log to permanently disable logging from all active and inactive services (and keep that configuration for reboots)?

    From my understanding yes.

    Philosophers have interpreted the world in many ways; the point is to change it.

    antiX with runit - leaner and meaner.

    #57959
    Moderator
    ModdIt
    Helpful
    Up
    0

    I gave up a few days ago,just went to /etc/service/servicename and renamed the logging folders log.blocked.

    System seems to run ok, hopefully not
    famous last words. Seems deleting will not kill system. Will try and find time to run an installed to HDD
    setup tomorrow.

    #57960
    Member
    Xecure
    Helpful
    Up
    0

    After a lot of testing and a lot of research, now I have most of it figured out.

    I now know I no longer need to remove symlinks from /etc/service/ to disable a runit service. Simply creating a file named “down” inside the service folder will disable it from starting.
    sudo touch /etc/service/service-name/down

    I can do the exact same thing to disable most service logs. Create an empty file named “down” inside the log folder of the service.
    sudo touch /etc/service/service-name/log/down

    There are still services that ignore the log/down file, and even deleting the log folder doesn’t help at all. I need to disable those services completely and it will then no longer write to the disk.

    I currently have all 32 services symlinked in /etc/service/ and now the runit system doesn’t write continuously on idle. Now I need to figure ut a different error I can see in the htop tree for runsvdir. But this is a different issue.

    I may even create a bash based gui script to manage services and logs on the weekend. At least something I can understand, as xsv is too low level for me.

    #58024
    Member
    Koo
    Helpful
    Up
    0

    Just checking repo address for antiX-bullseye-a2-runit_x64-full Grup Yorum 26 March 2021.

    https://mirrors.evowise.com/mxlinux-packages/antix/ bullseye or this not working https://mirrors.evowise.com/mxlinux-packages/antix// bullseye

    T430 i7-3632QM 16gb , antiX-19.2.1-runit_x64-base Hannie Schaft 29 March 2020 , 5.8.16-antix.1-amd64-smp

    #58027
    Member
    Xecure
    Helpful
    Up
    0

    @Koo, the correct repo address follows this syntax:
    deb http://antix-repo.mirror/antix/debianrelease debianrelease main non-systemd non-free

    Pay attention to how debianrelease appears twice (and in your post only appears once).
    For your exact particular case example, it would look like:
    deb https://mirrors.evowise.com/mxlinux-packages/antix/bullseye bullseye main non-systemd non-free
    bullseye appears twice.

    This was fixed in a2, as anticapitalista created the bullseye repo, replacing the testing repo.

    #58086
    Member
    Xecure
    Helpful
    Up
    0

    Bug: antix runit doesn’t remember the screen backlight set by backlight-brightness on the next reboot. Can anyone else reproduce?

    #58203
    Member
    Xecure
    Helpful
    Up
    0

    The reason why logs don’t work as expected is related to how the log “runs”. It requires the existence of a user named “_runit-log”, but this user doesn’t exists in /etc/passwd

    If the log script changes to NOT use the _runit-log user, the logs work as expected.

    Was there a part of the runit installer that should create this new _runit-log user? Is this user needed?

    SO, the solution is editing all log/run files to NOT launch (or chown the log directory) OR creating a new _runit-log user (which should be able to run svlogd.

    Which is best?

    #58207
    Member
    calciumsodium
    Helpful
    Up
    0

    Hi @Xecure,
    I can reproduce the screen backlight bug. If I use backlight-brightness from terminal, it does not remember the setting at the next reboot. However, if I use the screenlight program from Menu and use the Change and Apply the Day or Night Values, it remembers at the next reboot.

    #58208
    Moderator
    Brian Masinick
    Helpful
    Up
    0

    Hi @Xecure,
    I can reproduce the screen backlight bug. If I use backlight-brightness from terminal, it does not remember the setting at the next reboot. However, if I use the screenlight program from Menu and use the Change and Apply the Day or Night Values, it remembers at the next reboot.

    That sounds like a device permission issue. Either use the menu or add your username to a group that has access to the screenlight program.

    Brian Masinick

    #58209
    Moderator
    Brian Masinick
    Helpful
    Up
    0

    The reason why logs don’t work as expected is related to how the log “runs”. It requires the existence of a user named “_runit-log”, but this user doesn’t exists in /etc/passwd

    If the log script changes to NOT use the _runit-log user, the logs work as expected.

    Was there a part of the runit installer that should create this new _runit-log user? Is this user needed?

    SO, the solution is editing all log/run files to NOT launch (or chown the log directory) OR creating a new _runit-log user (which should be able to run svlogd.

    Which is best?

    How about adding the log/run files to a group with sufficient access or add a group that has the necessary access?

    This could also solve the problem; depends on which mechanism is preferred for configuration and setup. Adding a runit-log username is fine too. I personally have no preference.

    If the code is inherited though it’s easier to simply add the user instead of having to modify code from an outside source every time an update occurs; this invites repeated maintenance and code regression potential.

    • This reply was modified 2 months, 4 weeks ago by Brian Masinick.

    Brian Masinick

    #58217
    Member
    Xecure
    Helpful
    Up
    0

    If the code is inherited though it’s easier to simply add the user instead of having to modify code from an outside source every time an update occurs; this invites repeated maintenance and code regression potential.

    I completely agree. Once a decision is made to fix the future antix-runit releases, I will follow it. For now I am informing on the reason of the problem.

    An example of what I am talking about. This is /etc/sv/connman/log/run current content:

    #!/bin/sh
    set -e
    
    NAME=connman
    LOG="/var/log/runit/$NAME"
    
    test -d "$LOG" || mkdir "$LOG" && chown -R _runit-log:adm "$LOG"
    exec chpst -u _runit-log svlogd -tt "$LOG"

    If no new users are created for future versions, the change without a specific user launching the svlogd program would look like this:

    #!/bin/sh
    set -e
    
    NAME=connman
    LOG="/var/log/runit/$NAME"
    
    test -d "$LOG" || mkdir "$LOG"
    exec chpst svlogd -tt "$LOG"

    Though this is not needed for all services. Some of them, like elogind, has this log/run instructions:

    #!/bin/sh
    
    exec logger -p daemon.notice -t runsv-elogind

    It is best we can get some input from the developers, so that the small gui-script I am building can follow the same decision.

    #58220
    Moderator
    Brian Masinick
    Helpful
    Up
    0

    I like your approach for either solution.

    Hopefully we will simply add the user account; then it’s easy.

    • This reply was modified 2 months, 4 weeks ago by Brian Masinick.

    Brian Masinick

Viewing 15 posts - 91 through 105 (of 153 total)
  • You must be logged in to reply to this topic.