apache/beam · info

not supported on platform

Error message

not supported on platform

What it means

syscallx.ErrUnsupported is the sentinel error returned by syscallx helpers (hook, PhysicalMemorySize, FreeDiskSpace, SetProcessMemoryCeiling) when the underlying operation is not available on the current platform. Callers are expected to compare with errors.Is / == against this sentinel and degrade gracefully instead of failing. It signals 'unsupported', not 'failed'.

Solutions

  1. Compare the result against syscallx.ErrUnsupported and ignore it: `if err := syscallx.SetProcessMemoryCeiling(m, m); err != nil && !errors.Is(err, syscallx.ErrUnsupported) { log }`.
  2. If the memory ceiling matters for your job, run on a platform where the syscall is implemented (Linux) or use container-level memory limits (docker/cgroup) instead.
  3. Check that the correct syscall_*.go build-tag file is being compiled for your GOOS/GOARCH; a missing implementation file funnels everything to syscall_default.go.
  4. Treat the message as informational: it is not a pipeline failure; the harness continues without the limit.

Example fix

// before
if err := syscallx.SetProcessMemoryCeiling(memLimit, memLimit); err != nil {
    return err // fails on unsupported platforms
}

// after
if err := syscallx.SetProcessMemoryCeiling(memLimit, memLimit); err != nil && !errors.Is(err, syscallx.ErrUnsupported) {
    return err // real failures only
}
Defensive patterns

Strategy: fallback

Try / catch

if err := syscallx.SetProcessMemoryCeiling(m, m); err != nil && !errors.Is(err, syscallx.ErrUnsupported) {
    return fmt.Errorf("setting memory ceiling: %w", err)
}
// ErrUnsupported: continue with container/cgroup limits instead

Prevention

When it happens

Trigger: Calling any syscallx function on a platform lacking the corresponding syscall — e.g. SetProcessMemoryCeiling or PhysicalMemorySize on a platform using syscall_default.go, which unconditionally returns ErrUnsupported.

Common situations: Running Beam Go workers on unsupported OS/arch combinations (e.g. non-Linux containers, darwin, windows) where the harness init tries to apply a memory rlimit from the --memory_limit flag; disk-space probing on filesystems that don't report statfs data.

Understand the failure class

Background: "unsupported platform" / "not supported on this platform" errors: what they mean and how to fix them — this error's family across 47 libraries.

Related errors


AI-assisted analysis of apache/beam@12126d8942 (2026-09-13). Data as JSON: /api/errors/6da3b0e654793fec. Report an issue: GitHub.

Appendix: source

Thrown at sdks/go/pkg/beam/util/syscallx/syscall.go:27

//
// Unless required by applicable law or agreed to in writing, software
// distributed under the License is distributed on an "AS IS" BASIS,
// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
// See the License for the specific language governing permissions and
// limitations under the License.

// Package syscallx provides system call utilities that attempt to hide platform
// differences. Operations return ErrUnsupported if not implemented on the
// given platform. Consumers of this package should generally treat that
// error specially.
package syscallx

import (
	"github.com/apache/beam/sdks/v2/go/pkg/beam/internal/errors"
)

// ErrUnsupported is the error returned for unsupported operations.
var ErrUnsupported = errors.New("not supported on platform")

View on GitHub (pinned to 12126d8942)