/etc/cont-init.d/10-init-users.sh: line 86: sed-patch: not found

[BigBen2003]

---English--- When starting the Doker container, the container is terminated with the error message:

/etc/cont-init.d/10-init-users.sh: line 86: sed-patch: not found

The container is started with the following command:

docker run -d --name=crashplan-pro --env-file /volume1/docker/crashplanPro/environ.env -p 5900:5900 -p 5800:5800 -v /volume1/docker/crashplanPro/config:/config: rw -v /volume1:/mnt/volume1:rw jlesage/crashplan-pro

Does anyone know how to get the container working again?

---Deutsch--- Beim Starten des Doker Containers wird der Container mit der Fehlermelung beendet:

/etc/cont-init.d/10-init-users.sh: line 86: sed-patch: not found

Der Container wird mit dem folgendem Befehl gestartet:

docker run -d --name=crashplan-pro --env-file /volume1/docker/crashplanPro/environ.env -p 5900:5900 -p 5800:5800 -v /volume1/docker/crashplanPro/config:/config:rw -v /volume1:/mnt/volume1:rw jlesage/crashplan-pro

Weiß jemand, wie der Container wieder zum Laufen gebracht werden kann?

[jlesage]

See #402 and #403.

[BigBen2003]

--English-- When posting #402, the solution given is to remove the ENV variables:

SUP_GROUP_IDS INSTALL_PACKAGES VNC_PASSWORD

These were with my container without a value. Even after removing this variable, the container does not start. Same error message as before:

/etc/cont-init.d/10-init-users.sh: line 86: sed-patch: not found

-- Deutsch-- Beim Posting von #402 wird als Lösung angegeben, die ENV-Variablen zu entfernen:

SUP_GROUP_IDS INSTALL_PACKAGES VNC_PASSWORD

Diese waren bei meinem Container ohne einen Wert. Auch nach dem Entfernen dieser -Variablen startet der Container nicht. Gleiche Fehlermeldung wie zuvor auch:

/etc/cont-init.d/10-init-users.sh: line 86: sed-patch: not found

[BigBen2003]

-- English --

The solution in posting #403 doesn't work in my case.

The image "jlesage/crashplan-pro:22.11.3" cannot be found on docker.io.

The following command was execPosti

$ docker pull jlesage/crashplan-pro:22.11.3 Error response from daemon: manifest for jlesage/crashplan-pro:22.11.3 not found: manifest unknown: manifest unknown

Other versions 22.11.1 to 22.11.31 are also not available. All commands return the same error message that the version does not exist.

-- Deutsch -- Die Lösung im Posting #403 funktioniert in meinem Fall nicht.

Das Image "jlesage/crashplan-pro:22.11.3" kann nicht auf docker.io gefunden werden.

Folgender Befehl wurde ausgeführt:

$ docker pull jlesage/crashplan-pro:22.11.3 Error response from daemon: manifest for jlesage/crashplan-pro:22.11.3 not found: manifest unknown: manifest unknown

Auch andere Versionen 22.11.1 bis 22.11.31 sind nicht vorhanden. Bei allen Befehlen wird die gleichlautende Fehlermeldung ausgegeben, dass die Version nicht vorhanden ist.

[jlesage]

The image tags you are using are not correct. You are missing the initial v before version number. See https://hub.docker.com/r/jlesage/crashplan-pro/tags for available tags.

But the solution is not to revert to a previous version. The solution is to remove some variables. If after removal you still see the problem, there is probably something wrong with the deployment of the container. You can run docker inspect <container name> to see which environment variables are set.

[BigBen2003]

-- English -- Many Thanks. I missed the letter "v". After the old image has been restored, CrashPlan runs again without errors.

I'm aware that it can't be a solution, just a workaround.

Now, however, the cause of the error can be searched for without stress.

-- Deutsch -- Vielen Dank. Den Buchstaben "v" habe ich übersehen. Nachdem das alte Image wieder hergestellt wurde, läuft CrashPlan wieder fehlerfrei durch.

Mir ist bewusst, dass es keine Lösung sein kann, sondern nur ein Workarround.

Nun kann jedoch ohne Stress nach der Fehlerursache gesucht werden.

[BigBen2003]

-- English --

I've noticed for a long time that Crashplan doesn't stick to the CRASHPLAN_MAX_CPU specification. Far more CPUs are almost always used.

CrashPlan does not stick to the specification CRASHPLAN_SRV_MAX_MEM either. It is mostly claimed around 20G. In the system itself, the main memory was therefore upgraded to 64G. The symantec-nas-system does not support more memory.

-- Deutsch -- Mir ist schon seit längerer Zeit aufgefallen, dass Crashplan sich nicht an die Angabe CRASHPLAN_MAX_CPU hält. Es werden fast immer weit mehr CPUs in Anspruch genommen.

An die Angabe CRASHPLAN_SRV_MAX_MEM hält sich CrashPlan ebensowenig. Es wird meistens so um die 20G beansprucht. Im System selbst wurde deswegen der Arbeitsspeicher auf 64G aufgerüstet. Mehr Arbeitsspeicher wird vom Symantec-NAS-System nicht unterstützt.

[jlesage]

Now, however, the cause of the error can be searched for without stress.

From my side the cause of the error is already known :) Note that the latest image now implements a workaround for this Synology issue.

I've noticed for a long time that Crashplan doesn't stick to the CRASHPLAN_MAX_CPU specification. Far more CPUs are almost always used.

The container doesn't support a such environment variable. Usually CPU limitation is not enforced by the container, but by the system during creation of the container.

CrashPlan does not stick to the specification CRASHPLAN_SRV_MAX_MEM either. It is mostly claimed around 20G. In the system itself, the main memory was therefore upgraded to 64G. The symantec-nas-system does not support more memory.

You set the variable to what value ? You can use docker inspect <container name> to verify if the variable is correctly set. Also, what is the size of your backup set ? To amount of memory used directly depends on it. If value of CRASHPLAN_SRV_MAX_MEM is too low, CrashPlan will simply crashes.