Request for classic confinement for TDengine snap


I would like to request classic confinement for theTDengine snap.

TDengine is an open-source big data platform designed and optimized for Internet of Things (IoT), Connected Vehicles, and Industrial IoT. Besides the 10x faster time-series database, it provides caching, stream computing, message queuing and other functionalities to reduce the complexity and costs of development and operations.

Please find the yaml file from

TDengine’s core is a performance-critical engine for time-series data storage. It need access classic filesystem to store TB level data even more with very fast write and query performance. And it allow user to manually edit /etc/taos/taos.conf to adjust parameters for better fit with system configurations like CPU cores, hard disk type, hard disk capabilities to squazze more performance. And use can edit multi-machines’s configuraiton to add end points to build a cluster.

Right now classic mode works great at my local computer. Please let me know your comments.


Are there specific road blocks you ran into with strict confinement? As far as system wide configuration, you can store that in the $SNAP_DATA or $SNAP_COMMON. You can even hard code the paths those expand to if you don’t want to look up the environment variables at runtime.

If your server is primarily accessed via network sockets, then I would have thought strict confinement would be a fairly good fit.

1 Like

Classic confinement is only a last resort, to get it granted you need to explain exactly why stict confinement did not work for you in the first place.

Looking at your code (launchers, hooks and snapcraft.yaml) you could solve all file location problems with some added layouts (having the target dirs point to locations underneath the variables james gave above) and properly defined plugs.

Also note that Ubuntu Core which is used a lot in IoT, automotive, industrial and embedded computing will not allow you to install classic confined snaps.

Try adding some layouts to re-map /etc/taos, /var/lib/taos and /var/log/taos, then turn the snap to strict confinement and use snappy-debug to get suggestions for the required plugs.
If you run into probs, post the snappy-debug output of an app run here along with your questions.


Hi jamesh and ogra,

I would be very happy if the strict mode can satisfy the following requirements for TDengine.

  1. TDengine need read /etc/taos/taos.conf with some preset configuration values. a default /etc/taos/taos.conf should be installed by snap installation if not exist. If a previous version exists, installation should not overwrite it. I tried the strict mode. seems my install hook to create file does not work.
  2. Users can manually edit config file to adjust the preset value to tune better performance. I tried the strict mode. seems editing /var/snap/tdengine/current/etc/taos/taos.conf to change data location does not work.
  3. user can specify data location to different hard disk for better performance not only the disk /var/snap belong.
  4. the client we call taos became tdengine.taos with snap format. that’s fine we can tell the user the difference. the client will record the command history in a file named .taos_history in the user’s home. Next time users can use up/down to find the previous command list. With strict mode, it does not work. I guess it should be doable with strict mode. Maybe I misused home plugs. Appreciate it if someone can tell me how to fix it.
  5. the client need to write log to /var/log/taos. Now it reports permission denied. I guess it’s similar to 4, I don’t know how to write plug to do it correctly. And the log storage location should be able to move to other disks for performance reasons like 3.
  6. I am not sure if snap connect command can be done by install hook or another way. it’s nice if it can be done automatically by snap install. Then I don’t need to tell the user to do it manually. However, it’s not unacceptable although it does hurt user experience.


Are there any compile options or command line arguments you can use to change the location it looks for configuration files and writes log files?

As I said previously, snapd makes the locations $SNAP_DATA and $SNAP_COMMON available for snaps to write system wide configuration data. In this case, they would expand to /var/snap/tdengine/current and /var/snap/tdengine/common if you need to hard code paths in your app.

As far as changing the location where data is stored, one option would be to suggest users bind mount the alternative location they want data stored in.

Currently TDengine just use “-c path” to pass the directory where taos.cfg is.There are many configurable items in the taos.cfg for the purpose tune performance according to different CPU cores, memory size and also many options for different debug level for troubleshooting. To support them via passing too many command line argument seems less maintainable. We need provide more flexibility to the user. And keep the user using intuitive way to do that as what they used to do with classic Linux.


If you can set the configuration file location via an argument, then you could presumably set it as part of the command line for the daemon in your snapcraft.yaml.

Alternatively, if the configuration file needs to exist prior to the daemon running, you could launch the daemon via a shell script that copies a default configuration from your snap’s read-only data in $SNAP to a writable location in $SNAP_DATA, then launch the daemon with that configuration file.

1 Like

i’m struggling to make my snap work well with confine mode.

I have three executable app commands. First one is a simple daemon. Seems it works now. The last one is a simple command with network plug now it is workable. The second one is a client need write log to /var/logs directory but it failed to open log file as permission denied. and it need to write a file
at user’s home directory. It failed too although I specified home plug in its section of snapcraft.yaml. Could someone please help to point me what’s wrong?
The snapcraft.yaml is here:

@Lin-Buo-Ren thanks for your help. personal-files did resolve one of my problems. Now I can access ~/.taos_history after run snap connect.

1 Like

Now the review-tools reports following:

$ review-tools.snap-review tdengine_2.0.2.0_amd64.snap

  • declaration-snap-v2:plugs_installation:historyfile:personal-files
    human review required due to ‘allow-installation’ constraint (bool)
  • declaration-snap-v2:plugs_installation:systemfiles:system-files
    human review required due to ‘allow-installation’ constraint (bool)

  • security-snap-v2:interface-reference:historyfile:personal-files
    override not found for ‘plugs/historyfile’. Use of the personal-files interface is reserved for vetted publishers. If your snap legitimately requires this access, please make a request in the forum using the ‘store-requests’ category (, or if you would prefer to keep this private, the ‘sensitive’ category.
  • security-snap-v2:interface-reference:systemfiles:system-files
    override not found for ‘plugs/systemfiles’. Use of the system-files interface is reserved for vetted publishers. If your snap legitimately requires this access, please make a request in the forum using the ‘store-requests’ category (, or if you would prefer to keep this private, the ‘sensitive’ category.
    tdengine_2.0.2.0_amd64.snap: FAIL

As we discussed in recent two weeks, I believe I have explained why using system-files and personal-files make sense to this software. Please let me know what I should do. Thanks.

@jamesh @ogra Could you please help view


@shuduo thanks - we can use this existing forum discussion to continue the review process - can you please state what access is being requested for tdengine via personal-files and system-files and why this is required?


TDengine is a big-data platform and its core is a time-series database. There are a taosd server(daemon) and a client app, taos as primary parts and a few utility apps as additional parts.

The daemon and the client app need read configuration items from /etc/taos. The daemon need read/write all the data to /var/lib/taos (configurable in /etc/taos/taos.cfg). The daemon and the client app need write all the log to /var/log/taos (configurable in /etc/taos/taos.cfg). Those access request a system-files interface.

And the client need read/write a file named .taos_history in the user’s home directory for record and reuse command sequence as many databases software shell interface provides. This access requests a personal-files interface.


did you add layout entries for all these three yet ? (like i said above) did that not work ?

I assume the requester is asking to make the snap actually writing to the directories on the host’s rootfs instead of those accessible in the snap runtime?

In this case the answer is probably “snaps are designed not to write files to the classic system directories, just like you normally won’t make a docker container write logs to the host’s /var/log”.

My 2 cents.

EDIT: Backup my reply at #9 just so it wont be wrongly marked as the thread’s solution:

well, i’m just trying to point out that there is no actual requirement at all to write to these, using a layout is enough and you do not even need to request any review since this is the standard way to make apps like this “just work” without needing manual reviews or any changes to the app in any way … the same goes for the personal-files request , $HOME by default points to $HOME/snap/<snapname>/current/ for all snaps by default. the app has full write access there … unless you need/want to read any existing hosts files for migration purposes, none of the requested interfaces is needed when the packaging is done right …

1 Like

OK, I rechecked my snapcraft.yaml and removed all system-files interface related lines. It does work well too as you described.

Now the client still failed to access $HOME/.taos_history after I removed the personal-files interface. I see the original mechanism is to get home directory by “getpwuid(getuid())->pw_dir”, I think it did not get $HOME/snap/ directory. May I know if you would suggest what function should be used here to make both classic and snap to read right location?


1 Like

@Lin-Buo-Ren I do expect the snap can access other locations for data store requires to utilize faster disk or slower disk. Jamesh had suggested to allow users bind mount other locations in earlier reply. I plan to do it later. The first step is to publish the snap with all normal behavior works.

1 Like

Refer The homeishome launcher: Fix snapped apps that (wrongly) referring to the user's real home directory instead of $HOME for a possible workaround.

(Disclaimer: Just released, use at your own discretion.)

Thanks. I already replace getpwuid() with getenv(“HOME”). Now no need personal-files interface also.

I got the review tool reports pass.

$ review-tools.snap-review tdengine_2.0.2.0_amd64.snap
tdengine_2.0.2.0_amd64.snap: pass

I made a mistake to reject the new revision then clicked manual review again. I don’t know how to make it “without needing manual reviews” as ogra pointed out. Please help to process it or let me know what I need to do.

Thanks @jamesh @ogra @Lin-Buo-Ren @alexmurray a lot for your kind help.

1 Like