• Home
  • Features
  • Pricing
  • Docs
  • Announcements
  • Sign In

pomerium / pomerium / 17474795591
52%

Build:
DEFAULT BRANCH: main
Ran 04 Sep 2025 07:43PM UTC
Jobs 1
Files 544
Run time 2min
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst

04 Sep 2025 07:36PM UTC coverage: 54.077% (-0.04%) from 54.119%
17474795591

push

github

web-flow
feat: handle signals to better gracefully drain/terminate envoy (#5818)

## Summary

Right now we explicitly do not handle OS signals in pomerium - this has
the side effect of not necessarily running shutdown phases of pomerium,
e.g. things that are supposed to run after a context is done, for
example `context.AfterFunc(ctx, ...)`.

It works mostly as expected right now since when container orchestration
frameworks like Kubernetes pass a SIGTERM to the process, any
sub-processes spawned with exec.Command will inherit those signals and
get sent SIGTERM as well, which according to the envoy docs will result
in draining listeners according to `--drain-time` which defaults to
600s.

However, right now the pomerium.Shutdown is a utility function
explicitly used by our test environment, our current pomerium.Wait
doesn't handle graceful shutdown correctly, it has been amended to:
- wait for envoy server to close (either successfully or unsuccessfully)
- return errors to the parent command if and only if the first error was
not surfaced via pomerium.Shutdown() or by one of the valid interrupt
signals. Not handling these errors means that systemd, will handle
graceful shutdown as well since it expects a zero return code on
successful shutdown, which the previous iteration did not have.


An unintended side effect of catching signals is the envoy server
gracePeriodSeconds on is always set to 0 (in non-test env settings) --
causing the envoy process to be SIGKILLED inadvertently by the old code.
This has been fixed by respecting the default `--drain-time`.

<hr/>
In addition, we make a best effort to post an explicit graceful drain
request to envoy during shutdown.

<hr/>

Some testing utilities I used to verify different termination sceanrios:
- `strace -p $(pidof pomerium) -e signal`
- `strace -p $(pidof envoy) -e signal`

should always receive SIGTERM/SIGINT and exit with status code 0. 

<hr/>

Ref:
-
https://www.envoyproxy.io/docs/envoy/latest/intro/arch_ov... (continued)

0 of 85 new or added lines in 5 files covered. (0.0%)

19 existing lines in 7 files now uncovered.

25952 of 47991 relevant lines covered (54.08%)

89.83 hits per line

Uncovered Changes

Lines Coverage ∆ File
61
2.98
-0.43% pkg/envoy/envoy.go
11
0.0
pkg/contextutil/signals.go
9
0.0
0.0% pkg/cmd/pomerium/pomerium.go
3
0.0
0.0% cmd/pomerium/main.go
1
0.0
0.0% internal/zero/cmd/run.go

Coverage Regressions

Lines Coverage ∆ File
4
70.71
-1.06% internal/autocert/manager.go
4
90.91
-3.64% pkg/fanout/receive.go
3
87.75
-1.47% config/config_source.go
3
2.98
-0.43% pkg/envoy/envoy.go
2
89.19
-5.41% pkg/fanout/fanout.go
2
96.88
-1.04% pkg/identity/manager/schedulers.go
1
75.41
0.0% pkg/storage/postgres/registry.go
Jobs
ID Job ID Ran Files Coverage
1 17474795591.1 04 Sep 2025 07:42PM UTC 544
54.08
GitHub Action Run
Source Files on build 17474795591
  • Tree
  • List 544
  • Changed 14
  • Source Changed 4
  • Coverage Changed 14
Coverage ∆ File Lines Relevant Covered Missed Hits/Line
  • Back to Repo
  • Github Actions Build #17474795591
  • 2fa4d6a8 on github
  • Prev Build on main (#17474052796)
  • Next Build on main (#17475248072)
STATUS · Troubleshooting · Open an Issue · Sales · Support · CAREERS · ENTERPRISE · START FREE · SCHEDULE DEMO
ANNOUNCEMENTS · TWITTER · TOS & SLA · Supported CI Services · What's a CI service? · Automated Testing

© 2026 Coveralls, Inc