kubernetes: Job Failed StartTime is 1970?

What happened?

I wrote a deliberately failing Job. It should cause a StartError.

The problem is that the container start time is reported as ‘1970-01-01T00:00:00Z’ whereas the finishedAt time is correct.

{
  'terminated': {
    'exitCode': 128,
    'reason': 'StartError',
    'message': 'failed to create containerd task: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: exec: "sleepx": executable file not found in $PATH: unknown',
    'startedAt': '1970-01-01T00:00:00Z',
    'finishedAt': '2023-09-01T01:58:59Z',
    'containerID': 'containerd://b9833afeb22eac8639dd1a8890279525b14d25faefd0b690fe1b32e79aee8f9f'
  }
}

What did you expect to happen?

The correct startedAt time is given. Since k8s clearly knows when “now” is, is it really logical to have a start time almost 50 years ago?

How can we reproduce it (as minimally and precisely as possible)?

apiVersion: batch/v1
kind: Job
metadata:
  name: job1e
  namespace: default
  annotations:
    tracepusher/collector: "http://localhost:4318"
spec:
  backoffLimit: 0
  template:
    spec:
      containers:
      - image: alpine:latest
        command: 
          - "sleeps"
        args:
          - "1"
        imagePullPolicy: IfNotPresent
        name: first

Then kubectl get pods -l job-name=job1e

Anything else we need to know?

No response

Kubernetes version

$ kubectl version
Client Version: v1.26.3
Kustomize Version: v4.5.7
Server Version: v1.25.3

Cloud provider

OS version

# On Linux:
$ cat /etc/os-release
# paste output here
$ uname -a
# paste output here

# On Windows:
C:\> wmic os get Caption, Version, BuildNumber, OSArchitecture
# paste output here

Install tools

Container runtime (CRI) and version (if applicable)

Related plugins (CNI, CSI, …) and versions (if applicable)

About this issue

  • Original URL
  • State: open
  • Created 10 months ago
  • Comments: 19 (18 by maintainers)

Most upvoted comments

Thank you! So can you reproduce with other controllers? Or just a pod?

seems to me that this would not be related to job controller at all.

/sig node

Yes, this is a pod issue and is not related to the job. When a pod is in a ‘startError’ state, this happens. It seems that in this state, the ‘startedAt’ of the pod is not assigned. I am looking into this issue. image

apiVersion: v1
kind: Pod
metadata:
  name: hello
spec:
  containers:
  - command:
    - xxx
    - -c
    - echo "Hello"
    image: busybox
    name: hello
  restartPolicy: Never

you can reproduce the issue with this pod yml