net-fs/autofs should provide systemd unit file. Reproducible: Always
If you are able to prepare one, that will make things go faster for sure
Created attachment 354930 [details] autofs.service "Work's for me" It's my first unit file so it need a review.
Err, what's the point of using autofs in the first place? systemd has built-in automounts support...
hi charles, I'm already aware that upstream support systemd. I haven't added it because I don't use systemd and can't test. so, I'm really need helps here. hi @mgorny, what's your suggestion here? do you mean it's not necessary to add systemd support into autofs? or can we make them exist mutual exclusive? like you add some flag(automount?) into systemd, so autofs can add something like "system? ( sys-apps/systemd[-automount] )" into RDPEND?
I was just curious if this isn't one of the cases where people install random packages when everything they need is around already.
Created attachment 355040 [details, diff] add systemd support hi @charles, could you test is this works for you?
Created attachment 355076 [details, diff] ebuild diff agaist 5.0.7-r3 1) update RDEPEND, at least make it depend on RDEPEND (is this necessary?) 2) make systemddir controlled by IUSE=systemd 3) revision bump, update to 5.0.7-r4? (IUSE changes, necessary?)
You are not allowed to use USE=systemd to control unit files. You install them unconditionally.
Bug can not be marked RESOLVED TEST-REQUEST before changes will hit portage tree. Reopening...
Created attachment 355138 [details, diff] ebuild diff v3 against 5.0.7-r3 this should address @mgorny's concern. install unit files unconditionally
It's still conditional. Looking at the sources, upstream uses --with-systemd purely to control unit file install. You should pass --with-systemd, and no RDEPEND on systemd. Also, please suggest upstream to use --with-systemdsystemunitdir like other packages do. Uniformity is a good thing, and the same switch can be used both to provide the directory and control installing unit files. If they want, I have a pretty nice snippet in [1]. If they don't want the whole file, earlier versions [2] do not use the generic macro and therefore are more specialized. [1]:https://bitbucket.org/mgorny/systemd-sdk/src/master/m4/systemd.m4 [2]:https://bitbucket.org/mgorny/systemd-sdk/src/6e32c48490/m4/systemd.m4
(In reply to Dennis 'dlan' Lan from comment #10) > Created attachment 355138 [details, diff] [details, diff] > ebuild diff v3 against 5.0.7-r3 > > this should address @mgorny's concern. install unit files unconditionally This ebuild work's for me on start and stop usage. The reload usage work but raise error due to return of kill : # systemctl reload autofs Job for autofs.service failed. See 'systemctl status autofs.service' and 'journalctl -xn' for details. # systemctl status autofs autofs.service - Automounts filesystems on demand Loaded: loaded (/usr/lib64/systemd/system/autofs.service; enabled) Active: active (running) (Result: exit-code) since lun. 2013-08-05 15:56:03 CEST; 1min 22s ago Process: 4284 ExecReload=/usr/bin/kill -HUP $MAINPID (code=exited, status=203/EXEC) Process: 4247 ExecStart=/usr/sbin/automount $OPTIONS --pid-file /run/autofs.pid (code=exited, status=0/SUCCESS) Main PID: 4249 (automount) CGroup: /system.slice/autofs.service └─4249 /usr/sbin/automount --pid-file /run/autofs.pid août 05 15:56:38 polochon systemd[1]: Forked /usr/bin/kill as 4279 août 05 15:56:38 polochon systemd[1]: autofs.service changed running -> reload août 05 15:57:18 polochon systemd[1]: Trying to enqueue job autofs.service/reload/replace août 05 15:57:18 polochon systemd[1]: Installed new job autofs.service/reload as 1415 août 05 15:57:18 polochon systemd[1]: Enqueued job autofs.service/reload as 1415 août 05 15:57:18 polochon systemd[1]: Reloading Automounts filesystems on demand. août 05 15:57:18 polochon systemd[1]: About to execute: /usr/bin/kill -HUP $MAINPID août 05 15:57:18 polochon systemd[1]: Forked /usr/bin/kill as 4284 août 05 15:57:18 polochon systemd[1]: autofs.service changed running -> reload août 05 15:57:18 polochon systemd[1]: autofs.service changed reload -> running I think it's an upstream bug, isn't it ? Hi @Michał. I use autofs to mount nfs remote directory automaticaly based on hostname and directory name. Ex : ls /net/192.168.1.50/volume1/data => automount nfs. Can Systemd do that ? I have autofs already functional with OpenRC. I move to systemd for Gnome. So I have not "install random packages" but try to get already installed/tuned program to work.
(In reply to Michał Górny from comment #11) > It's still conditional. Looking at the sources, upstream uses --with-systemd > purely to control unit file install. You should pass --with-systemd, and no > RDEPEND on systemd. > what do you mean here about "conditional"? it sounds weird to me that we install unit file without systemd support. I could come up with two options "--with-systemd" and "--with-systemdsystemunitdir", they have no interactions with each other. that mean "--with-systemdsystemunitdir" can be enabled without systemd support (without --with-systemd=yes"). so, unit files will be always installed with/without systemd enabled. is this ok? > Also, please suggest upstream to use --with-systemdsystemunitdir like other > packages do. Uniformity is a good thing, and the same switch can be used > both to provide the directory and control installing unit files. > > If they want, I have a pretty nice snippet in [1]. If they don't want the > whole file, earlier versions [2] do not use the generic macro and therefore > are more specialized. > > [1]:https://bitbucket.org/mgorny/systemd-sdk/src/master/m4/systemd.m4 > [2]:https://bitbucket.org/mgorny/systemd-sdk/src/6e32c48490/m4/systemd.m4 I will ping upstream, but I'd like to keep the changes minimal. Your proposal require pkg-config, Makefile.am(automake) support. the file of sample/Makefile is still hand coded. this may require too many changes. I'm not sure whether I can convince upstream developer.
Created attachment 355248 [details, diff] ebuild diff agaist 5.0.7-r3 (v4) final version. I plan to cook a patch to suggest upstream add a option "--with-systemdsystemunitdir", but I do not want to introduce it into 5.0.7-r3. becasue it do not affect the installed files(exactly the same).
upstream discussion for adding a --with-systemdsystemunitdir option [1] http://thread.gmane.org/gmane.linux.kernel.autofs/6703 [2] http://article.gmane.org/gmane.linux.kernel.autofs/6702 [3] http://article.gmane.org/gmane.linux.kernel.autofs/6704
If you could proxy our answer, I'd appreciate it. --with-systemdsystemunitdir (however horrible that is to spell) is upstream's option name. It's covered in the manual [1]. Programs that use that include syslog-ng, gdm, libcanberra, alsa-utils, mpd, NetworkManager, polkit, colord, ... [1]:http://0pointer.de/public/systemd-man/daemon.html
(In reply to Michał Górny from comment #16) ok, I will forward this.. and I'm still puzzled about why you advocate installing systemd unit file unconditionally? from the link you give, I got this, so that mean unit file will be installed when systemd support is enabled? (on condition systemd support is enabled.) if HAVE_SYSTEMD systemdsystemunit_DATA = \ foobar.socket \ foobar.service endif
Yes. However, in Gentoo we have a policy of installing them unconditionally to avoid rebuilding a number of packages when switching between OpenRC and systemd.
(In reply to Charles Nérot from comment #12) > (In reply to Dennis 'dlan' Lan from comment #10) > > Created attachment 355138 [details, diff] [details, diff] [details, diff] > > ebuild diff v3 against 5.0.7-r3 > > > > this should address @mgorny's concern. install unit files unconditionally > > This ebuild work's for me on start and stop usage. > The reload usage work but raise error due to return of kill : > > # systemctl reload autofs > Job for autofs.service failed. See 'systemctl status autofs.service' and > 'journalctl -xn' for details. > # systemctl status autofs > autofs.service - Automounts filesystems on demand > Loaded: loaded (/usr/lib64/systemd/system/autofs.service; enabled) > Active: active (running) (Result: exit-code) since lun. 2013-08-05 > 15:56:03 CEST; 1min 22s ago > Process: 4284 ExecReload=/usr/bin/kill -HUP $MAINPID (code=exited, > status=203/EXEC) > Process: 4247 ExecStart=/usr/sbin/automount $OPTIONS --pid-file > /run/autofs.pid (code=exited, status=0/SUCCESS) > Main PID: 4249 (automount) > CGroup: /system.slice/autofs.service > └─4249 /usr/sbin/automount --pid-file /run/autofs.pid > > août 05 15:56:38 polochon systemd[1]: Forked /usr/bin/kill as 4279 > août 05 15:56:38 polochon systemd[1]: autofs.service changed running -> > reload > août 05 15:57:18 polochon systemd[1]: Trying to enqueue job > autofs.service/reload/replace > août 05 15:57:18 polochon systemd[1]: Installed new job > autofs.service/reload as 1415 > août 05 15:57:18 polochon systemd[1]: Enqueued job autofs.service/reload as > 1415 > août 05 15:57:18 polochon systemd[1]: Reloading Automounts filesystems on > demand. > août 05 15:57:18 polochon systemd[1]: About to execute: /usr/bin/kill -HUP > $MAINPID > août 05 15:57:18 polochon systemd[1]: Forked /usr/bin/kill as 4284 > août 05 15:57:18 polochon systemd[1]: autofs.service changed running -> > reload > août 05 15:57:18 polochon systemd[1]: autofs.service changed reload -> > running > > I think it's an upstream bug, isn't it ? > > Hi @Michał. > I use autofs to mount nfs remote directory automaticaly based on hostname > and directory name. Ex : ls /net/192.168.1.50/volume1/data => automount nfs. > Can Systemd do that ? > I have autofs already functional with OpenRC. I move to systemd for Gnome. > So I have not "install random packages" but try to get already > installed/tuned program to work. Hi @charles, do you have any updates about the reload operation? shouldn't the reload operation equal to "stop + start"? can you make sure the running process is killed first, then start later? it seems the killed process(4284) is behind the start process(4247)? (PID bigger) I may try to setup a systemd environment, but this may takes a few time... or, could you report to upstream if you still think it's upstream problem?
Created attachment 356662 [details, diff] ebuild diff agaist 5.0.7-r3 (v5) changing from /usr/bin/kill -> /bin/kill, this also fix systemd reload bug.
+ 22 Aug 2013; Sergey Popov <pinkbyte@gentoo.org> -autofs-5.0.7-r3.ebuild, + +autofs-5.0.7-r4.ebuild: + Revision bump: add systemd support, wrt bug #479492. Thanks to Charles Nérot + <charles AT nerot.com> for discovering this issue and Dennis Lan <dennis.yxun + AT gmail.com> for all necessary fixes. Drop old revision
(In reply to Dennis 'dlan' Lan from comment #20) > Created attachment 356662 [details, diff] [details, diff] > ebuild diff agaist 5.0.7-r3 (v5) > > changing from /usr/bin/kill -> /bin/kill, this also fix systemd reload bug. Just for record, if you want to be super-safe, you can use '/usr/bin/env kill' but I doubt it will be ever necessary.
