You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@nuttx.apache.org by GitBox <gi...@apache.org> on 2021/04/09 13:43:27 UTC
[GitHub] [incubator-nuttx] fjpanag opened a new pull request #3498: syslog_device: Device is re-opened in case of failure.
fjpanag opened a new pull request #3498:
URL: https://github.com/apache/incubator-nuttx/pull/3498
## Summary
Syslog_device has logic to open the device in a later time, in case initialization fails.
However, after this initial opening, no further checks were done. The state `SYSLOG_FAILURE` was not actually used anywhere.
If the device was opened successfully, but there was a problem occurring at a later time, during actual logging, the driver was not able to detect this. There was no way to recover from this state, and the user couldn't know of the failure.
Eventually all subsequent logging is lost.
The changes in this PR properly set the driver state in `SYSLOG_FAILURE` when any fault occurs.
At a later point, the device will be properly closed, and marked again as `SYSLOG_REOPEN`. So the initialization process can be executed again, and have the channel recover from the problem.
*Note!* This change is not intended to handle logs on removable media. It should not be used to open and close the file as e.g. an SD card is inserted and removed. The proper (and much more efficient) way to do this, would be to call `syslog_channel()` and `syslog_channel_remove()` every time the medium is mounted/unmounted.
This is mostly intended as an error handling mechanism.
## Impact
Syslog_device's can now recover from any problems during logging.
## Testing
Incomplete, I will un-draft the PR when testing is complete.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] v01d commented on pull request #3498: syslog_device: Device is re-opened in case of failure.
Posted by GitBox <gi...@apache.org>.
v01d commented on pull request #3498:
URL: https://github.com/apache/incubator-nuttx/pull/3498#issuecomment-816765885
@fjpanag so if not for SD removal what is the other failure scenario that this would handle?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] xiaoxiang781216 merged pull request #3498: syslog_device: Device is re-opened in case of failure.
Posted by GitBox <gi...@apache.org>.
xiaoxiang781216 merged pull request #3498:
URL: https://github.com/apache/incubator-nuttx/pull/3498
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] v01d commented on pull request #3498: syslog_device: Device is re-opened in case of failure.
Posted by GitBox <gi...@apache.org>.
v01d commented on pull request #3498:
URL: https://github.com/apache/incubator-nuttx/pull/3498#issuecomment-817136184
> > @fjpanag so if not for SD removal what is the other failure scenario that this would handle?
>
> The initial "inspiration" for this PR, was that the driver should not just swallow any errors, or die silently. It shall take care of itself.
>
> Of course, it will work perfectly in the SD card scenario. In fact, this is how I tested it. It can be used for this purpose, but it would be quite inefficient, compared to properly adding/removing the channel.
>
> I mentioned you since the work on adding/removing dynamically syslog channels is not finished. Thus, for the moment this is a necessary evil for log files in removable media.
>
> Apart for that, I can image it being useful in:
>
> * Temporary errors, e.g. an out of memory condition that the system can recover at a later time.
>
> * Errors handled elsewhere, e.g. a file system error, that some logic elsewhere handled by unmounting/remounting the SD, and is not aware of the logger to also remove and then add again.
>
> * Low-level / electrical errors, especially on "dump" drivers. E.g. an external (non-removable) memory, without an FS, that directly stores raw log files.
Thanks, I was just curious.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] fjpanag commented on pull request #3498: syslog_device: Device is re-opened in case of failure.
Posted by GitBox <gi...@apache.org>.
fjpanag commented on pull request #3498:
URL: https://github.com/apache/incubator-nuttx/pull/3498#issuecomment-817110630
> @fjpanag so if not for SD removal what is the other failure scenario that this would handle?
The initial "inspiration" for this PR, was that the driver should not just swallow any errors, or die silently. It shall take care of itself.
Of course, it will work perfectly in the SD card scenario. In fact, this is how I tested it. It can be used for this purpose, but it would be quite inefficient, compared to properly adding/removing the channel.
I mentioned you since the work on adding/removing dynamically syslog channels is not finished. Thus, for the moment this is a necessary evil for log files in removable media.
Apart for that, I can image it being useful in:
* Temporary errors, e.g. an out of memory condition that the system can recover at a later time.
* Errors handled elsewhere, e.g. a file system error, that some logic elsewhere handled by unmounting/remounting the SD, and is not aware of the logger to also remove and then add again.
* Low-level / electrical errors, especially on "dump" drivers. E.g. an external (non-removable) memory, without an FS, that directly stores raw log files.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] fjpanag commented on pull request #3498: syslog_device: Device is re-opened in case of failure.
Posted by GitBox <gi...@apache.org>.
fjpanag commented on pull request #3498:
URL: https://github.com/apache/incubator-nuttx/pull/3498#issuecomment-816692317
@v01d This may be of interest to you.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] fjpanag commented on pull request #3498: syslog_device: Device is re-opened in case of failure.
Posted by GitBox <gi...@apache.org>.
fjpanag commented on pull request #3498:
URL: https://github.com/apache/incubator-nuttx/pull/3498#issuecomment-817110804
Tested on an STM32F746G-DISCO, storing the log file in an external SD.
The driver properly detects the error, and re-opens the file when it is available.
On my side, this can be merged.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org