Commit Graph

3 Commits

Author SHA1 Message Date
Andres Suarez
fbdb46f5cb Tidy up license headers
Reviewed By: chadaustin

Differential Revision: D17872966

fbshipit-source-id: cd60a364a2146f0dadbeca693b1d4a5d7c97ff63
2019-10-11 05:28:23 -07:00
Adam Simpkins
9bfb48c921 update license headers in .py files
Summary:
Update the copyright & license headers in Python files to reflect the
relicensing to GPLv2

Reviewed By: wez

Differential Revision: D15487088

fbshipit-source-id: 9f2138dff41048d2c35f15e09a04ae5a9c9c80dd
2019-06-19 17:02:46 -07:00
Matt Glazar
6e360e1015 Isolate systemd service cgroups on Sandcastle
Summary:
systemd uses cgroups to contain a service's processes.

When EdenFS' tests run systemd on Sandcastle, the systemd process creates its cgroups as children of Sandcastle's cgroup. For example, the test-SystemdServiceTest.service service created in test_running_simple_service_is_active has the following cgroup on Sandcastle:

  /sandcastle-job/command/test-SystemdServiceTest.service

Unfortunately, systemd uses predictable cgroup names based on the service name. A service managed by one systemd instance shares the same cgroup as a same-named service managed by a different systemd instance. For example, if multiple systemd tests run concurrently on Sandcastle (e.g. during stress-testing), `systemctl --user stop foo.service` from one run will kill the processes of a different run's active foo.service. This causes systemd tests to be flaky on Sandcastle.

Fix the conflict by creating a unique cgroup per systemd instance. For example, separate runs of test_running_simple_service_is_active might use the following cgroups for the test service:

  /sandcastle-job/command/edenfs_test.1_qat2xv/test-SystemdServiceTest.service
  /sandcastle-job/command/edenfs_test.bbd3gj_o/test-SystemdServiceTest.service

Reviewed By: simpkins

Differential Revision: D13016626

fbshipit-source-id: 8535dc14a06bdb403c926b111cad4aed6c8ec3e3
2018-11-28 11:47:44 -08:00