Log files not being written, video files not being copied

[cimryan]

Log files not being written, video files not being copied

[rtanaka]

sounds like the script make-root-fs-readonly.sh only partially ran or something happened during execution. you should take a look at the output from findmnt to see if the /tmp directories are writeable.

[skipfire]

The only things marked ro are
/
/boot
/sys/fs/cgroup (children are rw)

I also deleted both the archiveloop and the archive-teslacam-clips and both were restored after rebooting with the exact same old data with "Thu 3 Nov 17:17:10 UTC 2016" timestamps.

TARGET                           SOURCE         FSTYPE     OPTIONS
/                                /dev/mmcblk0p2 ext4       ro,noatime,data=ordered
├─/dev                           devtmpfs       devtmpfs   rw,relatime,size=217624k,nr_inodes=54406,mode=755
│ ├─/dev/shm                     tmpfs          tmpfs      rw,nosuid,nodev
│ ├─/dev/pts                     devpts         devpts     rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000
│ └─/dev/mqueue                  mqueue         mqueue     rw,relatime
├─/sys                           sysfs          sysfs      rw,nosuid,nodev,noexec,relatime
│ ├─/sys/fs/cgroup               tmpfs          tmpfs      ro,nosuid,nodev,noexec,mode=755
│ │ ├─/sys/fs/cgroup/systemd     cgroup         cgroup     rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/lib/syst

│ │ ├─/sys/fs/cgroup/freezer     cgroup         cgroup     rw,nosuid,nodev,noexec,relatime,freezer
│ │ ├─/sys/fs/cgroup/net_cls     cgroup         cgroup     rw,nosuid,nodev,noexec,relatime,net_cls
│ │ ├─/sys/fs/cgroup/devices     cgroup         cgroup     rw,nosuid,nodev,noexec,relatime,devices
│ │ ├─/sys/fs/cgroup/cpu,cpuacct cgroup         cgroup     rw,nosuid,nodev,noexec,relatime,cpu,cpuacct
│ │ └─/sys/fs/cgroup/blkio       cgroup         cgroup     rw,nosuid,nodev,noexec,relatime,blkio
│ ├─/sys/kernel/debug            debugfs        debugfs    rw,relatime
│ └─/sys/kernel/config           configfs       configfs   rw,relatime
├─/proc                          proc           proc       rw,relatime
│ └─/proc/sys/fs/binfmt_misc     systemd-1      autofs     rw,relatime,fd=34,pgrp=1,timeout=0,minproto=5,maxproto=5,dire

├─/run                           tmpfs          tmpfs      rw,nosuid,nodev,mode=755
│ ├─/run/lock                    tmpfs          tmpfs      rw,nosuid,nodev,noexec,relatime,size=5120k
│ ├─/run/rpc_pipefs              sunrpc         rpc_pipefs rw,relatime
│ └─/run/user/1000               tmpfs          tmpfs      rw,nosuid,nodev,relatime,size=44384k,mode=700,uid=1000,gid=10

├─/var/tmp                       tmpfs          tmpfs      rw,nosuid,nodev,relatime
├─/var/log                       tmpfs          tmpfs      rw,nosuid,nodev,relatime
├─/tmp                           tmpfs          tmpfs      rw,nosuid,nodev,relatime
├─/boot                          /dev/mmcblk0p1 vfat       ro,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=asci

├─/backingfiles                  /dev/mmcblk0p3 ext4       rw,noatime,data=ordered
└─/mnt/archive                   //192.168.251.16/teslacam
                                                cifs       rw,relatime,vers=3,cache=strict,[email protected],d

[cimryan]

Does the content in /tmp/archiveloop.log and /tmp/archive-teslacam-clips.log explain what you're seeing?

[skipfire]

No, it appears to be a default file and never changes. A fresh install has the same exact file content. I can delete the file, reboot, and the exact same content returns, timestamps and, fsk, etc.

archiveloop.log

Thu  3 Nov 17:17:03 UTC 2016
Starting...
Thu  3 Nov 17:17:03 UTC 2016
Ensuring music backing file is mounted...
Thu  3 Nov 17:17:04 UTC 2016
Mounting /mnt/music...
Thu  3 Nov 17:17:04 UTC 2016
Mounted /mnt/music.
Thu  3 Nov 17:17:04 UTC 2016
Ensured cam drive is mounted.
Thu  3 Nov 17:17:04 UTC 2016
Running fsck on /mnt/music...
fsck from util-linux 2.29.2
fsck.fat 4.1 (2017-01-24)
0x41: Dirty bit is set. Fs was not properly unmounted and some data may be corrupt.
 Automatically removing dirty bit.
Performing changes.
/backingfiles/music_disk.bin: 1 files, 1/1755644 clusters
Thu  3 Nov 17:17:07 UTC 2016
Finished fsck on /mnt/music.
Thu  3 Nov 17:17:07 UTC 2016
Unmounting /mnt/music...
Thu  3 Nov 17:17:09 UTC 2016
Unmounted /mnt/music.
Thu  3 Nov 17:17:09 UTC 2016
Archiving...
Thu  3 Nov 17:17:12 UTC 2016
Finished archiving.
Thu  3 Nov 17:17:12 UTC 2016
Waiting for archive to be unreachable...

[cimryan]

Try this

sudo -i
touch /tmp/archive_is_unreachable

Does the content in /tmp/archiveloop change?

Meanwhile, what does the content in /tmp/archive-teslacam-clips.log indicate?

[skipfire]

That did generate additional lines in the log.

Thu 25 Oct 23:52:09 UTC 2018
Simulating archive being unreachable.
Thu 25 Oct 23:52:09 UTC 2018
Waiting for archive to be reachable...
Thu 25 Oct 23:52:09 UTC 2018
Archive is reachable.
Thu 25 Oct 23:52:09 UTC 2018
Archiving...
Thu 25 Oct 23:52:11 UTC 2018
Finished archiving.
Thu 25 Oct 23:52:11 UTC 2018
Waiting for archive to be unreachable...

[skipfire]

After another reboot the file reset, somewhere in the process a file did finally appear on my share.

[cimryan]

The touch /tmp/archive_is_unreachable tricks the system into thinking that the Pi has driven away from the house. It then immediately detects that the archive server is reachable, and so decides to immediately attempt another archive.

But archiveloop initiates an archive when it starts up if the archive is reachable. And, indeed, the "Archiving..." and "Finished archiving." messages indicate that this occurred. So the question is, why didn't this archiving operation transfer any clips?

To answer that we'll need to see the content of /tmp/archive-teslacam-clips.log

[skipfire]

Unfortunately it appears the contents of the temp files reset on every reboot. The end of it is attached, but per the timestamps it is all old data now.

/backingfiles/cam_disk.bin: 28 files, 1794/1317699 clusters
Thu  3 Nov 17:17:11 UTC 2016
Finished fsck on /mnt/cam.
Thu  3 Nov 17:17:11 UTC 2016
Moving clips to archive...
Thu  3 Nov 17:17:11 UTC 2016
Moved 0 file(s).
Thu  3 Nov 17:17:11 UTC 2016
Finished moving clips to archive.
Thu  3 Nov 17:17:11 UTC 2016
Unmounting /mnt/cam...
Thu  3 Nov 17:17:12 UTC 2016
Unmounted /mnt/cam.
Thu  3 Nov 17:17:12 UTC 2016
Connecting usb to host...
Thu  3 Nov 17:17:12 UTC 2016
Connected usb to host.

[cimryan]

The timestamps are generated before the Pi has been able to update its clock from the network, after boot. Please reopen this issue if you experience the same problem, again.

[rtanaka]

@skipfire - as @cimryan mentioned it has to do with the clock sync. can you try adding back fake-hwclock? i was able to reproduce the issue and that made it go away for me:

apt-get install fake-hwclock

[skipfire]

That has helped with the time, though the contents still go away after a reboot so you can't find out what happened much later due to how you use a car. Get home, get out, close the door - power shuts off, check your server, no files or bad files, look at Pi - oops it has been rebooted.

[thijsdejong]

I have the exact same issue. When I plug in my rpi to my computer I can see the "USB" drive just fine and files are there, but when I look into /mnt/cam via ssh the folder is empty. Seems like the archive script also sees no files. How can I fix this?