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.
j0057
Posted 2014-12-31T15:23:38.883
Reputation: 101
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--- wheninotifywaitsees 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 -lcshows 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