-
Notifications
You must be signed in to change notification settings - Fork 55
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
systemd and LSB scripts run parallel #172
Comments
You should make two packages. One for SYSV and one for systemd. |
Shouldn't be needed and from what I can tell, no one else is doing that. There is a recommended, safe way to mix systemd and sysv scripts. This uses the Debian GNU/Linux tools to maintain the two different ways. Once you enable systemd, the sysv init scripts is disabled. OR, if there is no systemd scripts, the sysv init scripts is converted into systemd config files... |
I wrote xen_zfs.target:
|
I forgot this:
|
The package come with both sysv and systemd scripts included. Don't know why you have a auto-generated script there! Did you install the packages on a system that didn't use systemd, then changed to systemd and that when the problem started perhaps? |
This system was debootstraped from wheezy but with dist jessie early with zfs 2.6.3. |
After bootstraping I booted jessie and after that I added zfs, |
Debootstrap don't install systemd for you as far as I know. So somewhere in all that, systemd must have gone active, so my idea sounds plausible. But that still don't explain why you're running with generated systemd files... |
How to get rid of this? |
I have absolutly no idea! You could always try using OR, just move the sysv scripts out the way. Move them to your home directory or something. You can always move them back if it turns out to be a problem. |
What's about this? Both should have the same name.
Without LSB ZED it didn't need LSB mount. |
I think there should be something about zfs-import.target to have the same name as /etc/init.d/zfs-import. |
Why do you not unshare, unmount or export like init.d? |
Actually, that is very likely a leftover from an earlier package and shouldn't be there.
Yes. And zfs-share and zfs-mount as well! |
Sure?
Both have time stamp: Sep 20 10:55 |
You're right! We must have missed to rename that when the new SYSV init scripts was accepted! I've opened a different issue about that... But that was just a side note. It still doesn't explain the original problem you're having. |
@dajhorn You've worked with systemd quite a lot, do you have any clue or idea on what could be the problem? |
That's exactly the problem. You have 3 active import scripts: zfs-import-cache.service and two off them running at boot time. |
Perhaps you rename zfs-import-cache.service to zfs-import.service with all dependencies and the problem is gone. |
The two service files do two different things. Or rather, import the pool(s) in different way, so they must both remain. So that isn't the solution either. |
Than you have to make a dummy zfs-import.service. |
No! You need to take a step back and breath! We do NOT go around writing code or anything else to fix a possible problem that so far have affected only ONE person out of hundreds, maybe thousands! AND we have not ruled out user error yet! |
I don't have only one system.
|
Here is an other system before and after update. Now look and see:
|
My point is that this more and more seems like an upstream problem. SYSV init scripts and systemd should not run at the same time. Could you take this to either the Debian GNU/Linux bug tracker or, preferable, to their mailing lists. Granted, ZFS isn't supported by them (yet), but it seems to be a problem with their tools or something. |
No, you are absolutely wrong., |
You're completely missing my point and isn't listening to what I'm saying. I can't reproduce this (and no one else seems to have ever seen this problem) so I'm going to close this as an upstream (Debian GNU/Linux) issue - OR user error. If you come back with references from their bug tracker and/or mailing list that's stating that it's something I have done, we can reopen it. |
I bet everybody with plain jessie with systemd will have this issue. |
On boot I see ZFS pool import twice. One LSB and one Systemd. They run both on same time.
With systemd there is a lot to do. It always import pool by ID:
cat zfs-import-scan.service | grep ExecStart=
ExecStart=/sbin/zpool import -d /dev/disk/by-id -aN
I think this won't work with the code above:
ZPOOL_IMPORT_PATH="/dev/disk/by-vdev:/dev/disk/by-id"
Perhaps these are changes from Turbo?
The idea behind this is OK, because I like to import pools by partlabel.
The text was updated successfully, but these errors were encountered: