Greetings! I understand this is not the right time to talk about business with ongoing pandemics plus crisis going on in Europe, but when the going gets tough, the tough get going. I am pleased to announce that we are using our finance-firm platform to help our investors take advantage of investing overseas or within, where they can get more profit for their funds.
We have assembled one of the most experienced teams in hedge funds, in loan and equity finance. We understand that a foreign company looking for investors is going to need some help in order to make an offer that is both attractive to the investors and fully compliant with law. We are here to guide you on the equity and loan finance model. We also provide investment capital in form of debt with anticipated ROI of 2 to 4% depending on the model of investment and amount required.
We can give you a credit facility if the project is feasible. It is a designed stage for Money Hunters to boldly present their companies and their projects to our 9 investors. Consider this a shout-out to all individuals and firms looking for loan and equity finance.
If you know of a company in need of funding, we have 16 ready investors to assist. There is a commission model for partners who make referrals.
Note: We Help Clients Solved Their Business Difficulties.
With warmest regards,
Bill Betterman
On 17/05/2022 09:51, Arnaud Panaïotis wrote:
> Hello,
>
> I'm working for a client to generate embedded 32-bits Linux Kernel working after y2038 issue.
>
> I generated a 5.15 Kernel thought Buildroot with Coreutils 9.0, GCC 11.2.0, Binutils 2.37, Glibc 2.34-9 and CFLAGS -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64.
>
> I encounter an issue while working with OpenSSH (I initially contacted them before).
To clarify: did you build just openssh with -D_TIME_BITS=64, or did
you build the user space
this way?
> After 2038, /usr/sbin/sshd does not create an error but it child does generate this one:
> daemon() failed: Value too large for defined data type
>
> This happend here in sshd.c:
>
> 2019 /*
> 2020 * If not in debugging mode, not started from inetd and not already
> 2021 * daemonized (eg re-exec via SIGHUP), disconnect from the controlling
> 2022 * terminal, and fork. The original process exits.
> 2023 */
> 2024 already_daemon = daemonized();
> 2025 if (!(debug_flag || inetd_flag || no_daemon_flag || already_daemon)) {
> 2026
> 2027 if (daemon(0, 0) == -1)
> 2028 fatal("daemon() failed: %.200s", strerror(errno));
My guess is that there are parts of glibc that are not fully
y2038-safe at the moment, but
merely provide the interfaces for time64 applications.
In the glibc code, I see
int
daemon (int nochdir, int noclose)
{
...
if ((fd = __open_nocancel(_PATH_DEVNULL, O_RDWR, 0)) != -1
&& (__builtin_expect (__fstat64 (fd, &st), 0)
== 0)) {
...
} else {
__close_nocancel_nostatus (fd);
return -1;
}
return (0);
}
__fstatat64 (int fd, const char *file, struct stat64 *buf, int flags)
{
struct __stat64_t64 st_t64;
return __fstatat64_time64 (fd, file, &st_t64, flags)
?: __cp_stat64_t64_stat64 (&st_t64, buf);
}
If I'm reading this correctly, daemon() internally uses the time32
version of 'stat', which
fails for files with out-of-range timestamps. Are you able to rebuild
the ssh binary
(or your entire distro, if that's easier) against musl-1.2.x instead
of glibc to see if the
same thing happens there?
Arnd
> To reproduce:
>
> # date -s "2040-05-12"
> # hwclock --systohc
> # reboot
> # /usr/sbin/sshd
>
> Note this error occurs only after the reboot, and setting a date before 2038 also require a reboot to remove the error.
>
> strace and gdb trace linked.
>
> Let me know if you need additional information.