3.2b1 Duet 3 (DCS is not started)



  • @chrishamm said in 3.2b1 Duet 3 (DCS is not started):

    /usr/lib/systemd/system/duetcontrolserver.service

    Thank you! That fixed it.


  • administrators

    @Dougal1957 Sure thing, run

    sudo curl https://pkg.duet3d.com/duetcontrolserver.service -o /usr/lib/systemd/system/duetcontrolserver.service
    sudo systemctl daemon-reload
    


  • Fixed now thanks (one of the guys in a discord I am in suggested how I could edit it with NANO Thanks Luke



  • Do you know why this isn't working?

    pi@duet3:~$ sudo /opt/dsf/bin/DuetWebServer
    crit: Microsoft.AspNetCore.Server.Kestrel[0]
    Unable to start Kestrel.
    System.IO.IOException: Failed to bind to address http://[::]:80: address already in use.
    ---> Microsoft.AspNetCore.Connections.AddressInUseException: Address already in use
    ---> System.Net.Sockets.SocketException (98): Address already in use
    at System.Net.Sockets.Socket.UpdateStatusAfterSocketErrorAndThrowException(SocketError error, String callerName)
    at System.Net.Sockets.Socket.DoBind(EndPoint endPointSnapshot, SocketAddress socketAddress)
    at System.Net.Sockets.Socket.Bind(EndPoint localEP)
    at Microsoft.AspNetCore.Server.Kestrel.Transport.Sockets.SocketConnectionListener.Bind()
    --- End of inner exception stack trace ---
    at Microsoft.AspNetCore.Server.Kestrel.Transport.Sockets.SocketConnectionListener.Bind()
    at Microsoft.AspNetCore.Server.Kestrel.Transport.Sockets.SocketTransportFactory.BindAsync(EndPoint endpoint, CancellationToken cancellationToken)
    at Microsoft.AspNetCore.Server.Kestrel.Core.KestrelServer.<>c__DisplayClass21_01.<<StartAsync>g__OnBind|0>d.MoveNext() --- End of stack trace from previous location where exception was thrown --- at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.AddressBinder.BindEndpointAsync(ListenOptions endpoint, AddressBindContext context) --- End of inner exception stack trace --- at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.AddressBinder.BindEndpointAsync(ListenOptions endpoint, AddressBindContext context) at Microsoft.AspNetCore.Server.Kestrel.Core.ListenOptions.BindAsync(AddressBindContext context) at Microsoft.AspNetCore.Server.Kestrel.Core.AnyIPListenOptions.BindAsync(AddressBindContext context) at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.AddressBinder.EndpointsStrategy.BindAsync(AddressBindContext context) at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.AddressBinder.BindAsync(IServerAddressesFeature addresses, KestrelServerOptions serverOptions, ILogger logger, Func2 createBinding)
    at Microsoft.AspNetCore.Server.Kestrel.Core.KestrelServer.StartAsync[TContext](IHttpApplication1 application, CancellationToken cancellationToken) Unhandled exception. System.IO.IOException: Failed to bind to address http://[::]:80: address already in use. ---> Microsoft.AspNetCore.Connections.AddressInUseException: Address already in use ---> System.Net.Sockets.SocketException (98): Address already in use at System.Net.Sockets.Socket.UpdateStatusAfterSocketErrorAndThrowException(SocketError error, String callerName) at System.Net.Sockets.Socket.DoBind(EndPoint endPointSnapshot, SocketAddress socketAddress) at System.Net.Sockets.Socket.Bind(EndPoint localEP) at Microsoft.AspNetCore.Server.Kestrel.Transport.Sockets.SocketConnectionListener.Bind() --- End of inner exception stack trace --- at Microsoft.AspNetCore.Server.Kestrel.Transport.Sockets.SocketConnectionListener.Bind() at Microsoft.AspNetCore.Server.Kestrel.Transport.Sockets.SocketTransportFactory.BindAsync(EndPoint endpoint, CancellationToken cancellationToken) at Microsoft.AspNetCore.Server.Kestrel.Core.KestrelServer.<>c__DisplayClass21_01.<<StartAsync>g__OnBind|0>d.MoveNext()
    --- End of stack trace from previous location where exception was thrown ---
    at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.AddressBinder.BindEndpointAsync(ListenOptions endpoint, AddressBindContext context)
    --- End of inner exception stack trace ---
    at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.AddressBinder.BindEndpointAsync(ListenOptions endpoint, AddressBindContext context)
    at Microsoft.AspNetCore.Server.Kestrel.Core.ListenOptions.BindAsync(AddressBindContext context)
    at Microsoft.AspNetCore.Server.Kestrel.Core.AnyIPListenOptions.BindAsync(AddressBindContext context)
    at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.AddressBinder.EndpointsStrategy.BindAsync(AddressBindContext context)
    at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.AddressBinder.BindAsync(IServerAddressesFeature addresses, KestrelServerOptions serverOptions, ILogger logger, Func2 createBinding) at Microsoft.AspNetCore.Server.Kestrel.Core.KestrelServer.StartAsync[TContext](IHttpApplication1 application, CancellationToken cancellationToken)
    at Microsoft.AspNetCore.Hosting.GenericWebHostService.StartAsync(CancellationToken cancellationToken)
    at Microsoft.Extensions.Hosting.Internal.Host.StartAsync(CancellationToken cancellationToken)
    at Microsoft.Extensions.Hosting.HostingAbstractionsHostExtensions.RunAsync(IHost host, CancellationToken token)
    at Microsoft.Extensions.Hosting.HostingAbstractionsHostExtensions.RunAsync(IHost host, CancellationToken token)
    at Microsoft.Extensions.Hosting.HostingAbstractionsHostExtensions.Run(IHost host)
    at DuetWebServer.Program.Main(String[] args) in /home/christian/Duet3D/DuetSoftwareFramework/src/DuetWebServer/Program.cs:line 24
    Aborted
    pi@duet3:~$


  • administrators

    @bcrazycramer It looks like there is another web server running on the same port (80). Do you have Apache or another HTTP server installed on your system? If not, try rebooting the Pi and check if that makes a difference.

    PS: DWS will usually run in the background as its own service, so there should be no need to start it manually. Follow my last reply describing the usage of journalctl to figure out why DCS/DWS isn't started.



  • I get the same after rebooting.

    I'm not using the Raspberry Pi for anything else except the Duet 3. I do have VNC enabled and SSH.


  • administrators

    @bcrazycramer Please see my earlier post where I mention journalctl.

    [edit]Sorry, linking posts doesn't seem to work too well[/edit]



  • @bcrazycramer I get the same as well not that I have a clue what it means!



  • fdd68c9f-5749-4f06-abd3-5f1bf7c3413b-image.png



  • @chrishamm said in 3.2b1 Duet 3 (DCS is not started):

    @bcrazycramer Please see my earlier post.

    Which part?



  • @bcrazycramer it was to me asking me to run the journal cads to see what was happening!



  • 2293ef33-61e6-4768-8fa0-50e60461f90e-image.png


  • administrators

    @bcrazycramer That's looking good. You should be able to connect to your board over HTTP.

    The GitHub releases and package feeds have been updated with the latest hotfixes as promised. If you're having problems, consider running another software update.



  • @chrishamm said in 3.2b1 Duet 3 (DCS is not started):

    I suspect there may be a permission issue going on because we changed from root to a dedicate dsf user in the latest pre-release.

    Can you explain the thinking behind changing from root to a dsf user?

    As to be honest if it was working before, this seems to be a prime example of changes being made for the sake of it for diminishing returns.

    As my old journeyman used to say : if it's working fuc*ing leave it alone.


  • Moderator

    @CaLviNx Running things as root is generally frowned upon for security sake.



  • @Phaedrux that I understand but in this instance it should be fine as people "should" have their home network secured.

    My printers all connected via my own wireless "intranet" that is not connected to the outside world, so no one can get into that small network, house innternet itself is run through a Secure DDWRT equipped router which is well locked down, and I'm not the most IT tech savvy but I'm I am happy to run my printers in "Root" mode.

    So to find yet another thing changed for the sake of change just trips things/people up as this instance proven


  • Moderator

    @CaLviNx said in 3.2b1 Duet 3 (DCS is not started):

    "should" have their home network secured.

    Defence in depth would urge you to not assume any favorable circumstances exist.



  • @Phaedrux and to counter that why should people not be allowed to choose for themselves and a notification in the docs would suffice?


  • administrators

    Given the huge number of hacking attempts made against everyone these days, we would rightly be castigated if we continued running DSF as root. This is even more important now that DSF supports plugins.


  • administrators

    @CaLviNx said in 3.2b1 Duet 3 (DCS is not started):

    @Phaedrux and to counter that why should people not be allowed to choose for themselves and a notification in the docs would suffice?

    If you want to run DSF as root, you can modify DSF - it's open source. If you don't know how to, then IMO you shouldn't be trusted to run DSF as root. I don't want your RPi running DSF to be part of a botnet.



  • @CaLviNx said in 3.2b1 Duet 3 (DCS is not started):

    @Phaedrux and to counter that why should people not be allowed to choose for themselves and a notification in the docs would suffice?

    because secure by default solves more problems than it can create? (ref OpenBSD it won't stop you from pulling down your pants, even though it ships with belts and suspenders)



  • @dc42 said in 3.2b1 Duet 3 (DCS is not started):

    [...] I don't want your RPi running DSF to be part of a botnet.

    Wait... is that, like, discouraged or something? 😁 😁



  • So these replies bring me to ask the next question.

    If running in "root" is as dangerous as YOU GUYS are pushing it to be, why was this not implemented from the get go ?

    For it to be as dangerous as is being said and for it to only be being implemented now many many months after the Rpi image was released shows recklessness and a lack of care for users in the extreme....


  • Moderator

    It's a best practice. I'm sorry it wasn't implemented initially and I'm sorry implementing it now has inconvenienced you. Your point about change for change sake is taken.



  • @Phaedrux

    So it has just been proven that best practice has not been followed, but im the one getting preached at from multiple directions for even mentioning it...

    On one hand being lectured about how important security is.

    Then after its pointed out about the delay the importance of said security gets glossed over as "not best practise"

    hypocrisy much.........


Log in to reply