Peertube restarting over and over

[nebulon]

I think you went down the wrong path here. Unless the app is run in debug mode, it will always run /app/code/start.sh as the entry point. So any customization has to be done in /app/data/production.yaml for which we have to see if the kind of customization is even possible.

To take a step back, maybe you can describe what you would like to have changed and then we can see what is the best avenue to achieve that and if it is even possible.

[jdaviescoates]

@nebulon sounds like @ChristopherMag just wants to disable outbound email:

@christophermag said in Peertube restarting over and over:

When I initially installed peertube I had outbound email configured.
Due to a compliance issue I now have outbound email explicitly disabled so that no apps can send email external to the server.
I don't know if I restarted peertube since making that change so this issue may have been one waiting to show up the first time it restarted after having outbound email disabled.

[nebulon]

Ah true got it. Well the package is currently built in a way where the start.sh will always overwrite the settings, since secrets may or may not be rotated on the server side or port numbers change after first installation (While is is not done currently, we still have all packages done in a way they can be changed)

I don't really see an easy way to essentially "unconfigure" those without making the app error everytime it wants to send out a transactional email.

Ideally there would be some suppported "never send out emails" configure option, but this may be quite the edge-case. Maybe you can try to set the transport to either null or sendmail and see if the app still works?

[ChristopherMag]

@nebulon based on the current design I think the cleanest way to handle this is to change the behavior of Cloudron to be that when Outbound Email Relay configuration for a domain is set to disabled the smtp daemon referenced in the app containers via the environment variable CLOUDRON_MAIL_SMTP_SERVER continues to accept mail from applications and then deletes/routes all mail it receives to /dev/null (how to accomplish this would be dependent on the smtp daemon used).

This would allow individual apps not to have to have configuration changes based on whether email is enabled or not.

The other maybe more correct but difficult option is to change the state visible to the app container if Email Relay is set to disabled. This could be by no longer setting the various SMTP related environment variables so that the start.sh scripts can check for the presence of the variables before trying to use their values in configuration files.

The app state change option requires that each app's start.sh has to account for this configuration possibility and then change the app's configuration based on that whereas the first option allows all apps configuration to remain consistent independent of whether Email Relay is disabled or not.

[girish]

@christophermag Did I understand correctly that the issue is that peertube crashes if the SMTP server rejects the connection ? If so, I think I can make a patch for peertube upstream. Seems normal for SMTP servers to up/down, so an app should be able to cope with this anyways.

[ChristopherMag]

@girish Good thinking, yes that appears to be the behavior, if the smtp server rejects the connection the app refuses to start.

[girish]

@christophermag thanks, I can reproduce this easily.

[girish]

@christophermag I have opened an issue upstream and make a PR as well - https://github.com/Chocobozzz/PeerTube/issues/3457 and https://github.com/Chocobozzz/PeerTube/pull/3458

[girish]

@christophermag Change was merged, should be in next release of peertube.

[ChristopherMag]

@girish That is amazing, thank you!