Onedrive process often stops unexpectedly after change OS from Cent OS 7 to Rocky9

[adg7511]

Onedrive Version
onedrive v2.4.13

OS Version
NAME="Rocky Linux"
VERSION="9.3 (Blue Onyx)"

We have been using onedrive to download/upload files from SharePoint for many years without any problem.
Recently, we changed OS from Cent OS 7 to Rocky9 by migrating all onedrive installation and configuration dir.
In Rocky9, onedrive can be started and run normally. But it often stops unexpectedly after running for a while (One or two days or less than one day).
There is nothing special in onedrive log when it stops.

Can anyone help investigate or resolve this issue?

[abraunegg]

@adg7511

onedrive v2.4.13
...
There is nothing special in onedrive log when it stops.
...
Can anyone help investigate or resolve this issue?

Firstly, you are running a 100% obsolete and unsupported client version. You are running something that was released in Jul 14, 2021 and there have been significant bug fixes and improvements since then.

As per the readme & support policy:

Additionally, this issue is called out as a Known Issue: https://github.com/abraunegg/onedrive/blob/onedrive-v2.5.0-release-candidate-1/docs/known-issues.md#application-stops-running-without-any-visible-reason

Actions for you:

1. Upgrade your client version urgently. Install from EPEL
2. Ensure your 'curl' version is as up-to-date as possible
3. Re-test

Post retesting, if you are still encountering an issue:

1. Force your client to use IPv4 only as curl has been found to intermittently flip/flop to use IPv6 for resolution, then fail and drop the connection. Please read: https://github.com/abraunegg/onedrive/blob/master/docs/USAGE.md#ip_protocol_version
2. Force your client to only use HTTP/1.1 as the communication protocol as there is potentially some device between you and Microsoft OneDrive that is causing HTTP/2 instability. Please read: https://github.com/abraunegg/onedrive/blob/master/docs/USAGE.md#curl-compatibility

[adg7511]

Thanks a lot for your response. @abraunegg

[adg7511]

Hi @abraunegg

After we upgraded our 'curl' and onedrive version (v2.4.25), all onedrive instances are running fine except for one which still sometimes (every few hours) terminated unexpectedly.

We use this instance to download files from SharePoint and the workload of this instance is generally larger than other instances.

There are no extra information in debug log or debug-https log, but at system level, we found it was killed by 'Signal : 11 (SEGV)'

Do you have any clues about this problem?
Thanks.

[abraunegg]

@adg7511

workload of this instance is generally larger than other instances

Firstly, did you also configure to use HTTP 1.1 and force the use of IPv4 ?

Secondly, are you doing any process isolation | memory isolation to constrain the memory use of processes?

Thirdly, how are you running the instance - what this the applicable configuration and usage mode - --monitor or --sync ?

Lastly, do any of the other instances fail - or do they run without issue in a consistent manner?

Common causes for SIGSEGV are:

1. Accessing invalid memory addresses: This occurs if the process tries to read or write to a memory address that is not allocated for its use. This could be due to dereferencing a null or uninitialized pointer, or an address outside the process's address space. If you are process constraining the memory space this could be a cause.
2. Buffer overflow: Accessing an array or buffer beyond its bounds can lead to accessing illegal memory addresses. For example, writing data beyond the end of an array might overwrite other memory, leading to a segmentation fault when that overwritten memory is later accessed. If you are only seeing this on one instance ... it is unlikely that this is the cause.
3. Dereferencing freed memory: If a process dereferences a pointer that has already been freed, the contents of that memory location might have been returned to the system, causing an access violation if the process tries to read or write to that location. What memory garbage collection are you using on the system?
4. Stack overflow: If a program uses up more stack space than allocated (often due to deep or infinite recursion), it can cause a segmentation fault. This happens because it attempts to access memory reserved for other uses or which does not exist (outside the process's allowable memory range). Do you have any recursion going on locally?
5. Violating protection rights: Trying to modify memory that the operating system has marked as read-only or executing non-executable memory can also trigger a SIGSEGV. This leads back to the points above around memory isolation.

Things to consider

1. Perform an exhaustive system load & memory test - ensure your platform is free from problems. v2.4.25 has no known memory leak issue as tested & validated at release time with valgrind, whilst running through a number of scenarios, so right now it would be good to rule out actual environment memory and/or platform stability issues.
2. Core Dump Analysis. It would be interesting to use gdb on all of the core files to identify potentially where things are failing and/or looking at full log files for the process - is it failing at the same point each and every time, or, is it failing at random points (which points to point 1 above). Does this Sharepoint instance fail when it is the only instance running (again at random points)?
3. Indirect effects of low memory conditions can potentially lead to a situation where a SIGSEGV might occur
   • Resource Starvation: In a low-memory scenario, the system might start swapping heavily or fail to allocate memory requested by processes. If a process does not properly check the results of memory allocation functions (like malloc in C), and then attempts to use memory that was not successfully allocated, this could lead to a SIGSEGV.

To investigate whether memory pressure could be indirectly contributing to the SIGSEGV, you can monitor the system's memory usage closely using tools like top, vmstat, or dmesg. Look for logs related to OOM conditions or heavy swapping activity around the time of the crashes.

[adg7511]

Thanks again @abraunegg
We will continue to investigate based on the information you provide.