0
On my laptop running Arch, I have a bunch of git repositories cloned under ~/git. My problem is that from time to time (maybe once in a month or so), all the executable files inside the clones will lose their executable bit. It's not caused by git, because git ls-files --cached
shows the relevant files as having mode 100755, and git diff
shows output like this:
diff --git a/setup.py b/setup.py
old mode 100755
new mode 100644
Which is how I notice this is happening in the first place.
I've looked at a lot of things. These are the mount options for /home:
/dev/sda4 on /home type btrfs (rw,relatime,ssd,space_cache)
There are no suspect systemd timers; only logrotate, mandb, grpck, pwck and systemd-tmpfiles run daily. No cron jobs either. The systemd journal doesn't mention anything even remotely related to the problem, and I searched for permission strings, my user name, paths, and more.
My umask is 0022
, thus preventing newly created files from having the write bit set. None of the directories above the git repositories have the sticky bit set.
I'm at a loss, what can cause this? Or how can I find out what is causing this? Maybe hack something up with inotify
and lsof
? It's going to be hard to catch the offending process in the act, since it happens so infrequently.
This didn't seem to show much promise:
FN=git/testapp/setup.py ; inotifywait -m $FN | while read foo ; do date ; ls -l $FN ; lsof $FN ; done
--- wheninotifywait
sees the change, the offending process has already exited, and to change attributes there's no need to "open" the file anyway. – j0057 – 2014-12-31T15:33:05.820"ls -lc" should show time of last status change. Knowing when this happens might give a clue as to how it's happening. – Paul Haldane – 2014-12-31T15:33:40.123
Hey, that's strange.
ls -lc
shows the status change as being Apr 05 2014, which is a special date, because that's the day I installed Arch on my laptop, according to the systemd journal. – j0057 – 2014-12-31T15:36:40.837And all the files have that ctime, not just the files that should have been executable. – j0057 – 2014-12-31T15:37:36.467
1
OK - looks like "ls -lc" isn't going to help you (though I don't think I've ever seen it reporting installation/file system creation time. Two more thoughts ... 1. Does this only affect files in the git repos? 2. Systemtap (which I haven't used for ages) might be what you need. https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/SystemTap_Beginners_Guide/inodewatch2sect.html has what looks like a relevant example.
– Paul Haldane – 2014-12-31T15:56:30.177Thanks Paul, I'll definitely look into systemtap. I created an executable file outside of ~/git to see if that one is also affected. – j0057 – 2014-12-31T16:58:14.257