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 2.0.2.0 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?
Thanks,
The snap version is settable via a partâs scriptlet, refer the adopt-info
key for more info.
Also refer: Selective-checkout: Check out the tagged release revision if it isn't promoted to the stable channel
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.
OK.
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 home
and removable-media
interfaces, though?
Data outside of the snap-specific dirs (i.e. $SNAP_DATA
, $SNAP_COMMON
, $SNAP_USER_DATA
, and $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.
I guess snap set system snapshots.automatic.retention=100y
might work, but a forever
value instead of <duration>
or 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[6787]: 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[6787]: config file:/etc/taos/taos.cfg not
found, all variables are set to default
2020-09-09T03:00:05Z tdengine.tdengine[6787]: failed to open log
file:/var/log/taos/taosdlog.0, reason:No such file or directory
2020-09-09T03:00:05Z tdengine.tdengine[6787]: failed to init log file
2020-09-09T03:00:06Z systemd[1]: snap.tdengine.tdengine.service holdoff time
over, scheduling restart.
2020-09-09T03:00:06Z systemd[1]: Stopped Service for snap application
tdengine.tdengine.
2020-09-09T03:00:06Z systemd[1]: start request repeated too quickly for
snap.tdengine.tdengine.service
2020-09-09T03:00:06Z systemd[1]: Failed to start Service for snap application
tdengine.tdengine.
2020-09-09T03:00:06Z systemd[1]: Unit snap.tdengine.tdengine.service entered
failed state.
2020-09-09T03:00:06Z systemd[1]: 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:
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
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 âŠ
like:
#! /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?
Thanks, Shuduo
Hi @shuduo,
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.
Thanks!
OK. I think phase one is completed. I donât need personal-files and system-files for now. Please close the request. Thanks.