Convox Community

BUG: --no-sync not respected in Gen2

Hi there,

When starting an app on a local gen2 rack, I get the following error:

ERROR: dial tcp: lookup api.convox.svc.cluster.local: too many open files

this is the same as this error: ERROR: dial tcp: lookup api.convox.svc.cluster.local: too many open files
when trying to access some of the services, I get a simple response of EOF, like here:
Convox API in K8S Rack crashes

The error dial tcp: too many open files issue also happens later on when doing various commands like convox ps, etc.

Looking at the code for the convox start command in the old-gen CLI, you can see that the flag Sync (which comes from --no-sync) is not used at all:

	for _, s := range m.Services {
		if !services[s.Name] {
			continue
		}

		if s.Build.Path != "" {
			go opts.watchChanges(ctx, pw, m, s.Name, wd, errch)
		}
	}

The only thing that is considered is whether the build path is defined or not (i.e. and image is used directly).

Now I know that the gen2 racks are not the main focus of Convox nowadays, but this sort of thing causes major issues working with a local rack (we’ll upgrade to gen3 at the end of the year).

I was hoping it can be fixed and a new CLI released - it seems like a minor things to handle.

@Brian-G What do you think? Could this be handled?

It might also be an issue with the Rack itself, I guess?

All that is certain is that the --no-sync is ignored… running convox start --no-sync I get:

convox          | starting sync from srvc1 to /opt/app on srvc1-api
convox          | starting sync from srvc2/requirements.locked.txt to /home/someapp on srvc2
convox          | starting sync from srvc2/src to /home/someapp on srvc2
convox          | starting sync from srvc2/common/requirements.locked.txt to /home/someapp on srvc2
convox          | starting sync from srvc3/src to /home/someapp on srvc3-queue
convox          | starting sync from srvc3/requirements.txt to /home/someapp on srvc3-queue

Also tagging @ed_convox, as I see he did most of the latest commits in convox/rack, so hopefully could correct this easily…

I created a PR, that hopefully fill fix it: