prevent /etc/init.d/zfs-import from running with systemd #3839
Conversation
#3837 For systems with systemd in sysv init compatibility mode you have to prevent that services in /etc/init.d will be executed if there is a equivalent in systemd. There is zfs-import without a corresponding systemd service.
#3837 For systems with systemd in sysv init compatibility mode you have to prevent that services in /etc/init.d will be executed if there is a equivalent in systemd. There is zfs-import without a corresponding systemd service.
|
The description of the issue is misleading at best. IF I have understand your problem correctly (and I'm not sure I have), once Instead, any missing This leads to (and I have yet to verify that this can actually happen - I have been unable to reproduce the problem) the already existing scripts As I've said in the pkg-zfs issue, I can't rule out user error or a Debian GNU/Linux tool issue. I've been supplying both SYSV init scripts and |
|
I am not technically against this PR, it makes sense and looks good to me. HOWEVER, I'm afraid that it can/might shield us from the real issue. |
|
@dajhorn How are you doing in your Ubuntu packages? Are you supplying both SYSV and |
|
This is my old Jessie host, which was running version This is what I see after the upgrade: So in TWO cases, I don't see this problem: In the PS. The |
@FransUrbo In 0.6.4 there was no zfs-import: So how could systemd start zfs-import?
Nobody will have a real problem because zpool import is run twice. Please run on your system:
That's what I wanted to know. I didn't found *.service in Ubuntu package.
This file exists since Mai. |
The PPA installs the systemd units that are currently bundled with ZoL, but as an overlay component instead of a source component so that debhelper will manage them. (NB: zfsonlinux/pkg-zfs#145)
No, sysv is retired and unsupported. Existing The packages for Ubuntu currently support systemd and upstart, which themselves are mutually exclusive startup modes on recent Ubuntu releases.
Not as reported by @ggzengel, if only because anything sysv is already twice deprecated on the Ubuntu platform. |
|
Ok, thanx @dajhorn. The plot thickens though: So it seems I have this issue to, but I looked very carefully when it booted, and I could not see the import run twice. I'll see if I can log it... |
|
@FransUrbo :-) |
|
Ah, ok thanx. That explains a lot :). So NOT a user error, or Debian GNU/Linux tool problem :D I've been reading up on Unless @behlendorf consider this [PR] a good thing to do generically, the correct way (at least in Debian GNU/Linux) would be to disable the I have yet to actually test that in the package, BUT running that command in the shell gives this after a reboot: While I was at it, I also ran @ggzengel what do you think? |
|
So you have to decide on package install which init system is actually used, this is like deleting or not installing this file.
To disable (and mask) or enable services is an user decision to configure the system. It's nothing to always prevent services from running. |
|
That's my point. I put it in the Since I install both SYSV and systemd scripts on the same system, the Debian GNU/Linux tools takes care of everything. If you look at Correcting the section to: will make sure that it's only done if |
|
But user can enable it but shouldn't. With my solution it doesn't matter if it's enabled. It doesn't run. I think my solution works with most distributions and package maintainers have less complexity and less work. |
|
If the mask is run once at install time, it doesn't matter if the system is using SYSV or systemd when run. The link (and all the files for both ways) is still there. So once a change from SYSV to systemd is done, that dummy file (link) is there and it won't ever auto generate… I'm not absolutly convinced that this is something we (ZFS On Linux) should deal with. For me, it's more of a packaging thing. And installing both in a package is the correct way to do it. It will guarantee that things will work smoothly no matter which startup system one uses. Or migrates to/from... And I'm not creating two ADDITIONAL packages with only four or five files in them! It's to many packages as it is! Having to keep track of installing, deinstalling or reinstalling specific packages when (if!) going back and forth between them is way to much work… People WILL forget about that. So no, no additional packages. This needs to be done automatic. It's either your way, making it global for everyone (whether it's needed or not), or my way. Let's wait and see what @behlendorf thinks about this. I'm not opposed to your way, I'm just not convinced ZoL should deal with this… I can't do it the Ubuntu way either, because SYSV isn't deprecated in Debian GNU/Linux. Yet! And lets pray to every deity ever thought up that it never will! |
|
Which systemctl? |
|
Is that on a systemd enabled system? |
|
With the help from "ansgar" on #debian-devel, a better solution is to ship a zfs-import.service -> /dev/null symlink in /lib/systemd/system. |
No, it wasn't a systemd enabled system. But upgrade to jessie will be run after zfsutils.postinst if zfsutils are not upgraded. So it didn't mask in this special case. I think it should always match. That's what I said before on zfsonlinux/pkg-zfs#172 (comment): Use a dummy for zfs-import.service. I didn't think about a link to /dev/null, but that's it. But how to put it to the repository that every maintainer will understand this? |
|
Ok, fair enough. I think (thought) about "dummy file" differently… First we need to figure out if this occur on every distribution. Debian GNU/Linux have a bunch of extra patches to the systemd sources that might be the source of this. Let's stop here and get some more input… We now have several ways to solving this, so let's hear what everyone else is saying... |
So lets do it for everyone, even if there is only one more distribution or somebody installs plain ZFS from repository. It has no side-effect. |
That's the thing. Anyone installing from source will NOT have this problem, because the configure script will recognize if this is a SYSV or systemd system and ONLY install the relevant parts. Which is why I'm not sure doing it (either create a dummy Also, Gentoo for example don't use systemd at all (the only positive site of that distribution :D, neither does many others so they won't have this problem either. And for those distribution packages that only installs the relevant parts depending on how/where it's installed on won't need this either… There are many reason to consider this a packaging/distribution problem and not that many to consider it a ZoL responsibility... PS. As dajhorn said earlier, the Ubuntu packages don't have this problem because he's not installing the SYSV scripts (because SYSV is deprecated in Ubuntu). |
|
Masking out zfs-import.service and relying on the current EDIT: See #3836 |
|
Was there agreement in this issue about what the right fix for this is? |
|
No. We have three (I think it was) ways of solving this. They're all good. The primary/first question we need to decide is if this is a ZoL issue or a packaging/downstream issue… I've voted for the latter... |
|
Where is @FransUrbo? I can't see his posts nor account.
Number 3 is the solution which is used on debian: Now there a 3 options to realize:
|
|
GitHub thought I was a robot there for a while. Should be fixed now. When you put it like that, the only way forward (which is the one I've used in my latest As for your other three options (where to put it), I've said my opinion and I stand by it. ZoL should provide, as much as possible, a uniform environment. Which is the reason why we provide SYSV scripts, |
|
@FransUrbo So you say point 2: The maintainers have to create the soft link. |
|
What should I do with this issue? |
|
Leave it open for now and see what @behlendorf have to say about it. He's the one with the final say on it. |
|
@SpComb Exporting the pool at shutdown is incorrect. The import associates the pool with the system to say that it should persistantly appear on every boot. The export disassociates it so that does not happen anymore. The systemd zfs-import-cache.service unit file correctly calls |
|
It is worth mentioning that I tried exporting pools at shutdown in Gentoo in 2012 and abandoned it after finding that it caused far more problems than it solved: |
|
It's worth mentioning that not exporting a pool during shutdown may cause GRUB to not be able to read it. For root pools this can result in a system which doesn't boot. I'm not sure if this issue still exists in the very latest GRUB but it certainly exists in the version of GRUB shipped by many distributions. |
Yeah, I'm not sure if exporting is correct or not - but it's inconsistent with what the existing |
Yes, but according to @ryao, this is wrong to. I, and apparently @behlendorf, consider the issues he's seeing a problem with the zfs/zpool commands, not necessarily with the boot/shutdown process. We might need to hold of a shutdown/stop/export option until we've (well, they :) have decided if this is correct behavior or not. |
|
I'd say that exporting the pool on shutdown ends up exposing long standing deficiencies in other parts of the tool chain. Therefore we should avoid doing so until such time as those issues are addressed. These issues are a good example of the mixing of pool configuration and state information I was alluding to in #3800. With that in mind I've merged 33df62d which prevents the export. But that's an entirely different issue than the one describe here where both the systemd and sysv scripts are installed. From my point of view this is a decision which needs to be handled by the end distribution maintainers. My preference would be to just install either systemd of sysv support, which ever is the preferred default option for the distribution in question. However, if the maintainer wants to support both then they need to do whatever the right thing is for their distribution. It sounds like that means a symlink on Debian systems (option 2). @FransUrbo @ggzengel so if I understand correctly then this issue can be closed because there's no need to merge anything in the upstream ZoL tree. It will be handled by the maintainers in their packaging. |
|
@behlendorf If you agree to the fact that conflicts between SYSV and systemd (as in, installed simultaneous) is a distribution issue, not a ZoL issue, then I say that this can/should be closed. |
|
Agreed. Closing. |
#3837
For systems with systemd in sysv init compatibility mode you have to prevent that services in /etc/init.d will be executed if there is a equivalent in systemd.
There is zfs-import without a corresponding systemd service.