Init systems => dinit => Topic started by: konimex on 08 November 2021, 15:58:14
Title: [Tracker] Dinit support
Post by: konimex on 08 November 2021, 15:58:14
dinit pretty much is "stable enough" right now, but as always, create backups of your important data.
Installation and usage See https://wiki.artixlinux.org/Main/Dinit
Why dinit instead of other inits? See https://github.com/davmac314/dinit/blob/master/doc/COMPARISON
Known Issues TBA
Needs more testing TBA
Title: Re: [Tracker] Dinit support
Post by: phoenix_king_rus on 08 November 2021, 16:59:40
Is there a way to enable service via adding/editing some file? Dinit socket does not exist in chroot, also it will be hard to add proper serial tty script running on different arch
Title: Re: [Tracker] Dinit support
Post by: ndowens on 08 November 2021, 17:01:12
Dinit works with ZFS, though I've added a script locally for "zfs mount -a" to make sure all my datasets are mounted
Title: Re: [Tracker] Dinit support
Post by: calvinh on 08 November 2021, 23:24:37
Have been running dinit testing ISO with dwm for a couple of hours now. Everything works just fine. Thanks @konimex for the excellent work.
Have a few questions,
1. Seems that dinit doesn't support run levels and cgroups. At least in current implementation in Artix.
2. How can we measure the time & order that dinit uses to bring the services up? Noticed some messages printed on tty1. Maybe we can also log them in a dedicated log?
Title: Re: [Tracker] Dinit support
Post by: konimex on 09 November 2021, 01:20:38
Is there a way to enable service via adding/editing some file? Dinit socket does not exist in chroot, also it will be hard to add proper serial tty script running on different arch
You can do it like this: ln -s ../service_name /etc/dinit.d/boot.d/
Have been running dinit testing ISO with dwm for a couple of hours now. Everything works just fine. Thanks @konimex for the excellent work.
Have a few questions,
1. Seems that dinit doesn't support run levels and cgroups. At least in current implementation in Artix.
2. How can we measure the time & order that dinit uses to bring the services up? Noticed some messages printed on tty1. Maybe we can also log them in a dedicated log?
Support on CGroups are crude, like it is on runit (i.e. just mounting the cgroups filesystem). Full support for cgroups are currently on dinit's plans post 1.0 (See https://github.com/davmac314/dinit/blob/master/TODO)
The time? For now, I can't really say since I don't test that part myself. The order? We can look at the depends-on and waits-for in the services. As for the logging, we only log the services for now (see /var/log/dinit). But perhaps we can use bootlogd for overall boot process. As for the some messages printing, the tty service started messages should be the last one (i.e. if wpa_supplicant or mysql runs, it won't spam the screen).
Title: Re: [Tracker] Dinit support
Post by: phoenix_king_rus on 09 November 2021, 07:46:27
The order? We can look at the depends-on and waits-for in the services.
But this appeared to be a new one. When i tried to add new tty service to boot.d (i copied tty2 and replaced all its tty references to ttyAMA0 to test in qemu) i got cycling dependency error on boot. So, where is "entrypoint" (if any) for dinit from which it builds service tree? Or maybe /etc/dinit.d/boot can be backuped so that user can modify it and doesn't lose changes after update?
Title: Re: [Tracker] Dinit support
Post by: konimex on 09 November 2021, 12:25:06
But this appeared to be a new one. When i tried to add new tty service to boot.d (i copied tty2 and replaced all its tty references to ttyAMA0 to test in qemu) i got cycling dependency error on boot. So, where is "entrypoint" (if any) for dinit from which it builds service tree? Or maybe /etc/dinit.d/boot can be backuped so that user can modify it and doesn't lose changes after update?
The entry point is, of course boot. boot waits for loginready which in turn waits for boot.d (I made it this way originally to reduce the printing messages on tty1, but it only partially works).
It's a cyclic dependency because ttyAMA0 depends on loginready, which in turn waits for.. boot.d, which contains ttyAMA0. Anyway, I can either do what you suggested, or create a dedicated internal getty folder (/etc/dinit.d/getty.d), so that boot depends on getty, and people can add whatever tty they want in /etc/dinit.d/getty.d/. Let me know what you think.
Title: Re: [Tracker] Dinit support
Post by: phoenix_king_rus on 09 November 2021, 13:16:02
create a dedicated internal getty folder (/etc/dinit.d/getty.d), so that boot depends on getty, and people can add whatever tty they want in /etc/dinit.d/getty.d/. Let me know what you think.
This one sounds even better
UPD: ARMtix dinit rootfs is uploaded now
Title: Re: [Tracker] Dinit support
Post by: just on 09 November 2021, 16:04:04
Subject: runit and dinit conflict during Arix-runit installation from base ISO
1. Problem: Some conflicts arise between runit and dinit packages during Artix-runit installation from base ISO.
2. Description: Trying to install Artix-runit from the base ISO:
Doing installation by strictly following Artix Wiki Installation (https://wiki.artixlinux.org/Main/Installation) article:
https://wiki.artixlinux.org/Main/Installation
Everything works fine until runit and elogind-runit packages installation. basestrap returns the error about runit and dinit being in conflict and refuses to install two packages.
artixlinux:[artix]:~$ sudo basestarp /mnt runit elogind-runit ==> Creating install root at /mnt -> Installing packages to /mnt :: Syncronizing package databases... system is up to date world is up to date galaxy is up to date resolving dependencies... looking for conflicting packages... :: runit and dinit are in conflict (svc-manager). Remove dinit? [y/N] error: unresolvable package confliicts detected error: failed to prepare transaction (conflicting dependencies) :: runit and dinit are in conflict ==> ERROR: Failed to install packages to new root artixlinux:[artix]:~$
Artix Wiki Installation (https://wiki.artixlinux.org/Main/Installation) guide doesn't describe this situation.
Actually, there are two more conflicts between runit and dinit. They are shown below.
3. Solution: run basestrap with auto-confirmation disabled and two overwrites
By default, basestrap runs with auto-confirmation enabled. So it auto-responds with N to "Remove dinit? [y/N]" question.
Add -i switch to run basestrap command with auto-confirmation disabled and to reply with y to the question (the command still fails, for other reasons):
artixlinux:[artix]:~$ sudo basestarp -i /mnt runit elogind-runit ==> Creating install root at /mnt -> Installing packages to /mnt :: Syncronizing package databases... system is up to date world is up to date galaxy is up to date resolving dependencies... looking for conflicting packages... :: runit and dinit are in conflict (svc-manager). Remove dinit? [y/N] y :: elogind-runit and elogind-dinit are in conflict (init-elogind). Remove elogind-dinit? [y/N] y :: dbus-runit and dbus-dinit are in conflict (dbus-dinit). Remove dbus-dinit? [y/N] y warning: dependency cycle detected: warning: runit-rc will be installed before its runit dependency
Total Download Size: 0.50 MiB Total Installed Size: 2.06 MiB Net Upgrade Size: 1.79 MiB
:: Proceed with installation? (Y/n) Y :: Retrieving packages... popt-1.18-1-x86_64 logrotate-3.18.1-1-x86_64 bootlogd-2.89-2-x86_64 runit-rc-20210122-1-x86_64 runit-2.1.2-28-x86_64 dbus-runit-202104-27-1-any elogind-runit-20210413-1-any Total (7/7) (7/7) checking keys in keyring (7/7) checking package integrity (7/7) loading package files (7/7) checking for file conflicts error: failed to commit transaction (conflicting files) runit-rc: /mnt/usr/bin/modules-load exists in filesystem (owned by dinit-rc) runit-rc: /mnt/usr/share/man/man8/modules-load.8.gz exists in filesystem (owned by dinit-rc) Errors occurred, no packages were upgraded. ==> ERROR: Failed to install packages to new root artixlinux:[artix]:~$
runit and elogind-runit are about to be installed, but they conflict with dinit files already existing in filesystem.
Run basestrap with auto-confirmation disabled and two pacman's-style --overwrite options to overwrite existing files and avoid conflicts. The full command is:
Someone changed the installation instructions entirely, causing the problem in the first place. The inits should've been installed together with the base, so the command should've been something like this: sudo basestrap -i /mnt base elogind-runit
Installing elogind-runit will automatically pull the init package, so you won't have to reinstall the init package anymore, causing the conflict.
Title: Re: [Tracker] Dinit support
Post by: calvinh on 09 November 2021, 17:56:18
You can do it like this: ln -s ../service_name /etc/dinit.d/boot.d/
The time? For now, I can't really say since I don't test that part myself. The order? We can look at the depends-on and waits-for in the services. As for the logging, we only log the services for now (see /var/log/dinit). But perhaps we can use bootlogd for overall boot process. As for the some messages printing, the tty service started messages should be the last one (i.e. if wpa_supplicant or mysql runs, it won't spam the screen).
I was trying to see how dinit handles the dependencies in runtime. A boot log like /var/log/rc.log in OpenRC should be simple enough to provide both the time and order information for the boot process. Given dinit in Artix is still in early testing stage, we can add more little pieces in the future.
BTW all Calamare installers in weekly builds are broken. Need to update them...
Title: Re: [Tracker] Dinit support
Post by: konimex on 10 November 2021, 12:23:52
I was trying to see how dinit handles the dependencies in runtime. A boot log like /var/log/rc.log in OpenRC should be simple enough to provide both the time and order information for the boot process. Given dinit in Artix is still in early testing stage, we can add more little pieces in the future.
Try to install and enable bootlogd-dinit. The bootlog location will be in /var/log/boot, but it works partially as it needs access to /dev/console (i.e. this means pseudofs will never show up on startup).
... Someone changed the installation instructions entirely, causing the problem in the first place. The inits should've been installed together with the base, so the command should've been something like this: sudo basestrap -i /mnt base elogind-runit ...
TLDR: there are no runit and dinit conflits anymore. The issue is solved.
Re-installed Artix-runit base ISO (https://iso.artixlinux.org/iso/artix-base-runit-20210726-x86_64.iso) from scratch, following restored old Installation (https://wiki.artixlinux.org/Main/Installation) guide (the current one). Though not as complete and useful as removed guide, it hits the main goal - helps to completely avoid any conflict between runit and dinit.
Artix-runit Gnome is installed from base ISO and runs very smoothly.
A mix of best parts from removed Installation guide and the current (https://wiki.artixlinux.org/Main/Installation) one would be great.
The subtopic "runit and dinit conflict" is solved and closed. Thanks.
Title: Re: [Tracker] Dinit support
Post by: phoenix_king_rus on 10 November 2021, 19:22:26
I have got the following error messages booting dinit with nfs-server and haveged enabled:
dinit: rpcbind: execution failed - setting up standard input/output descriptors: No such file or directory [FAILED] rpcbind [FAILED] statd [FAILED] nfs-server dinit: haveged: execution failed - setting up standard input/output descriptors: No such file or directory [FAILED] haveged
nfs-server (and its deps) is started right after pseudofs which seemd to be too early. The problem with haveged is completely unclear to me
Title: Re: [Tracker] Dinit support
Post by: konimex on 11 November 2021, 11:05:13
dinit: rpcbind: execution failed - setting up standard input/output descriptors: No such file or directory [FAILED] rpcbind [FAILED] statd [FAILED] nfs-server dinit: haveged: execution failed - setting up standard input/output descriptors: No such file or directory [FAILED] haveged
nfs-server (and its deps) is started right after pseudofs which seemd to be too early. The problem with haveged is completely unclear to me
There should be a log in /var/log/dinit for both rpcbind and haveged. Anyway, moved rpcbind and haveged to be started after setup. Should be in the newest package now.
Title: Re: [Tracker] Dinit support
Post by: calvinh on 11 November 2021, 16:18:14
Today's new builds fixed the dependency issues in Calamare installers. However, dinit still doesn't install.
https://ibb.co/YWdLwMp
Title: Re: [Tracker] Dinit support
Post by: nous on 11 November 2021, 23:55:35
Today's new builds fixed the dependency issues in Calamare installers. However, dinit still doesn't install.
A dinit module for calamares is still needed for the GUI installer. Soon(™).
Title: Re: [Tracker] Dinit support
Post by: konimex on 13 November 2021, 03:32:20
UPDATE: I have split the dinit package into two distinct packages: dinit-base and dinit. dinit-base is the "basic" dinit package which won't conflict with other init systems, so you can use it if you want to manage user services as described here (https://forum.artixlinux.org/index.php/topic,3268.html). dinit will depend on dinit-base and will remain as the proper init package so it will conflict with other init system.
Title: Re: [Tracker] Dinit support - spice-vdagent-dinit
Post by: purpleleaf on 29 December 2021, 16:29:39
Package spice-vdagent-dinit In PKGBUILD, row 19, there is a typo: install -Dm755 spice-vdagentd.script "$pkgdir/etc/dinit.d/scripts/pice-vdagentd" renaming pice-vdagentd to spice-vdagentd fix the problem
Title: Re: [Tracker] Dinit support
Post by: konimex on 31 December 2021, 12:59:48
Package spice-vdagent-dinit In PKGBUILD, row 19, there is a typo: install -Dm755 spice-vdagentd.script "$pkgdir/etc/dinit.d/scripts/pice-vdagentd" renaming pice-vdagentd to spice-vdagentd fix the problem
Fixed. Thanks for the report and oops.
Title: Re: [Tracker] Dinit support
Post by: Hitman on 04 February 2022, 22:19:02
Dinit installs just fine with Calamares now, i got it set up on a lower memory machine, boots very quickly too
Title: Re: [Tracker] Dinit support
Post by: purpleleaf on 26 February 2022, 16:10:20
Any way to disable elogind? i don't use it at all. I don't want remove it, only disable it.
dinitctl: could not unlink dependency entry /etc/dinit.d/boot.d/elogind: No such file or directory dinitctl: note: service was disabled, but will be re-enabled on restart.
Title: Re: [Tracker] Dinit support
Post by: ndowens on 26 February 2022, 23:41:10
dinitctl: could not unlink dependency entry /etc/dinit.d/boot.d/elogind: No such file or directory dinitctl: note: service was disabled, but will be re-enabled on restart.
When it gives no such file/dir in this case, it means it's not enabled for boot. There may be some other service that is starting elogind.
Title: Re: [Tracker] Dinit support
Post by: purpleleaf on 02 March 2022, 22:14:49
Sorry for the late. Thanks for the response, but this does not solve my question. How i can disable elogind using dinit?
If you run "dinitctl stop elogind" (as root) it should tell you which active services require elogind (and you may be able to disable those). Having said that, I'm not sure you are supposed to be able to disable elogind. It's a pretty fundamental system component, depending on how things are set up. (When you say you "don't use it", I'm wondering if you're fully aware of what it actually does. You might be using it without realising. But if you're sure, that dinitctl command should give you the information you need).
(Edit: actually, that will only work if the dependencies are hard dependencies, which the output from the disable command that you already tried makes me suspect is not the case. In that case, you need to find the dependents by grepping the service description files for example, and remove elogind from them. man dinit-service for details of the service description format, online version here: https://davmac.org/projects/dinit/man-pages-html/dinit-service.5.html).
Title: Re: [Tracker] Dinit support
Post by: strajder on 03 March 2022, 07:57:39
Any way to disable elogind? i don't use it at all. I don't want remove it, only disable it.
This is a very strange request. Why not go all the way and simply remove elogind, if you want to replace it with something like seatd (https://forum.artixlinux.org/index.php/topic,3050.0.html)?
One or the other is necessary for a lot of programs to function.
Title: Re: [Tracker] Dinit support
Post by: purpleleaf on 03 March 2022, 15:25:11
(When you say you "don't use it", I'm wondering if you're fully aware of what it actually does. You might be using it without realising. But if you're sure, that dinitctl command should give you the information you need).
I know i don't use it because if i stop it, all works flawlessy, and because i assembled my system with packages that don't have elogind or logind as dependecies (no dm, no polkit, etc.).
This is a very strange request. Why not go all the way and simply remove elogind, if you want to replace it with something like seatd (https://forum.artixlinux.org/index.php/topic,3050.0.html)?
Thanks strajder, i will try this way, for what i read seatd is a good choice considering the switch to wayland in a near future.... and may be seatd can be disabled :)
Title: Re: [Tracker] Dinit support
Post by: purpleleaf on 03 March 2022, 16:58:08
I succesfully installed seatd and seatd-dinit, then removed elogind-dinit and enabled seatd. After reboot seat is started but also elogind-daemon
i can't remove elogind for it's dependencies. i suppose it was started by dbus, because the /proc/pidnumber/environ shows:
DBUS_STARTER_ADDRESS=unix:path=/run/dbus/system_bus_socketDBUS_STARTER_BUS_TYPE=system i make a test disabling dbus, and elogind-daemon does not start. I will try to find where dbus starts elogind.
Title: Re: [Tracker] Dinit support
Post by: strajder on 03 March 2022, 18:21:33
it seems that more work will be required to use seatd with dinit.....
Indeed, my apologies. I'm using seatd under 66. dinit is a relatively new addition to Artix and seatd support predates it. It will need additional work to support seatd.
Title: Re: [Tracker] Dinit support
Post by: purpleleaf on 03 March 2022, 23:06:24
I tried disabling the dbus service, after adding my user to the input group, and now i can start openbox without problem. i don't now if seatd is used, i don't have a DM. I will try to disable seatd tomorrow. Artix developers must only fix the tmpfiles errors at boot :)
Title: Re: [Tracker] Dinit support
Post by: konimex on 04 March 2022, 12:55:50
Title: Dinit 2022 07 13 plasma iso-install worked well with post tweak to clamd-dinit
Post by: jspaces on 23 October 2022, 05:41:50
I had a chance to try the latest dinit image, artix-plasma-dinit-20220713-x86_64.iso when the silence dead of my nvme root drive caused me to rebuild everything from the get go. The installation process when as painless as one can expect when rebuilding the universe. All I customized really was the fstab entries with getting the other disks going and my tmpfs entries for my ~/.cache and /tmp folders. After getting everything back, I install clamav-dinit and enabled it. Dinitctl enabled and started the clamd daemon without any error. Upon reboot though it failed with error 2 restarting too fast stopped. I edited the /etc/dinit.d/clamd file and changed the wait for pseudofs to sysusers as it also started successfully once I got logged in and manually start through dinitctl. I liked that it worked without issue after the edit. I have freshclam running via a cron job for the updates (I use fcron). All the other dinit startup processes have worked so far including openvpn which was only edited to connect to a commercial VPN server configuration file.
$ cat /etc/dinit.d/clamd type = process command = /etc/dinit.d/scripts/clamd smooth-recovery = true logfile = /var/log/dinit/clamd.log waits-for = sysusers
Even though it was not a happy day when I started my computer up only to see the BIOS displayed show up with the NVME no longer present one morning a week ago, I was very pleased with the ease to get my system running with my favourite distro's graphical installer. My humble thanks to the tireless devs who have brought us mere mortals Artix Linux.
Title: Re: [Tracker] Dinit support
Post by: Panda on 10 December 2022, 12:06:48
Hi,
First of all, thank you for maintaining "Dinit" init system.
I'm using "Dinit" with KDE fresh install using weekly community ISO.
So, the issue is that, acpid fails to start on boot. But it starts fine when I start it manually after boot.
The following is what it says in the boot screen.
Quote
dinit: acpid: execution failed - setting up standard input/output descriptors: No such file or directory
Here is what shows in the dinit status after boot.
Quote
% sudo dinitctl status acpid Service: acpid State: STOPPED (could not be launched) Stage: setting up standard input/output descriptors Error: No such file or directory
After starting it manually with "sudo dinitctl start acpid".
Quote
% sudo dinitctl status acpid Service: acpid State: STARTED Activation: explicitly started Process ID: xxxx
Quote
Xorg.log: (WW) Open ACPI failed (/var/run/acpid.socket) (No such file or directory)
When I start the process manually using "sudo dinitctl start acpid", the file magically appears.
Request you to look into this issue. Thank you.
Title: Re: [Tracker] Dinit support
Post by: gavincc on 10 December 2022, 15:34:17
and doing a:
sudo dinitctl enable acpid
followed by a restart has no effect?
Title: Re: [Tracker] Dinit support
Post by: Panda on 10 December 2022, 16:43:23
acpid service is already enabled by default. So, this does not change anything.
Anyway, here is what it says.
Quote
% sudo dinitctl enable acpid dinitctl: service already enabled.
Title: Re: [Tracker] Dinit support
Post by: gavincc on 10 December 2022, 17:12:26
just a quick question, when you say - "I'm using "Dinit" with KDE fresh install using weekly community ISO", have you changed your init, as the only weekly community .iso is openrc? https://download.artixlinux.org/weekly-iso/artix-community-gtk-openrc-20221205-x86_64.iso
Title: Re: [Tracker] Dinit support
Post by: capezotte on 10 December 2022, 18:20:36
Is your /var or /var/log on a separate partition?
The only cause that I know of for a "no such file or directory" error message in that stage of dinit is opening the log file (https://github.com/davmac314/dinit/blob/v0.16.0/src/run-child-proc.cc#L209).
Title: Re: [Tracker] Dinit support
Post by: Panda on 11 December 2022, 18:28:33
just a quick question, when you say - "I'm using "Dinit" with KDE fresh install using weekly community ISO", have you changed your init, as the only weekly community .iso is openrc? https://download.artixlinux.org/weekly-iso/artix-community-gtk-openrc-20221205-x86_64.iso
Nope, nothing like that. I downloaded the "Dinit" ISO (artix-plasma-dinit-20221205-x86_64.iso) from Artix Linux primary mirror, France. (http://mirror1.artixlinux.org/weekly-iso/)
The only cause that I know of for a "no such file or directory" error message in that stage of dinit is opening the log file (https://github.com/davmac314/dinit/blob/v0.16.0/src/run-child-proc.cc#L209).
Nope, everything is in the same partition, including "home" directory.
Title: Re: [Tracker] Dinit support
Post by: gavincc on 11 December 2022, 18:39:38
ok, so you're not using the "community iso" like you said to begin with, but the weekly plasma-dinit. Ok, next question, on live boot, I'm assuming it worked, but on installation, followed by a restart, did it fail then? Or did it start okay, then you did an update, followed by a system reboot, and then it failed? Or was it ok at that point in time? (before anything else was done to it, as thats all the steps needed to begin with to get it running). Ascertaining the point at which it started failing, and the steps prior to that point in totality as much as possible (even if those steps do not appear to have any relevance) are pretty vital to start effectively troubleshooting.
Title: Re: [Tracker] Dinit support
Post by: Panda on 13 December 2022, 06:58:10
ok, so you're not using the "community iso" like you said to begin with, but the weekly plasma-dinit. Ok, next question, on live boot, I'm assuming it worked, but on installation, followed by a restart, did it fail then? Or did it start okay, then you did an update, followed by a system reboot, and then it failed? Or was it ok at that point in time? (before anything else was done to it, as thats all the steps needed to begin with to get it running). Ascertaining the point at which it started failing, and the steps prior to that point in totality as much as possible (even if those steps do not appear to have any relevance) are pretty vital to start effectively troubleshooting.
Sorry, I got confused with the community ISO and graphical installation ISO.
I booted the live Dinit ISO and ACPID service started fine.
So, to figure out if the issue was really with Dinit, I migrated from Dinit to OpenRC and guess what, ACPID service started fine.
But OpenRC is a battle tested init system, so I then again migrated from OpenRC to S6 and again ACPID service started fine.
So, this proves the installation is fine and so were the BIOS settings.
What I usually do is the following.
Install from live ISO, update and reboot.
Add support for 32-bit repos, arch repos, update and reboot.
Install Wayland packages and reboot into Wayland.
Install all other necessary applications.
I did the same steps with OpenRC live ISO with that same dated Graphical ISO (weekly) and all services have started properly.
I don't have the time to reproduce the Dinit issue now, but I have the ISO saved, so I'll do a fresh install in another drive and will see if I can reproduce the issue, if I have the time & patience.
Thank you all. :)
PS: I'm using GNU Linux for more than 15 years as primary OS, so I know what I was doing and not doing random stuffs.
Title: Re: [Tracker] Dinit support
Post by: gavincc on 13 December 2022, 16:27:10
thanks for the info., so basically the installation/full update/power cycle/re-login works as it should without error. So, something post install is breaking it, I'm assuming the extra repo's you've added are in the correct order and nothing funky like any testing repo has been added. Anyway, once you use a different drive and do a fresh install, it'll then be a case of adding components and rebooting after each to see what is breaking it (pain in the butt, but hey, dinit is so blindingly fast to reboot, shouldn't take much additional time!). WM or any DM changes? AUR packages etc? Anyway, shall be interesting to see which additional Arch/AUR package(S) is/are breaking it.
Goodluck Panda, G
Title: Re: [Tracker] Dinit support
Post by: davmac on 14 December 2022, 07:43:02
As capezotte suggested the only reason you could get that status is if the log file can't be created. Therefore I would look at /etc/dinit.d/acpid and check both the logfile setting and any waits-for or depends-on dependencies. My first suspicion is the log file is specified to be written to a directory which doesn't exist at the time the acpid service is started, but which is created later on by another service, which is why you are able to start it after booting.
However, looking at the acpid service description file currently (https://gitea.artixlinux.org/packagesA/acpid-dinit/src/branch/master/trunk/acpid), it should have logfile set to /var/log/dinit/acpid.log:
type = process command = /usr/bin/acpid -f smooth-recovery = true depends-on = pseudofs logfile = /var/log/dinit/acpid.log
I think it really should have a dependency on root-rw, since there's no guarantee it will be able to create the log file without that, although I would've expected a different error message from dinitctl status acpid if that were really the problem. To try it with this dependency, you could add the line:
Title: Re: [Tracker] Dinit support
Post by: davmac on 14 December 2022, 12:54:30
While I'm about it, I also came across a reddit thread (https://www.reddit.com/r/artixlinux/comments/zhxeod/dinit_difficulties/) from someone for who tmpfiles-setup service is failing. Looking at the tmpfiles config, it does seem that it should be run with root mounted read-write, eg it has entries such as:
... which potentially require to be able to write to the root filesystem (assuming /var isn't a mounted filesystem, which it normally wouldn't be). Therefore the tmpfiles-setup service really should depend-on root-rw, unless I'm missing something.
(I suspect the reason this does not usually show up as a problem is because the relevant directories typically do already exist).
Title: Re: [Tracker] Dinit support
Post by: 90 on 12 May 2023, 16:37:00
Been noticing that the lvm2 script also seems to be consistently failing on boot. Both this one and acpid might need to be looked at to see if anything needs to be added to them to ensure they don't fail, though the latter was fixable with a fix mentioned here earlier to add root-rw as a dependency.
Title: Re: [Tracker] Dinit support
Post by: Hitman on 04 December 2023, 13:06:37
Most of the other little stuff in previous post got fixed except for rclocal which still exits with an error despite the script exiting with 0.
I now have a new problem, every few shutdowns / doesn't unmount properly, triggers fsck on the next boot. fs is a plain ext4 this time. How to figure that out? :)
Title: Re: [Tracker] Dinit support
Post by: davmac on 05 December 2023, 12:38:13
I now have a new problem, every few shutdowns / doesn't unmount properly, triggers fsck on the next boot. fs is a plain ext4 this time. How to figure that out? :)
Any errors visible during those shutdowns which don't unmount cleanly?
Title: Re: [Tracker] Dinit support
Post by: Hitman on 05 December 2023, 18:38:43
There are none as far as i can spot them. On the previous install on xfs (or f2fs, i forgot sorry), it did say ”cannot unmount / is busy” every shutdown, but now on this generic ext4 i can't see any.
Title: Re: [Tracker] Dinit support
Post by: davmac on 06 December 2023, 08:59:24
There are none as far as i can spot them. On the previous install on xfs (or f2fs, i forgot sorry), it did say ”cannot unmount / is busy” every shutdown, but now on this generic ext4 i can't see any.
Well, dinit (actually, shutdown) does the following on shutdown:
kill all other processes by sending a SIGKILL broadcast
then, runs "umount -a -r" to unmount filesystems (and remount root read-only)
then, calls sync() to flush disk buffers
then requests the kernel to shutdown
The first step should ensure that the root filesystem is not busy. The second step should ensure that the root filesystem is cleanly unmounted (more specifically, remounted as read-only).
If that isn't the case then the only reasons I can see are:
bug in kernel causing some process not to die, so root remains busy (should get an error from umount in this case)
bug in umount so that it doesn't correctly remount root read-only
bug in kernel such that it's not properly flushing disk buffers
bug in disk drive firmware/hardware so that it's not properly flushing buffers
None of these seem particularly likely, though they're certainly possible.
The only real mechanism for debugging these issues is via the shutdown hook ("man shutdown", "shutdown hooks" section). You could write a hook which does "umount -a -r" itself, syncs and sleeps for a bit, so that any error messages are clearly visible. Perhaps even run dmesg to check for any suspicious kernel messages, an "ps" to see if any processes are still running that shouldn't be.
Title: Re: [Tracker] Dinit support
Post by: Hitman on 06 December 2023, 21:12:18
Very well adviced, appreciate it, didn't know of the shutdown hook script so that comes in handy, i put umount -a -r --verbose before sync to see if there's anything with that, for now it says successful/ignored, need to wait a bit certainly :)
EDIT: I figured out the other cosmetic issue with rc-local in the meantime, /etc/local.d/local.stop exits with 1, the two scripts inheriting it do the same thing and dinit knows (it does it's job too well, hehe). Will let the devs know.
Title: Re: [Tracker] Dinit support
Post by: Hitman on 20 December 2023, 01:54:17
I caught an unsuccessful unmount finally today and it did not provide much info apart from /and /tmp (weirdly) saying target is busy. Guessing it has to be from elsewhere such as hardware or kernel build, but still i might ask, how to force the system to really free up it's resources? (as when a concrete io transfer is happening the shutdown is simply delayed until the unmount will eventually succeed)
Title: Re: [Tracker] Dinit support
Post by: davmac on 22 December 2023, 00:27:06
I caught an unsuccessful unmount finally today and it did not provide much info apart from /and /tmp (weirdly) saying target is busy. Guessing it has to be from elsewhere such as hardware or kernel build, but still i might ask, how to force the system to really free up it's resources? (as when a concrete io transfer is happening the shutdown is simply delayed until the unmount will eventually succeed)
It's sounding like a kernel bug to me. If you follow also my suggestion to run "ps" in the shutdown hook (it needs to run before umount, because it needs /proc mounted) my guess is you'll see a stuck process that can't be killed (it's stuck in the kernel somewhere). And "dmesg" might give a clue as to what exactly has happened in the kernel.
There's not much you can do other than wait for a fix in the kernel, but if dmesg gives you something meaningful you could actually report the problem to the kernel developers and that might lead to a fix more quickly.
Title: Re: [Tracker] Dinit support
Post by: Hitman on 01 April 2024, 16:32:24
A curiosity regarding the new `dinitcheck --online` option, I saw that for user services, it seems to be required in order to list every available service, without it just showing parts of dependencies:
# dinitcheck --online -u -d /run/turnstiled/1000/srv.922/ -p /run/user/1000/dinitctl Checking service: boot... Checking service: system... Service 'system', error reading dependencies from directory /usr/lib/dinit.d/user/boot.d: No such file or directory Checking service: wireplumber... Checking service: pipewire-pulse... Checking service: pipewire... Checking service: dbus... Performing secondary checks... Secondary checks complete. One or more errors/warnings issued. # dinitcheck -u -d /run/turnstiled/1000/srv.922/ -p /run/user/1000/dinitctl Checking service: boot... Checking service: system... Service 'system', error reading dependencies from directory /usr/lib/dinit.d/user/boot.d: No such file or directory Checking service: wireplumber... Unable to load service 'wireplumber': service description not found. Checking service: pipewire-pulse... Unable to load service 'pipewire-pulse': service description not found. Performing secondary checks... Secondary checks complete. One or more errors/warnings issued.
From the normal user:
~> dinitcheck --online Checking service: boot... Checking service: system... Service 'system', error reading dependencies from directory /usr/lib/dinit.d/user/boot.d: No such file or directory Checking service: wireplumber... Checking service: pipewire-pulse... Checking service: pipewire... Checking service: dbus... Performing secondary checks... Secondary checks complete. One or more errors/warnings issued. ~> dinitcheck Checking service: boot... Unable to load service 'boot': service description not found. Performing secondary checks... Secondary checks complete. One or more errors/warnings issued.
Could it be maybe turnstile not setting it up exactly right, hence those warnings? Everything else under dinitctl works perfectly under both root and the normal user. I saw a patch about hardcoding user service paths by default https://github.com/davmac314/dinit/commit/a77acc962aed32b0378cb9185b8d7cf7ad0ae14d which i guess turnstile already overrides, but maybe has something to do here. Also, if it works fine, can i use `dinitcheck --online` instead of iterating with `find` over user service locations to get a listing of what's available?
Title: Re: [Tracker] Dinit support
Post by: kiblaster on 01 April 2024, 21:05:38
I tried that patch on ARMtix I do not have that warning but I do not use turnstile.
Title: Re: [Tracker] Dinit support
Post by: sdothum on 09 April 2024, 15:14:32
Despite the first post referencing Postgres, i have had no such luck with postgres/postgres-dinit.
Attempting to start postgres failed on no postgresql.conf -- /var/lib/postgres/data was empty. This may be normal -- i manually initialized /var/lib/postgres/data by running initdb.
However, after doing so, attempting to dinitctl start postgres fails on the dreaded "could not translate host name "localhost", service "5432" to address: Name or service not known" error. i noticed a user running Artix/runit also has run into this recently in my 2 days of culling the internet for solutions. My /etc/hosts file has the standard 127.0.0.1 and ::1 assignments for localhost.
What am i missing? Is there some other package dependency that postgres relies on to properly create the socket?
This is a clean install of Artix/dinit. It has been awhile since i've been on an arch based distro -- been on Alpine and Void the past few years -- and i am quite liking Artix/dinit so far but this has me stumped.
--
UPDATE: SOLVED
Staring too long at my /etc/hosts..
It ultimately was caused by an error further down in the file caused by a hosts file merge.
Title: Re: [Tracker] Dinit support
Post by: davmac on 30 April 2024, 12:43:05
A curiosity regarding the new `dinitcheck --online` option, I saw that for user services, it seems to be required in order to list every available service, without it just showing parts of dependencies:
...
Could it be maybe turnstile not setting it up exactly right, hence those warnings? Everything else under dinitctl works perfectly under both root and the normal user.
Sorry for the slow answer! Turnstile adds some service directories to the defaults when it starts dinit, which dinitcheck only knows about if it can contact dinit (i.e. if run with --online).
Quote
I saw a patch about hardcoding user service paths by default https://github.com/davmac314/dinit/commit/a77acc962aed32b0378cb9185b8d7cf7ad0ae14d which i guess turnstile already overrides, but maybe has something to do here.
Yes, this patch should make --online unnecessary when using turnstile.
Quote
Also, if it works fine, can i use `dinitcheck --online` instead of iterating with `find` over user service locations to get a listing of what's available?
Be aware that it only checks only current (transitive) dependencies of "boot". So it will ignore services that are available but not enabled and not otherwise depended on by boot or an enabled service.
Title: Re: [Tracker] Dinit support
Post by: renguangxi on 21 May 2024, 15:21:18
One month ago I made a thread (https://forum.artixlinux.org/index.php/topic,6752.0.html) about a problem I have with dinit and with the sddm service where the content of the /tmp folder is randomly deleted, including the Xauth file created by sddm, which prevents the user from opening programs. I'm re-posting here as I'm still having the problem :(
Title: Re: [Tracker] Dinit support
Post by: davmac on 25 May 2024, 03:36:43
I'm re-posting here as I'm still having the problem :(
The problem is almost certainly nothing to do with dinit itself but might be a service issue.
Can you post the output of `sudo dinitctl list` and `mount` immediately after logging in? I'm wondering if some service is taking a long time to start for some reason and that is delaying the mount of the tmpfs on /tmp (or it's getting re-mounted at some point for example).
Title: Re: [Tracker] Dinit support
Post by: konimex on 25 May 2024, 05:51:13
I don't think it's anything specifically with services either, given that /tmp is mounted before udevd-early (before dinit-rc 0.3.0) or before early-prepare.target (after 0.3.0) and is never invoked again after that.
Inspecting both current sddm-dinit pkg (https://gitea.artixlinux.org/packages/sddm-dinit) and older sddm-dinit (https://gitea.artixlinux.org/packages/sddm-dinit/src/commit/c31e22bd1e07377e5ef850a8b0c5430937b87b3a), there's no commands to remount /tmp either.
Title: Re: [Tracker] Dinit support
Post by: davmac on 25 May 2024, 07:05:57
I don't think it's anything specifically with services either
Yeah, you might be right - I'm just struggling to think of what would remove files in (or remount) /tmp and why.
renguangxi – I assume you've checked system logs for anything unusual?
Title: Re: [Tracker] Dinit support
Post by: konimex on 29 May 2024, 10:44:21
I'm unpinning and closing this thread since support has gotten to the level of "good enough". I'm happy enough with the startup/shutdown scripts, I'm happy enough with most of the implementations. There will always be things to iron out, but I can say that this thread served its purpose. Any and all new announcements regarding dinit will be made in a new thread, and please make a thread if you have any problems with Artix's dinit services (or anything probably related to dinit, really).
Regarding turnstile, I guess a separate thread ala seatd will be made.