Is there a workaround for a git repository under /etc?

I did some research and found out that there is no good way to avoid etckeeper commit "daily autocommit" exiting with status code other than zero if there is a git repository under the /etc hierarchy? This causes the /etc/cron.daily/etckeeper to send an e-mail every day with body "run-parts: /etc/cron.daily/etckeeper exited with return code 1."

I've attempted to add the repo as git submodule in /etc/.gitmodules and tried to add "-path ./myrepo -prune -o" to the NOVCS in /etc/etckeeper/pre-commit.d/30store-metadata but neither of these fixed the issue.

If I have a git repo in /etc/myrepo:

# etckeeper commit "daily autocommit"
On branch master
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
  (commit or discard the untracked or modified content in submodules)
    modified:   myrepo (untracked content)

no changes added to commit (use "git add" and/or "git commit -a")
# echo $?
1

RSS Atom

comment 1

What are you trying to achieve here? I'm not sure what your goal is from the question. Would you rather…

Have etckeeper ignore the /etc/myrepo directory entirely
Have etckeeper automatically commit changes to /etc/myrepo as a submodule, then automatically commit submodule changes to the /etc repository
Have etckeeper not run daily commits at all
Something else…

If you just want to disable the non-zero exit status, you can change /etc/etckeeper/commit.d/50vcs-commit to suppress the exit status. To do that, change the following lines:

        if [ -n "$logfile" ]; then
                git $GIT_GC_OPTIONS commit $GIT_COMMIT_OPTIONS -F "$logfile"
        else
                git $GIT_GC_OPTIONS commit $GIT_COMMIT_OPTIONS
        fi

        if [ -n "$logfile" ]; then
                git $GIT_GC_OPTIONS commit $GIT_COMMIT_OPTIONS -F "$logfile" || :
        else
                git $GIT_GC_OPTIONS commit $GIT_COMMIT_OPTIONS || :
        fi

But all that will do is prevent any errors from being reported, which I suspect isn't what you're after! All etckeeper commit is doing is running the scripts in /etc/etckeeper/commit, though, so you should be able to change it to do whatever you want just by editing those scripts.

Comment by me_and — Thu Feb 23 13:27:23 2023

Remove comment

Comment 2

Hi! And thanks for the tip. I think I am okay with the first and second option (ignore the dir completely or have as submodule) you provided. And I would indeed like to know about any other error messages, I do not wish to ignore them completely.

Comment by pulk — Tue Feb 28 11:41:37 2023

Remove comment

comment 3

In that case, I'd recommend just having the directory ignored:

sudo sed -i 1i/myrepo /etc/.gitignore

Comment by me_and — Thu Mar 2 20:46:48 2023

Remove comment

comment 4

Unfortunately that does not work. I tried all these in /etc/.gitignore:

 myrepo
 myrepo/*
 /myrepo
 /myrepo/*

But I still get the error each time.

Comment by pulk — Thu Mar 16 14:18:17 2023

Remove comment

comment 5

Your repo has already been added as a submodule. That's why git commit is complaining about it.

If you put it in /etc/.gitignore before etckeeper commit, it will be ignored from the beginning.

At this point you will need to remove the submodule as well as ignoring it.

I was a little surprised to see etckeeper adding git repos within /etc as submodules, but it turns out that git add --all or git add . do add submodules that way.

Comment by joey — Fri Apr 21 16:02:43 2023

Remove comment

comment 6

Thanks! That solved the issue. I did not remember that I had previously attempted to add it as submodule to workaround the issue.

Comment by pulk — Tue Apr 25 05:43:57 2023

Remove comment

Add a comment