In message <[email protected]>, Stefan Esser
wri
tes:
> This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
> --NK2NXzwQu7dx8KsgmaoRg3Dm6O6zdPwBc
> Content-Type: multipart/mixed; boundary="IvLrYgq138dlzrHKca2qNTCpIvtGaetXM";
> protected-headers="v1"
> From: Stefan Esser <[email protected]>
> To: Cy Schubert <[email protected]>
> Cc: [email protected], [email protected],
> [email protected], Chris Rees <[email protected]>,
> Baptiste Daroussin <[email protected]>, Rick Parrish <[email protected]>,
> Alastair Hogge <[email protected]>
> Message-ID: <[email protected]>
> Subject: Re: git: 77e1ccbee3ed - main - rc: implement parallel boot
> References: <[email protected]>
> <[email protected]>
> <[email protected]>
> <[email protected]>
> <[email protected]>
> <[email protected]>
> <[email protected]>
> In-Reply-To: <[email protected]>
>
> --IvLrYgq138dlzrHKca2qNTCpIvtGaetXM
> Content-Type: text/plain; charset=windows-1252; format=flowed
> Content-Language: en-US
> Content-Transfer-Encoding: quoted-printable
>
> Am 08.03.21 um 15:22 schrieb Cy Schubert:
> >> SDDM fails to successfully start an X session now, too.
> >>
> >> It repeatedly tries to start the X server without success.
> >> Only a "service sddm restart" terminates this loop.
> >>
> >> I do assume that the same applies to quite a number of services
> >> that are installed form ports/packages.
> >>
> >> While we can test parallel execution of rc scripts in base, this
> >> is not easily possible for the large number of optional services
> >> provided by ports/packages.
> >>
> >> I'll try to find the cause of the start-up failure for the SDDM
> >> case on my system. But even if I get it fixed on my system, it
> >> may still fail to start the X server on systems with a different
> >> set of ports ...
> >>
> >> Regards, STefan
> >=20
> > Is this new breakage after 763db589328 or before the fixes to this?
>
> This issue exists since the initial commit that enabled parallel start=20
> of rc scripts. I do not see why the X server does not start, since the
> commands that are started in parallel appear to be completely unrelated
> and I do assume that scripts are only started from the next line after
> the previous ones are running (but maybe not yet completely functional).
Yes, the original commit broke rc due to some incorrect assumptions by the
author -- it messed up non-parallel boot here. I don't use parallel rc
here. I think bapt@ does.
>
> SDDM is in the 2nd-last line of rcorder -p output on my system:
>
> /etc/rc.d/sendmail
> /usr/local/etc/rc.d/apache24
> /usr/local/etc/rc.d/postfix
> /etc/rc.d/othermta
> /etc/rc.d/bgfsck
> /usr/local/etc/rc.d/postgresql
> /etc/rc.d/securelevel
> /usr/local/etc/rc.d/sddm
>
> (All the above listed rc files are on a single line, actually.)
When I started looking at it, it uses spaces to separate related scripts to
be started serially and line feeds for parallel threads.
>
>
> BTW: I was surprised to see the following line 139 in /etc/rc:
>
> files=`rcorder ${skip} ${skip_firstboot} /etc/rc.d/* ${local_rc}
> ${_rc_parallel} 2>/dev/null`
>
>
> Since ${_rc_parallel} is at the end of the command line, it does not
> have any impact on the output that is generated ...
>
> This seems to indicate that scripts from /usr/local/etc/rc.d are not
> executed in parallel, which makes the SDDM failure even more
> surprising.
I'll leave this to bapt@ and the author to answer. I suspect that this too
wasn't tested, hence the suggestion that this not be MFCed for six weeks,
or maybe never. The original commit seriously broke my infrastructure here.
--
Cheers,
Cy Schubert <[email protected]>
FreeBSD UNIX: <[email protected]> Web: https://FreeBSD.org
NTP: <[email protected]> Web: https://nwtime.org
The need of the many outweighs the greed of the few.
_______________________________________________
[email protected] mailing list
https://lists.freebsd.org/mailman/listinfo/dev-commits-src-main
To unsubscribe, send any mail to "[email protected]"
