coreos / coreos/go-systemd

Cannot Start or Stop Units anymore, when nothing reads from the job completion channel

Open
#429 4 comments 2 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Go
Stars
2.7k
Forks
338
PR merge metrics
No merged PRs in 30d

Description

https://github.com/coreos/go-systemd/blob/d843340ab4bd3815fda02e648f9b09ae2dc722a7/dbus/methods.go#L48
The jobHandler used e.g. by Conn.StartUnitContext blocks for ever if nothing reads from the provided channel.
I think this write to the result channel should be non-blocking, like this:

	c.jobListener.Lock()
	out, ok := c.jobListener.jobs[job]
	if ok {
		select {
		case out <- result:
		default:
			fmt.Println("failed to write result to job channel")
		}
		delete(c.jobListener.jobs, job)
	}
	c.jobListener.Unlock()

I'm not sure, what is the best way to log something or if it's even necessary,

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Read dbus/methods.go at the jobHandler code around line 48, then trace how Conn.StartUnitContext uses the provided job completion channel. Reproduce the hang with no reader on that channel. Done means the call no longer blocks forever when the result channel is unread, with the handling of a dropped result made explicit.

Written by the indexing model from the issue text.

Assessment

Tech stack
go
Domain
operating-systems
Issue type
Bug
Difficulty
3/5
Estimated time
1-2 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
38/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.