Skip to main content ↑ ↓
Topic solved
This topic has been marked as solved and requires no further attention.
Topic: [Tracker] Dinit support (Read 7550 times) previous topic - next topic
0 Members and 4 Guests are viewing this topic.

Re: [Tracker] Dinit support

Reply #45 –
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. 

Re: [Tracker] Dinit support

Reply #46 –
Quote from: gavincc – on
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.

Re: [Tracker] Dinit support

Reply #47 –
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

Re: [Tracker] Dinit support

Reply #48 –
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:

Code: [Select]
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:
Code: [Select]
depends-on  = root-rw


Re: [Tracker] Dinit support

Reply #49 –
While I'm about it, I also came across a reddit thread 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:

Code: [Select]
d /var/log 0755 - - -

... 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).

Re: [Tracker] Dinit support

Reply #50 –
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.

Re: [Tracker] Dinit support

Reply #51 –
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? :)

Re: [Tracker] Dinit support

Reply #52 –
Quote from: Hitman – on
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?

Re: [Tracker] Dinit support

Reply #53 –
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.

Re: [Tracker] Dinit support

Reply #54 –
Quote from: Hitman – on
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.

Re: [Tracker] Dinit support

Reply #55 –
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.

Re: [Tracker] Dinit support

Reply #56 –
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)

Re: [Tracker] Dinit support

Reply #57 –
Quote from: Hitman – on
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.
 

Re: [Tracker] Dinit support

Reply #58 –
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:

Code: [Select]

From root:

# 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?

Re: [Tracker] Dinit support

Reply #59 –
I tried that patch on ARMtix I do not have that warning but I do not use turnstile.