Hi!
All information asked for was either already provided (you even quote the
text where it was provided!) or is entirely unnecessary to investigate
this problem. I have tried to duplicate the information in a different
form below, in case there was a comprehension issue. If you still think
some information is missing you would need to more clearly explain what
you think is missing, and I'd be happy to provide it.
On Tue, Nov 12, 2019 at 12:55:42AM +0100, Michael Biebl <bi...@debian.org>
wrote:
> > To accomplish this I have an initramfs-tools script that runs it something
> >
> > exec -a @ntfs-3g-root ntfs-3g ...
>
> Would be great if you can share this script so we can see what exactly
> it is doing.
Uhm, what other information could potentially be of use? Nothing else
in the script is of any relevance, other than starting a daemon with
@ as first character of its name. The arguments do not do anything to
change the name, and that's essentially the only other thing that the
script does. The only relevant information is that systemd has special
(but buggy) code for processes whose names start with '@' - nothing else
matters, as systemd clearly doesn't check for anything else, as you can
see in the code - just grep for the log_notice I provided (I don't have
easy access to it righ now, otherwise I woudl do it for you).
> > The @ prevents systemd-shutdown from killing it, which works. However, it
> > outputs the following warning (lifted from the code, can't copy&paste from
> > the real system):
> >
> > log_notice("Process " PID_FMT " (%s) has been marked to be
> > excluded from killing. It is "
> > "running from the root file system, and thus
> > likely to block re-mounting of the "
> > "root file system to read-only. Please consider
> > moving it into an initrd file "
> > "system instead.", pid, strna(comm));
> >
> > Since it is running from the initramfs, this warning is bogus (and indeed,
> > the root fs can be mounted ro with no problem), suggesting that the check
> > systemd-shutdown uses to detect this case is broken.
> >
> > For additional reference, /proc/<ntfs-3g-pid>/root has a target of "/",
> > which probably causes this. /proc/<ntfs-3g-pid>/exe has a target of
> > '/usr/bin/ntfs-3g (deleted)', which makes sense as it was deleted when
> > cleaning up the initramfs before handing over to the actual root fs.
>
> Please supply the information that was requested by upstream:
The information is right in the paragraph you just quoted - root points to
"/" and exe points to "/usr/bin/ntfs-3g (deleted)".
> have a magic effect, and point to something potentially different than
> their literal value. Hence, can you do stat on those two magic symlinks
> to see what they actually point to?
stat can't show you what they "actually" point to, but since the command
was started using initramfs (as also already mentioned), / obviously
points to the root of the initramfs, and the ntfs-3g dxecutable in there
has been deleted when it was cleaned up during boot, unless you want to
assume a kernel bug.
What _stat_ can tell you is that "root" points to a different filesystem
(the tmpfs used by the kernel) than the current root filesystem that is
supposedly blocked.
--
The choice of a Deliantra, the free code+content MORPG
-----==- _GNU_ http://www.deliantra.net
----==-- _ generation
---==---(_)__ __ ____ __ Marc Lehmann
--==---/ / _ \/ // /\ \/ / schm...@schmorp.de
-=====/_/_//_/\_,_/ /_/\_\
