Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Kitchen] Problems with testing CentOS #137

Open
myii opened this issue Mar 31, 2020 · 1 comment
Open

[Kitchen] Problems with testing CentOS #137

myii opened this issue Mar 31, 2020 · 1 comment

Comments

@myii
Copy link
Member

myii commented Mar 31, 2020

Made some attempts to get the CentOS testing working again but ran into a number of hurdles.

centos-6

This was actually working as-is a few months back for version: '4.4:

The zabbix-server-mysql package is no longer available in the repo:

The highest version that still has it available is 2.4 (this isn't really useful, though):

centos-7 & centos-8

Essentially, these are failing due to issues between docker and systemd. The main error that reoccurs:

New main PID does not belong to service, and PID file is not owned by root. Refusing.

Research:

Potential solutions

  1. Check if we're in a container and then run the service manually instead, using a check similar to:
    1. refactor(ng/init.sls): use grains.get to detect containers ntp-formula#45
  2. Use Vagrant boxes instead:
    1. Biggest issue here is that this will only be local testing, which is always difficult to work with.
@an0nz
Copy link

an0nz commented Jan 28, 2021

For my own kitchen tests I got around this issue thanks to this issue apache/bigtop#640
If you mount cgroups in as a volume to your test container services can run as non-root users.
eg: /sys/fs/cgroup:/sys/fs/cgroup:ro

For Kitchen I used the following as I only test for OS's where this is needed but the same driver_config can be set in the platforms definition if you need it on specific images.

suites:
  - name: build
    driver_config:
      volume: 
        - /sys/fs/cgroup:/sys/fs/cgroup:ro

I do not use this formula so haven't tested to see if it fixes the problem just thought it might be relevant as I came across this bug while hunting for something to fix the same issue in my own salt repos.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants