ZFS does not install sysvinit scripts

[Ryushin]

This is in reference to the Debian bug #826994
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=826994

Aron Xu from Debian mentions that this is an upstream problem.
So after setting up a Devuan Jessie, Debian Wheezy, and Debian Jessie (with sysvinit as default) and following the document for compiling from source 0.7.6:
https://github.com/zfsonlinux/zfs/wiki/Custom-Packages

Running make install from the zfs source did not install the init scripts in etc/init.d in the source tree. I even tested using the configure --enable-sysvinit (default anyway) and it still did not install the init scripts.

Please have the init scripts installed and activated for systems that use sysvinit.

[loli10K]

So after setting up a Devuan Jessie, Debian Wheezy, and Debian Jessie (with sysvinit as default)

Does these systems have systemd installed ("systemctl" binary in $PATH)? This is likey to be caused by the autoconf bits in 03658d5 if you're building 0.7.7.

On my Debian Jessie 0.7.6 correctly packages and installs sysvinit scripts:

root@linux:~# cat /etc/debian_version 
8.0
root@linux:~# dpkg -L zfs | grep init.d
/etc/init.d
/etc/init.d/zfs-mount
/etc/init.d/zfs-import
/etc/init.d/zfs-share
/etc/init.d/zfs-zed
root@linux:~# dpkg -l zfs
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name                                           Version                      Architecture                 Description
+++-==============================================-============================-============================-==================================================================================================
ii  zfs                                            0.7.6-1                      amd64                        Commands to control the kernel modules and libraries
root@linux:~# 

[Ryushin]

Does these systems have systemd installed ("systemctl" binary in $PATH)? This is likey to be caused by the autoconf bits in 03658d5 if you're building 0.7.7.

None of the systems have systemd or systemctl installed. I was building 0.7.6 from source as well.

Are you using the Debian packages? Installing from source does not install the init scripts?
./autogen.sh
./confgure
make
make install

I've been patching my Debian Source packages with:
https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=826994;filename=sysvinit_patch_3_826994.diff;msg=82

[Ryushin]

I compiled and installed 0.7.7 and also did not install the sysvinit scripts.

[beren12]

Even if some systemd packages are installed, it doesn't mean that's your init system. Debian supports both systems and because systemd has taken over tons of core utilities you can't fully get rid of it, and it's not hard to switch between them. --enable-sysvinit should always install the files no matter what other switches are given.

[Ryushin]

Both Devuan Jessie and Debian Wheezy don't have any systemd packages installed.
cat /proc/1/comm shows "init" on each system.

But as beren12 mentioned, --enable-sysvinit should always install the sysvinit scripts and try to activate them, regardless of distro, Devuan, Debian, Gentoo, Slackware, etc.

[loli10K]

@Ryushin i do not use Debian packages. How are you testing this on Debian Wheezy? IIRC 0.7.6 should not even be able to produce .deb packages due to an old alien version.

[Ryushin]

I'm not making any packages. Just compiling from the source and running make install.

But the issue in the Debian bug #826994 is that the source should be installing the sysvinit files by default and it is not.

[loli10K]

Sorry, you said you were following https://github.com/zfsonlinux/zfs/wiki/Custom-Packages in your issue report and i thought you were building packages ... i could not find any "make install" in the wiki, so i just assumed "Running make install from the zfs source did not install the init scripts in etc/init.d in the source tree" was just a test.

Can you please provide the following information?

1. Are you using tarballs or git to get the source?
2. Which parameters are you passing to ./configure?
3. Post the "config.log" output file (it would be great if you could use http://gist.github.com)
4. Verify you are not "make install"ing sysvinit scripts in "/usr/local/etc/init.d"

[Ryushin]

Using tarballs. Not passing any parameters or just the --enable-sysvinit parameter.
Config.log: https://gist.github.com/Ryushin/f2a874de2b6b25ea06329297393d3094
The init scripts did install "/usr/local/etc/init.d"
I thought the etc location was working fine as /etc/default/zfs was installed.

So with finding that out:
./configure --sysconfdir=/etc --enable-sysvinit
Resulted in the init scripts being installed in the correct location but they where not activated. Is there another option in the configure options to have it run the distros update-rc.d / chkconfig / rc-update commands?

loli10K: Thank you for thinking to look in /usr/local/etc. Strange that some things are installed in /etc and others in /usr/local/etc. I would think that that the configure would by default use /etc and --sysconfdir can be used to specify someplace else.

[beren12]

yeah… /usr/local/etc seems like a really strange place since nothing else is installed into /usr/local

[loli10K]

I believe this is the default behaviour in every project using autotools: from ./configure --help

By default, `make install' will install all the files in
`/usr/local/bin', `/usr/local/lib' etc.  You can specify
an installation prefix other than `/usr/local' using `--prefix',
for instance `--prefix=$HOME'.

Is there another option in the configure options to have it run the distros update-rc.d / chkconfig / rc-update commands?

I don't think so, it doesn't look like it is autoconf's job to do this.

[beren12]

Well, if everything was installed to /use/local i guess it makes sense for etc/ to be in /usr/local as well… but it's still confusing if somethings are in /etc and others in /user/local/etc

[Ryushin]

loli10K: So adding --sysconfdir=/etc to the Debian zfs-0.7.6-1 debian/rules file did not install the init scripts. Can you point me to the source of the Debian packages that you are using so I can figure out what is needed to fix the official Debian packages.

[pashford]

I believe something's missing here.

Systemd has three locations for the files it uses:

• /etc/systemd - By convention, this is the directory that should be used by system administration, either for locally developed services, or to override settings from upstream providers and vendors.
• /run/systemd - By convention, this is the directory that should be used for testing new/updated system configuration files.
• /usr/lib/systemd - By convention, this is the directory that should be used by upstream providers and vendors.

As the ZFS system files are from the upstream provider, I believe they should be installed into /usr/lib/systemd.

[rlaager]

@pashford Everything you said about systemd is correct, but this is not about systemd. This is about sysvinit.

[Ryushin]

This can probably be closed. Though it should be mentioned in https://github.com/zfsonlinux/zfs/wiki/Custom-Packages to use --sysconfdir=/etc and to activate the init scripts.

[loli10K]

use --sysconfdir=/etc and to activate the init scripts

That is taken care of by rpmbuild, no need to do it manually: https://github.com/zfsonlinux/zfs/blob/zfs-0.7.6/rpm/generic/zfs.spec.in#L231

[Ryushin]

But what about compiling from source tarballs? Interesting that there is a generic rpm but no generic debian in the source.

[Fabian-Gruenbichler]

On Tue, Apr 10, 2018 at 04:24:20AM -0700, Ryushin wrote: But what about compiling from source tarballs? Interesting that there is a generic rpm but no generic debian in the source.

@aerusso and I spitballed the idea some weeks ago to push a variant of Debian's packaging upstream to provide first-party native .deb builds - but we haven't progressed any further on that front yet. I hope to be able to put up a rought draft of various approaches after further brainstorming with @aerusso - but I won't have much time for that in the next 1-2 weeks unfortunately.

[aerusso]

@Fabian-Gruenbichler I have packaging that works, and I'm using it. The debian directories are also available in one of my repos (they're modified version of what's in Debian proper). I'm not sure what standards are expected of the packaging, so I was hoping to eventually talk with you about that. If you want, you can take a look and send me comments.

[Ryushin]

@Fabian-Gruenbichler: Hopefully the packages you are building have the sysvinit scripts: https://bugs.debian.org/826994

[behlendorf]

I'm not sure what standards are expected of the packaging

I'm all for adding native packaging to the repository. As for standards, we should try and conform as closely as possible to the Debian packaging guidelines. At a minimum we need to retain the ability to build and install packages for the buildbot to use when testing.

[pashford]

@rlaager,

this is not about systemd. This is about sysvinit.

I reread the Issue. Yes, sysVinit. The directory name was what caused me to think it was systemd. There's no valid reason to install any sysVinit scripts in any directory other then /etc/init.d and /etc/rc?.d (links). Sorry for the confusion.

How should this be solved? We can either fix this in the makefile (override locations for init scripts), or in the WIKI (documentation). It would be useful to know whether or not the --sysconfdir=/etc parameter causes problems with the system build/install. If the system install puts the configuration files into the wrong directory when the --sysconfdir=/etc parameter is used, it might be best to update the makefile.

For the user building the software from source, fixing the makefile would also be best.

[Ryushin]

This is in reference to: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=826994

I'm a bit confused then. Debian is saying the lack of sysvinit scripts is because of an upstream issue with ZFS. But the sysvinit scripts have been there for years in the source. Is the issue Debian has from the fact that they are not getting installed to /etc/init.d and the necessary sysnlinks in /etc/rc?.d created like what I mentioned before?

[cmur2]

Why was this closed?

[rlaager]

This bug report was opened because Debian said that there was an upstream problem. There was not, and I eventually convinced the Debian folks that the init scripts were in the tarball the whole time. The packages in Debian were fixed.

Is there still some outstanding issue here?