I suppose publishing a new revision should do?
I will update the package version to align with the classic package (even including Windows version) release in the future.
Current 220.127.116.11 is aligned with the latest stable version of the classic release. Appreciated it if it can be approved manually.
One more question, My snap will release new version with classic package release accordingly. So should I modify snapcraft.yaml every time then commit to git repo? Or to compose a small script to modify version string before run snapcraft. Can I specify snap version by command line argument?
The snap version is settable via a part’s scriptlet, refer the
adopt-info key for more info.
Disclaimer: Own product, use with your discretion.
Understood. Thanks @Lin-Buo-Ren
Another question, how to transfer the snap, especially snap name to another account? I uploaded the tdengine snap to store and display my launchpad name as publisher. I need transfer it to another account with my employer’s company name as publisher and make its name verified with a checked emoji.
Refer The store-requests category in the Snapcraft Forum for such matter.
For the “verified” check mark, I believe it is only granted to the (very) high-profile snaps, maybe the @store folks can help.
New question, as when the user remove a snap, the data files will be removed too. But as a database software, most scenario should keep data files untile the user manually delete them. How I can implement this with snap?
When your snap is removed, a snapshot of its data is created that will be retained for a month:
If a user reinstalled your snap in that time, then the data will be restored with it. It is possible to omit some data from the snapshot through the
remove hook, as described here.
There isn’t currently a way for a snap to have data in snap specific system wide dirs persist in place after removal though.
Is it possible for a snap service to access a user’s data path via
removable-media interfaces, though?
Data outside of the snap-specific dirs (i.e.
$SNAP_USER_COMMON) won’t be touched on snap removal.
A hook won’t be able to access data in individual users’ home directories though, unless it has
read: all set on its
home interface plug (which will trigger manual review on the store).
It is possible to retain a snap’s data forever?
As the document I linked states, manually created snapshots are retained until they are discarded. It also explains how you can control the life cycle of automatic snapshots via the
snapshots.automatic.retention configuration variable (either disabling their creation entirely, or changing how long they are retained).
I did skimmed through the referring document, however I would really like to see permanent retention for the automatic snapshots, even when it need to be opted-in manually.
snap set system snapshots.automatic.retention=100y might work, but a
forever value instead of
off might also be appreciated.
I tried to save/restore it on a centos system. but seems not all data be saved then restored data makes the server fails to start now.
$ sudo snap logs tdengine [sudo] password for shuduo: 2020-09-09T03:00:05Z tdengine.tdengine: 09/09 11:00:05.921277 0x7f70e8f1d3c0 DND Failed to start TDengine, please check the log at:/var/log/taos 2020-09-09T03:00:05Z tdengine.tdengine: config file:/etc/taos/taos.cfg not found, all variables are set to default 2020-09-09T03:00:05Z tdengine.tdengine: failed to open log file:/var/log/taos/taosdlog.0, reason:No such file or directory 2020-09-09T03:00:05Z tdengine.tdengine: failed to init log file 2020-09-09T03:00:06Z systemd: snap.tdengine.tdengine.service holdoff time over, scheduling restart. 2020-09-09T03:00:06Z systemd: Stopped Service for snap application tdengine.tdengine. 2020-09-09T03:00:06Z systemd: start request repeated too quickly for snap.tdengine.tdengine.service 2020-09-09T03:00:06Z systemd: Failed to start Service for snap application tdengine.tdengine. 2020-09-09T03:00:06Z systemd: Unit snap.tdengine.tdengine.service entered failed state. 2020-09-09T03:00:06Z systemd: snap.tdengine.tdengine.service failed.
There are three kinds of data be used by the tdengine daemon. 1, /var/snap/tdengine/current/etc/taos/taos.cfg; 2. /var/snap/tdengine/current/var/log/taos/taosdlog.0; 3. /var/snap/tdengine/current/var/lib/taos/.
They are managed to be layout:
Not sure if any trick needed to handle it.
i guess your app tries to write to the dir but the dir structure does not exist yet … you likely want to create an install hook or a
command-chain: script that calls mkdir -p for $SNAP_DATA/var/lib/taos, $SNAP_DATA/var/log/taos and $SNAP_DATA/etc/taos …
#! /bin/sh [ -d "$SNAP_DATA/var/log/taos" ] || mkdir -p $SNAP_DATA/var/log/taos [ -d "$SNAP_DATA/var/lib/taos" ] || mkdir -p $SNAP_DATA/var/lib/taos [ -d "$SNAP_DATA/etc/taos" ] || mkdir -p $SNAP_DATA/etc/taos
… and if the cfg file needs to be there before first start, you maybe also want to copy it into $SNAP_DATA/etc/taos from that script …
I already use install hook can layout section to handle it. It works for normal install.
$ cat snap/hooks/install #!/bin/sh if [ ! -d /var/lib/taos ]; then mkdir -p /var/lib/taos fi if [ ! -d /var/log/taos ]; then mkdir -p --mode=777 /var/log/taos else chmod 777 /var/log/taos fi if [ ! -d /etc/taos ]; then mkdir -p /etc/taos fi if [ ! -f /etc/taos/taos.cfg ]; then if [ ! -d /etc/taos ]; then mkdir -p /etc/taos fi cp $SNAP/etc/taos/taos.cfg /etc/taos/taos.cfg fi $ tail -8 snap/snapcraft.yaml layout: /var/lib/taos: bind: $SNAP_DATA/var/lib/taos /var/log/taos: bind: $SNAP_DATA/var/log/taos /etc/taos: bind: $SNAP_DATA/etc/taos
Before I restore my snapshot, the daemon can start as usual. After I restore the snapshot, I see the files be saved to the directories it should be and I checked the md5 is same as original. But the daemon failed to read its cfg file and can’t write to the log file.
I start a new thread for transfer ownership of tdengine to my employer account. Seems no one takes care of it. Could you please let me know if it will be processed?
I can see @roadmr has already answered your transfer ownership request. Can you please add the other account as a collaborator as he suggested so we can move forward with your request?
Also, are you still experiencing issues with your snap? Were you able to solve your install hook/snapshot issue? I see you mentioned you do not need personal-files nor system-files anymore and your last revision https://dashboard.snapcraft.io/snaps/tdengine/revisions/7/ is successfully published. If that’s the case we can remove this request from our queue.
OK. I think phase one is completed. I don’t need personal-files and system-files for now. Please close the request. Thanks.