Created attachment 362826 [details] dhcpd4.service from archlinux there were none after transition.
Created attachment 362828 [details] dhcpd6.service
I cannot run that command: nov 11 22:36:01 belkin5 dhcpd[19798]: Not searching LDAP since ldap-server, ldap-port and ldap-base-dn were not specified in the config file nov 11 22:36:01 belkin5 dhcpd[19798]: Can't open lease database /var/lib/dhcp/dhcpd.leases: No such file or directory -- nov 11 22:36:01 belkin5 dhcpd[19798]: check for failed database rewrite attempt! nov 11 22:36:01 belkin5 dhcpd[19798]: Please read the dhcpd.leases manual page if you nov 11 22:36:01 belkin5 dhcpd[19798]: don't know what to do about this. nov 11 22:36:01 belkin5 dhcpd[19798]: nov 11 22:36:01 belkin5 dhcpd[19798]: This version of ISC DHCP is based on the release available nov 11 22:36:01 belkin5 dhcpd[19798]: on ftp.isc.org. Features have been added and other changes nov 11 22:36:01 belkin5 dhcpd[19798]: have been made to the base software release in order to make nov 11 22:36:01 belkin5 dhcpd[19798]: it work better with this distribution. nov 11 22:36:01 belkin5 dhcpd[19798]: nov 11 22:36:01 belkin5 dhcpd[19798]: Please report for this software via the Gentoo Bugzilla site: nov 11 22:36:01 belkin5 dhcpd[19798]: http://bugs.gentoo.org/ nov 11 22:36:01 belkin5 dhcpd[19798]: nov 11 22:36:01 belkin5 dhcpd[19798]: exiting. Reading the man page, looks like I need to simply run: touch DBDIR/dhcpd.leases Why isn't this done by ebuild? (I guess init.d would also benefit from it)
> Why isn't this done by ebuild? (I guess init.d would also benefit from it) It is already done in /etc/init.d/dhcpd: local leasefile="$(get_var lease-file-name /var/lib/dhcp/${SVCNAME}.leases)" checkpath -f -o dhcp:dhcp "${chroot}${leasefile}"
I was thinking on doing it at install time to let init.d and systemd unit to not need to handle it by separate
Given that the init script allows you to have multiple instances of dhcpd with separate lease files, I don't see how you could create the lease file(s) in the ebuild.
Well, I was thinking on simply creating var/lib/dhcp/dhcpd.leases and dhcpd6.leases as fedora and arch are doing
(In reply to Pacho Ramos from comment #6) > Well, I was thinking on simply creating var/lib/dhcp/dhcpd.leases and > dhcpd6.leases as fedora and arch are doing Any problem with doing that?
(In reply to Pacho Ramos from comment #7) I guess that's fine.
(In reply to Pacho Ramos from comment #6) because you cannot rely on /var/lib ever being filled out. it is correct for the init script to create the dirs/files as needed with the right perms.
Then, either we create it in unit file or tell people to do that manually :/
(In reply to Pacho Ramos from comment #10) what people write in systemd unit files matters not to me. i'm merely telling you "no" to putting it into the ebuild ;).
(In reply to SpanKY from comment #9) > (In reply to Pacho Ramos from comment #6) > > because you cannot rely on /var/lib ever being filled out. it is correct > for the init script to create the dirs/files as needed with the right perms. Wait, are you saying we cannot rely on /var/lib? Can you please share more information about that? I am asking because after I read your comment I went to "/var/lib" on one of my test systems, stopped various services (nginx, ntp, firewalls, redis, vnstat, powerdns), removed their folders from "/var/lib" and tried to restart the services. All mentioned services failed. So are these maintainers all doing something wrong, because they don't ensure that these folders are present/in an expected state in the runscript (I tested with OpenRC, not systemd!)? Should we use tmpfiles (https://blog.flameeyes.eu/2013/01/the-unsolved-problem-of-the-init-scripts) for that (this would allow us to keep the maintenance overhead low; could be used from systemd and OpenRC; checkpath isn't available from systemd/systemd folk doesn't like scripts)? My problem with tmpfiles is: You install something new. You cannot use it until you restart tmpfiles. I haven't seen any ebuild yet telling me to restart tmpfiles so I'd like to hear some best practice. Thanks.
(In reply to Thomas D. from comment #12) yes, for many services, you should be able to do: /etc/init.d/foo stop rm -rf /var/lib/* /etc/init.d/foo start that doesn't apply to all services as some, like mysql/postgres need to seed a lot of state. but they have `emerge --config <package>` to regenerate things because the operation is non-trivial and expensive. that rule doesn't apply to dhcpd thought because it simply needs the dir to exist and then it can do what it needs to do. at some point we'll start filing bugs for /var/lib offenders. for now, it's up to maintainers (i.e. me) to enforce it.
+*dhcp-4.2.5_p1-r2 (26 Dec 2013) + + 26 Dec 2013; Pacho Ramos <pacho@gentoo.org> +dhcp-4.2.5_p1-r2.ebuild, + +files/dhcpd.tmpfiles, +files/dhcpd4.service, +files/dhcpd6.service, + +files/dhcrelay4.service, +files/dhcrelay4.service.conf, + +files/dhcrelay6.service, +files/dhcrelay6.service.conf: + Add unit file (#490800) +
