Thank you for testing, Sven. I'll get this change committed and then
publish a new version of the SysV suite soon.
Jesse
On 2024-07-28 14:02, Sven Reschke wrote:
Sorry for being hasty.
I tested the patch recommended by Petter, with adjustments to the
current bootlogd version.
Looks like it
Sorry for being hasty.
I tested the patch recommended by Petter, with adjustments to the
current bootlogd version.
Looks like it's working, at least I don't have a greedy bootlogd process
anymore, and the boot logfile also looks good, with the root cause logged:
...
stty: 'standard inp
On 2024-07-23 17:46, Petter Reinholdtsen wrote:
Is this related to the issue reported with patch in
https://mail.gnu.org/archive/html/sysvinit-devel/2017-07/msg0.html >?
The patch seems to be almost perfect, once adjusted for some things
having been moved around since it was written. I'm
I did some debugging.
I've attached the patch I've applied to the 3.04 of sysvinit
bootlogd.c src file.
It includes your changes plus additional debug printfs.
The process is started with the following command in the init.d script:
nohup stdbuf -o0 -e0 $DAEMON -r -c -d > /tmp/bootlogd.log 2>&
On 2024-07-23 17:46, Petter Reinholdtsen wrote:
Is this related to the issue reported with patch in
https://mail.gnu.org/archive/html/sysvinit-devel/2017-07/msg0.html >?
Hi Peter,
Yes, this looks like the same bug. And with a nice fix included. I'll
take a look at this as an option and
Is this related to the issue reported with patch in
https://mail.gnu.org/archive/html/sysvinit-devel/2017-07/msg0.html >?
--
Happy hacking
Petter Reinholdtsen
On 2024-07-23 09:17, Jesse Smith wrote:
On 2024-07-11 05:44, Sven Reschke wrote:
I have a rented root server, where I have a yocto build running,
which
utilizes sysvinit.
After logging in, the /var/log/boot file is empty and the process is
On 2024-07-23 09:17, Jesse Smith wrote:
On 2024-07-11 05:44, Sven Reschke wrote:
I have a rented root server, where I have a yocto build running,
which
utilizes sysvinit.
After logging in, the /var/log/boot file is empty and the process is
On 2024-07-23 09:17, Jesse Smith wrote:
On 2024-07-11 05:44, Sven Reschke wrote:
I have a rented root server, where I have a yocto build running,
which
utilizes sysvinit.
After logging in, the /var/log/boot file is empty and the process is
On 2024-07-23 09:17, Jesse Smith wrote:
On 2024-07-11 05:44, Sven Reschke wrote:
I have a rented root server, where I have a yocto build running,
which
utilizes sysvinit.
After logging in, the /var/log/boot file is empty and the process is
On 2024-07-23 09:17, Jesse Smith wrote:
On 2024-07-11 05:44, Sven Reschke wrote:
I have a rented root server, where I have a yocto build running,
which
utilizes sysvinit.
After logging in, the /var/log/boot file is empty and the process is
On 2024-07-23 07:20, Sven Reschke wrote:
On 2024-07-11 05:44, Sven Reschke wrote:
I have a rented root server, where I have a yocto build running, which
utilizes sysvinit.
After logging in, the /var/log/boot file is empty and the process is
taking up to 95%
On 2024-07-11 05:44, Sven Reschke wrote:
I have a rented root server, where I have a yocto build running, which
utilizes sysvinit.
After logging in, the /var/log/boot file is empty and the process is
taking up to 95% of cpu usage. Also the process doesn't react on
On 2024-07-11 05:44, Sven Reschke wrote:
I have a rented root server, where I have a yocto build running, which
utilizes sysvinit.
After logging in, the /var/log/boot file is empty and the process is
taking up to 95% of cpu usage. Also the process doesn't react on SIGINT.
After some debugging, I
Thank you for this report. I'll look into it.
I agree, we should probably have a max number of attempts in place. And
possibly a greater pause between attempts to reduce the process's load
on the system while it is retrying.
Jesse
On 2024-07-11 05:44, Sven Reschke wrote:
I have a rented ro
I have a rented root server, where I have a yocto build running, which
utilizes sysvinit.
After logging in, the /var/log/boot file is empty and the process is
taking up to 95% of cpu usage. Also the process doesn't react on SIGINT.
After some debugging, I saw, that the process is trying to open t
16 matches
Mail list logo
