Backup Errors on Exit after Chromium install

[tclfan]

I am not sure if this belongs here or in TCE section:
On TCL 2.7 booted from usb: After installation of Chromium browser TC no longer shuts down or reboots with 'Backup'. When 'Backup' option is checked, it results in error message indicating errors and invalid backup device. USB stick is freshly configured with 'usbinstall' of TCL, to eliminate some corruption. If another browser is installed, but Chromium not installed then all seems fine - TCL 'backup' option on reboot or shutdown appears to work fine.
Now, although this problem appears to be related to Chromium, should this not be considered a TCL issue, not being able to back up on exit?
Anyone else experienced this? Is there any solution?

[Arslan S.]

what is the output of "filetool.sh backup" ?

[Arslan S.]

the problem might be ~/.config/chromium/SingletonLock and SingletonSocket
if so add them to your .xfiletool.lst

[tclfan]

Arslan, thank you for quick response. I will try this.

[jur]

the problem might be ~/.config/chromium/SingletonLock and SingletonSocket
if so add them to your .xfiletool.lst

I have trouble with SingletonSocket - and nothing worked. Does not work to have them listed in xfiletool.lst. My workaround is to manually delete these items with a script when I close Chromium just before shutdown. It means I can't perform a backup while chromium is still open.

[roberts]

Browsers are now putting sockets in user's home directories, ugh.

Another work around is to sed out the ignores in /tmp/backup_status in /usr/bin/filetool.sh at line 104

Code: [Select]

   [ -s /tmp/backup_status ] && sed -i '/socket ignored/d' /tmp/backup_status 2>/dev/null                                             
   [ -s /tmp/backup_status ] && exit 1   


[tclfan]

Sorry I have not had the time to test these workarounds yet...  After spending half a day yesterday cutting out various combinations of usb sticks trying to narrow down the problem, which appears to be specific to Chromium out of all browser extensions in repository. At first the error message indicates write error and invalid media, so trying different sticks, etc...
However, since it appears this issue may surfice with some other extensions: Is there any across the board solution possible so TC base operation of backup function would not be affected by specifics of extension? In principle, this is a system/data backup function, therefore extensions should not be able to impact this operation? If some data or configuration file is or is not backed up to the extension's liking, then it is up to the extension to work or malfinction in consequence. The base system operation, such as backup, should not be prevented from working.
In a word, the user programs should not be able to prevent base system from correct operation... Is this correct thinking in modular architecture?

[Jason W]

Tar ignores sockets, and creates a warning message in the process.  And Robert's workaround does work by removing ignored socket warning messages from the output file.  Since tar gives a 0 exit status even in the case of errors, testing for exit status does not work for tar so an output file is more appropriate.

There are other extensions like xine-xvesa that use sockets in the home directory, but those sockets are deleted once the app is closed.  Leaving a socket behind sounds like bad program behavior, though for chromium there may be a reason for it.  

This socket warning message is probably one of the few warnings/errors that can be safely ignored, so it could be easily filtered out in general, or added individually to .xfiletool.lst.

[tclfan]

Jason - thanks for explaining this phenomenon. My 'trying to be organized' testing yesteday confirms the above explanation as it appears backup actually executes. although the error message on backup error indicating invalid media could be confusing to those who do not know the actual cause...
Since the backup function is default exit mode and native part of TCL modus operandi, is there any way to make TCL more immune to such irregular behavior of extensions, perhaps other than testing the execution status code? This would enhance confidence in solid TC base operation in the face of future extensions doing some wild stuff like this...

[^thehatsrule^]

If you didn't see it, the above test uses -s (which is for stderr iirc)

[tclfan]

Yes, indeed. Thank you.