Thanks for the feedback and suggestion. I'm fairly certain (haven't actually tried though) that adding iscsi-disk.mount or even iscsi.target to the "After=" of the MySQL service would probably solve this problem I don't think it's a good solution.
Just to start, I don't think the MySQL package includes anything about the remote-fs.target at all. This particular MySQL instance/unit file was home grown to include that since it's known it will be running on the iSCSI disk. The reason I don't feel like adding iscsi-disk.mount is a good solution is because that is a dynamically generated file made by systemd when it looks at fstab. That means if I choose to change my mount point from /iscsi-disk to /foo-bar for example having iscsi.mount as an "After=" will no longer work. As for adding iscsi.service as an "After=", I also feel like that is inadequate. What if the underlying storage becomes NFS instead of iSCSI? The whole point of the special systemd remote-fs.target is to handle this and ordering properly yet clearly something isn't right here. While adding these new orderings to the MySQL unit file will help make MySQL less upset it doesn't change the fact that it appears that /iscsi-disk is being unmounted after iscsi.service is stopped which can cause all sorts of file system problems. Again, I appreciate the attempt at a solution but there is something else wrong here that needs a more concrete fix. -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/open-iscsi. For more options, visit https://groups.google.com/d/optout.
