Proposal: Logs rotation for DueControlServer and DuetWebServer

fragrama17

@oliof NLog is already being configured for ConsoleTarget, I think it's way easier to just add another target (FileTarget for rotation) in the source code (this way it will work on every os), instead of using something like logrotate that is specific to linux machines

fragrama17

@chrishamm would it be possible to add at least the thread-name/id in the pattern layout for debug purposes ?
using something like the following:

"${longdate} [thread-${threadname:whenEmpty=${threadid}}] ${uppercase:${level}} - ${message}"

I am aware that DSF is based on LinuxAPI (especially for SPI and GPIO tasks) but, since .NET is cross-platform, I think it's best practice to configure a proper logger for DCS and DWS that will work potentially on every platform supported by .NET; this way we won't need to worry about logs rotation anymore.

There's a library provided by Microsoft https://github.com/dotnet/iot that provides abstractions for any sort of GPIO driver (I2C, SPI, PWM ecc..) using System call APIs based on where we run the programs (Linux or Windows); this way DSF could be potentially extended to other platforms

oliof

Seeing how the RRF team is already stretched to support the current user base, I really don't want to think about effectively inviting support for other OSes on DSF and the intricate bugs and support questions that would invite.

SBC mode already uses linux specific things for other things like proper secure separation of plugins etc. So its not just about adding .net native logrotation and a mukti platform gpio library that will have its own set of bugs, dependencies, and idiosyncrasies.

In the end it's RRF team's call of course (-:

chrishamm

@fragrama17 If you need that kind of logging for debugging support, you can always change it in the source code. I currently don't see the benefit in making it configurable for everyone via the settings. DSF has been successfully tested on RedHat-based distros and other nVidia Tegra-based boards, but making it available on other non-Linux based platforms isn't planned at this point. Since it's open-source, everyone with some coding knowledge could probably have a look at that, though.

I used to use the .NET IOT library but I found it too unreliable and in particular the GPIO interface was way too slow. That may have changed, but before I decide to use that library again, the reliability and speed compared to the current solution need to be assessed again. I've logged this request at https://github.com/Duet3D/DuetSoftwareFramework/issues/208

PS: I've been considering to add support for plugins that are loaded as assemblies (DLLs) but so far there's been no need for it. At some point I want to restructure DCS to run as a hosted application but that isn't super urgent. Perhaps I will implement that as part of v3.7 or v3.8 and when that's done it should be relatively easy to implement "native" plugins, too. At that point, you could reconfigure NLog as you like without having to rebuild DCS completely.

chrishamm created this issue in Duet3D/DuetSoftwareFramework

open Assess .NET IOT library again for usage with DCS #208

chrishamm

@oliof said in Proposal: Logs rotation for DueControlServer and DuetWebServer:

SBC mode already uses linux specific things for other things like proper secure separation of plugins etc.

That's true, but you can turn off the AppArmor requirement in the DSF settings if you really want to. Some Linux distros with different kernel configurations don't support AppArmor.

fragrama17

@chrishamm @oliof
sorry guys if I went too far and kind of changed the main subject of this conversation, going from logging functionalities to os cross-compatibility.

I still firmly think that, at least for logging, DCS and DWS should have a file logs rotation properly configured (via NLog for DCS and maybe via NLog/log4net for DWS).

The possibility for the user to configure the rotation via M-code by extending M929 could be a handy feature; but it doesn't have to be that way, we could just configure it via config.json and/or http.json.

The dotnet platform provides really good abstractions for multiple purposes (logging could be one of them), and deciding to not take advantage of these is like deciding to kind of re-inventing the wheel.

infiniteloop

@fragrama17

The dotnet platform provides really good abstractions for multiple purposes

Same does Linux, which nowadays has become the gold standard for server applications, even at Cupertino and Redmond.

deciding to not take advantage of these is like deciding to kind of re-inventing the wheel.

Micro$oft has ”re-invented” numerous wheels, mostly to keep its dominant position, not for the good intent. Strictly taken, logging mechanisms have been covered to an exhaust by Unix ages ago, so why should I use .Net just because they bolted a fifth wheel to the M$ waggon?

fragrama17

@infiniteloop
seems like you guys don't really like Microsoft ecosystem;

then what is the purpose of using dotnet in DSF ?

there are so many programming languages and runtime environments platform independent with GPIO libraries included (nodejs, python, jdk, rust and many more).

Also, the NLog library is a non-profit project, microsoft only provides the runtime and the file system abstraction.

infiniteloop

@fragrama17

seems like you guys don't really like Microsoft ecosystem

I’m not ”you guys”: as a simple 3D printing individual, I just speak for myself. TBH, in a strict sense, I’m not even a Linux guy, I prefer Macs. But on this forum, that doesn’t matter: I’m here as a longtime DUET user, convinced of Duet3D’s Open Source policy as well as of their approach to hard- and software integration. When the Duet team introduced their SBC solution, using Linux on this was the obvious choice.

I didn’t want to hurt your feelings - not even your pro-Micro$oft ones . Instead, I propagate a more 'agnostic' view: Instead of engaging in long-lost battles in the OS wars, go with the least common denominator. That’s what Duet3D has rightly done.

fragrama17

@infiniteloop did you read the code snippet I wrote in the first message ?

I am also providing an 'agnostic' view;
the best advantage of the approach that I suggested in the first code snippet is that is platform independent (it will work everywhere) and NLog is already being configured for ColoredConsoleTarget anyway (see Settings.cs line 413 in DCS).

I didn’t want to hurt your feelings - not even your pro-Micro$oft ones

Mate, you're hurting nobody, but please do not move the subject elsewhere, nobody is engaging any war.

I love linux and all the amazing contributions the communities behind are adding to the kernel and the distros.

Phaedrux

No need for this to have a pro or anti microsoft angle to this discussion.