Hide Forgot
Description of problem: A dovecot package supplied /etc/dovecot/dovecot.conf comes with the following line in it: protocols = imaps pop3s lmtp If started that way dovecot write in log files: .... doveconf: Warning: Obsolete setting in /etc/dovecot/dovecot.conf:21: 'imaps' protocol is no longer supported. to disable non-ssl imap, use service imap-login { inet_listener imap { port=0 } } .... doveconf: Warning: Obsolete setting in /etc/dovecot/dovecot.conf:21: 'pop3s' protocol is no longer supported. to disable non-ssl pop3, use service pop3-login { inet_listener pop3 { port=0 } } Version-Release number of selected component (if applicable): dovecot-2.0.15-1.fc17 How reproducible: always Expected results: A default configuration suitable for the current package version Additional info: This detail that a conceptually broken a non-configuration file /lib/systemd/system/dovecot.socket sandbags a system administrator and starts imap (not imaps) listener even if explicitely configured _out_ is neither here nor there.
To get rid of the warnings, remove the "protocols = ..." line from /etc/dovecot/dovecot.conf. This will enable imap (port 143) and pop3 (port 110), in addition to imaps/pop3s. If you don't want imap, add "port = 0" to the "inet_listener imap" section in /etc/dovecot/conf.d/10-master.conf (this leaves imaps enabled). If you don't want pop3, add "port = 0" to the "inet_listener pop3" section (this leaves pop3s enabled).
(In reply to comment #1) > To get rid of the warnings, remove the "protocols = ..." line from > /etc/dovecot/dovecot.conf. You miss the point. I know what I can do to kill these warnings. The issue is that a default configuration from a distribution package is causing these. > This will enable imap (port 143) and pop3 (port 110), in addition to > imaps/pop3s. Did you try? Again, by default you are running dovecot.socket and not dovecot.service and in that situation your port enabling and disabling in a dovecot configuration is just disregarded while /lib/systemd/system/dovecot.socket is not marked as a "configuration file". That possibly needs another bugzilla report.
> You miss the point. I know what I can do to kill these warnings. Might be useful information for others who come across the same problem. > The issue > is that a default configuration from a distribution package is causing these. I agree that it's not ideal for the default configuration to cause these warnings. > Did you try? Yes - earlier today in fact. By removing the "protocols = ..." line, all four protocols (imap/imaps/pop3/pop3s) are enabled. So adding "port = 0" for imap/pop3 leaves just imaps/pop3s, which is what the "protocols = ..." line is trying to achieve (and is what I want). > Again, by default you are running dovecot.socket and not > dovecot.service Neither dovecot.socket nor dovecot.service were enabled for me after installing Dovecot; so I enabled/started dovecot.service. With the changes described above, the warnings go away and I'm left with a running Dovecot listening only on the imaps/pop3s ports. > and in that situation your port enabling and disabling in a > dovecot configuration is just disregarded while > /lib/systemd/system/dovecot.socket is not marked as a "configuration file". > That possibly needs another bugzilla report. Yeah, that is odd. dovecot.socket ought to be changed so that systemd listens on port 995 (pop3s) instead of 143 (imap), since that is what the "protocols = ..." line makes Dovecot use. As a workaround though, if you get the Dovecot configuration set up how you like it, you can just enable/start dovecot.service, not dovecot.socket.
(In reply to comment #3) > > I agree that it's not ideal for the default configuration to cause these > warnings. Well, one of ways to prevent these warnings is to have in a configuration protocols = imap With the current dovecot that enables both imap and imaps (unless eomething is not configured out in a way described in quoted warnings) and at least is consistent with what dovecot.socket is doing. Results are visible in an output of 'netstat -pae'. A line 'protocols = imaps ...' in the present situation is simply wrong. > Neither dovecot.socket nor dovecot.service were enabled for me after installing > Dovecot; so I enabled/started dovecot.service. I cannot tell what is supposed to be running or not running by default anymore. I only know that on a rawhide system where dovecot was present but NOT enabled by default after updates I ended up with an active dovecot.socket while I was not asking for it. OTOH some turned on services (like NFS) got switched off. A bloody mess in other words. Myself I can eventually sort this out. I know enough of people who will be completely lost. > Yeah, that is odd. dovecot.socket ought to be changed so that systemd listens > on port 995 (pop3s) instead of 143 (imap), since that is what the "protocols = > ..." line makes Dovecot use. Again - the existing "protocols = ..." line is now incorrect but dovecot.socket does not pay the slightest attention to it. > As a workaround though, if you get the Dovecot configuration set up how you > like it, you can just enable/start dovecot.service, not dovecot.socket. I am really not asking for workarounds for myself.
I've fixed the first part, so it won't print those obsolete messages. For socket activation, this is not fixed yet.
The dovecot.conf file still contains imaps for the protocol line in f16. i.e. the line: protocols = imap pop3s lmtp should really be: protocols = imap pop3s lmtp Can imaps be changed to simply imap in which case there will be no complaint from the system if dovecot service is activated and used with the default config file?
(In reply to comment #6) > The dovecot.conf file still contains imaps for the protocol line in f16. this should be fixed now
This seems fixed in dovecot-2.0.16-1.fc16
Can this bug be closed now?
(In reply to comment #9) > Can this bug be closed now? AFAICS not really. "Normal" repositories for F16 still include only dovecot-2.0.15-1.fc16 with the problem present. Moreover even in koji packages /lib/systemd/system/dovecot.socket hardwires listener ports, without paying any attention to a configuration in /etc/dovecot/ and dovecot.socket file is not marked "config" so even if you will make adjustments there then the next update will clobber it. I am not sure what can be done with dovecot.socket. One possible avenue is to run 'dovecot -n' and check what comes out from there. Only when? It is not clear to me what one can do here with systemd.
(In reply to comment #9) > Can this bug be closed now? not yet, because only the configuration is fixed. Socket activation problem remains. ad dovecot update is in updates-testing repository, bodhi limits are not fulfilled yet > dovecot.socket file is not marked "config" so even if you will > make adjustments there then the next update will clobber it. for dovecot.service and/or dovecot.socket changes, you should copy them to /etc/systemd/system/ and make changes there. These files won't be overwritten during update
(In reply to comment #11) > > > dovecot.socket file is not marked "config" so even if you will > > make adjustments there then the next update will clobber it. > > for dovecot.service and/or dovecot.socket changes, you should copy them to > /etc/systemd/system/ and make changes there. That is not needed for dovecot.service as you just start dovecot and it pays attention for its configuration so this is fine. If you will copy dovecot.socket to /etc/systemd/system/ then you are in the following situation after you tried to start dovecot.socket: dovecot.socket - Dovecot IMAP/POP3 email server activation socket Loaded: loaded (/lib/systemd/system/dovecot.socket; disabled) Active: active (listening) since Tue, 29 Nov 2011 13:28:44 -0700; 4min 14s ago CGroup: name=systemd:/system/dovecot.socket This actually works despite this "disabled" but all changes in an /etc/systemd/system/dovecot.socket copy are simply ignored. Just checked with netstat. Additionally with such copy 'systemctl disable dovecot.socket' silently fails and returns status 0 while 'systemctl enable dovecot.socket' gets status 1 and prints "Failed to issue method call: Invalid argument". All in all such "workaround" simply does not work. > These files won't be overwritten during update. That is right but this only creates a mess.
Oh, and changes in a copy of dovecot.socket located in /etc/systemd/system/sockets.target.wants are ignored as well.
(In reply to comment #12) > (In reply to comment #11) > > > > > > dovecot.socket file is not marked "config" so even if you will > > > make adjustments there then the next update will clobber it. > > > > for dovecot.service and/or dovecot.socket changes, you should copy them to > > /etc/systemd/system/ and make changes there. > > That is not needed for dovecot.service as you just start dovecot and it pays > attention for its configuration so this is fine. I've mentioned it for general changes, not related only to socket activation. > > If you will copy dovecot.socket to /etc/systemd/system/ then you are in the > following situation after you tried to start dovecot.socket: > > dovecot.socket - Dovecot IMAP/POP3 email server activation socket > Loaded: loaded (/lib/systemd/system/dovecot.socket; disabled) > Active: active (listening) since Tue, 29 Nov 2011 13:28:44 -0700; > 4min 14s ago > CGroup: name=systemd:/system/dovecot.socket > > This actually works despite this "disabled" but all changes in an > /etc/systemd/system/dovecot.socket copy are simply ignored. Just checked with > netstat. I've checked it right now. I edited copy of dovecot.socket (commented out ipv4 and ipv6 :143) placed in /etc/systemd/system, called systemctl daemon-reload and started dovecot.socket. netstat shown only imaps listening sockets > Additionally with such copy 'systemctl disable dovecot.socket' silently fails > and returns status 0 while 'systemctl enable dovecot.socket' gets status 1 and > prints "Failed to issue method call: Invalid argument". could you provide more details? > All in all such "workaround" simply does not work. > > > These files won't be overwritten during update. > That is right but this only creates a mess. Unfortunately, this is how systemd is designed to work: default unit files in /lib/systemd/... and if you want to change anything, copy it to /etc/systemd/... and edit it there
(In reply to comment #14) > I've checked it right now. I edited copy of dovecot.socket (commented out ipv4 > and ipv6 :143) placed in /etc/systemd/system, called systemctl daemon-reload > and started dovecot.socket. netstat shown only imaps listening sockets Hm, that is what I am seeing with systemd-37-4.fc17.x86_64: An initial state is that nothing "dovecot" is activated and 'netstat -pae | grep imap' comes back empty - as expected. Now I am putting into /etc/systemd/system/sockets.target.wants/dovecot.socket the folowing: [Unit] Description=Dovecot IMAP/POP3 email server activation socket [Socket] #dovecot expects separate IPv4 and IPv6 sockets BindIPv6Only=ipv6-only ListenStream=0.0.0.0:995 ListenStream=[::]:995 KeepAlive=true [Install] WantedBy=sockets.target That is only 'pop3s' socket configured here. After 'systemctl start dovecot.socket' I see as a "status": dovecot.socket - Dovecot IMAP/POP3 email server activation socket Loaded: loaded (/lib/systemd/system/dovecot.socket; disabled) Active: active (listening) since Wed, 30 Nov 2011 13:05:42 -0700; 5s ago CGroup: name=systemd:/system/dovecot.socket Ok, "disabled" but "active (listening)". Whatever. Only 'netstat -pae | grep pop' shows nothing. OTOH # netstat -pae | grep imap tcp 0 0 *:imap *:* LISTEN root 24301 1/init tcp 0 0 *:imaps *:* LISTEN root 24303 1/init tcp 0 0 *:imap *:* LISTEN root 24302 1/init tcp 0 0 *:imaps *:* LISTEN root 24304 1/init Oops! Surprise! It loaded /lib/systemd/system/dovecot.socket just like it said. So maybe not such big suprise after all. BTW - effects are exactly the same if I will put a modified dovecot.socket file into /etc/systemd/system/multi-user.target.wants/ instead of /etc/systemd/system/sockets.target.wants/ > Unfortunately, this is how systemd is designed to work: Which means that its design is seriously lacking and in the current incarnation plain broken. A possible, hacky, workaroud would be to have some means to "automatically" generate /lib/systemd/system/dovecot.socket from the current dovecot configuration. An output of 'dovecot -n' does provide a required info and dovecot does not need to run for that. A simpler way would be to mark /lib/systemd/system/dovecot.socket "config" and add a big fat comment to /etc/dovecot/dovecot.conf to the effect that if you want to configure ports for use by 'dovecot.socket' you need to edit a relevant file.
Thinking a bit more about general issues a symlink in /etc/sysconfig to /etc/dovecot would likely help with a "consistency". Like an exisiting /etc/sysconfig/selinux symlink.
(In reply to comment #15) > Oops! Surprise! It loaded /lib/systemd/system/dovecot.socket just like it > said. So maybe not such big suprise after all. > > BTW - effects are exactly the same if I will put a modified dovecot.socket file > into /etc/systemd/system/multi-user.target.wants/ instead of > /etc/systemd/system/sockets.target.wants/ > why are you putting it there? It should go to /etc/systemd/system/dovecot.socket multi-user.target.wants - this is what is started when changing session (or what is it called) to multi-user.target, not what is used when you start it manually using systemctl start xyz.
(In reply to comment #17) > > > why are you putting it there? It should go to > /etc/systemd/system/dovecot.socket Because if you will do 'systemctl enable dovecot.socket' then a link will be created in /etc/systemd/system/sockets.target.wants/, If you are asking about /etc/systemd/system/multi-user.target.wants/ directory then I tried that just in case for a completeness without expectations that this will do any good. IIRC I also tried in some moment /etc/systemd/system/ location too without any significant changes in results but at this moment I cannot recheck that. Later.
(In reply to comment #18) > (In reply to comment #17) > > > > > > why are you putting it there? It should go to > > /etc/systemd/system/dovecot.socket > > Because if you will do 'systemctl enable dovecot.socket' then a link will be > created in /etc/systemd/system/sockets.target.wants/ yes and it should be link. Anyway, for systemctl start dovecot.{service|socket}, /{etc|lib}/systemd/system/dovecot.{service|socket} is used. > IIRC I also tried in some moment /etc/systemd/system/ location too without > any significant changes in results but at this moment I cannot recheck that. > Later. let me know the result, because it works for me
(In reply to comment #19) > let me know the result, because it works for me No idea how. I put into /etc/systemd/system/dovecot.socket the same content as in comment #15, so only pop3s should show up, and after starting that I see # netstat -pae | grep imap tcp 0 0 *:imap *:* LISTEN root 23103 1/init tcp 0 0 *:imaps *:* LISTEN root 23105 1/init tcp 0 0 *:imap *:* LISTEN root 23104 1/init tcp 0 0 *:imaps *:* LISTEN root 23106 1/init with no traces of pop. In case of doubts - there is only _one_ dovecot.socket file in /etc/systemd/ tree. I even tried rebooting with this configuration. 'dovecot.socket' starts, as expected, but an output from netstat looks like above. 'systemctl status dovecot.socket' steadfastly claims "Loaded: loaded (/lib/systemd/system/dovecot.socket; disabled)" and in that at least "loaded" part agrees with observed results on what is really loaded. Not mentioning an extra fun with "enable/disable".
I'd noticed this bug is reported against rawhide, not Fedora 16. So I tried to reproduce it in rawhide: $ yum install dovecot dovecot-pigeonhole $ systemctl is-enabled dovecot.socket dovecot.service disabled disabled $ systemctl enable dovecot.socket $ systemctl is-enabled dovecot.socket dovecot.service enabled disabled # systemctl status dovecot.socket dovecot.socket - Dovecot IMAP/POP3 email server activation socket Loaded: loaded (/lib/systemd/system/dovecot.socket; enabled) Active: inactive (dead) since Mon, 12 Dec 2011 12:38:07 +0100; 3s ago CGroup: name=systemd:/system/dovecot.socket $ systemctl start dovecot.socket # systemctl status dovecot.socket dovecot.socket - Dovecot IMAP/POP3 email server activation socket Loaded: loaded (/lib/systemd/system/dovecot.socket; enabled) Active: active (listening) since Mon, 12 Dec 2011 12:38:35 +0100; 2s ago CGroup: name=systemd:/system/dovecot.socket $ netstat -l | grep -E 'imap|pop' tcp 0 0 *:imap *:* LISTEN tcp 0 0 *:imaps *:* LISTEN tcp6 0 0 [::]:imap [::]:* LISTEN tcp6 0 0 [::]:imaps [::]:* LISTEN cat >/etc/systemd/system/dovecot.socket <<EOF [Unit] Description=Dovecot IMAP/POP3 email server activation socket [Socket] #dovecot expects separate IPv4 and IPv6 sockets BindIPv6Only=ipv6-only ListenStream=0.0.0.0:995 ListenStream=[::]:995 KeepAlive=true [Install] WantedBy=sockets.target EOF $ systemctl restart dovecot.socket $ systemctl status dovecot.socket dovecot.socket - Dovecot IMAP/POP3 email server activation socket Loaded: loaded (/lib/systemd/system/dovecot.socket; enabled) Active: active (listening) since Mon, 12 Dec 2011 12:46:07 +0100; 5s ago CGroup: name=systemd:/system/dovecot.socket $ netstat -l | grep -E 'imap|pop' tcp 0 0 *:imap *:* LISTEN tcp 0 0 *:imaps *:* LISTEN tcp6 0 0 [::]:imap [::]:* LISTEN tcp6 0 0 [::]:imaps [::]:* LISTEN it's still correct (both "Loaded: .../lib/systemd/... and imap(s) sockets), because systemd is still using old socket files. $ systemctl daemon-reload $ systemctl status dovecot.socket dovecot.socket - Dovecot IMAP/POP3 email server activation socket Loaded: loaded (/etc/systemd/system/dovecot.socket; enabled) Active: active (listening) since Mon, 12 Dec 2011 12:46:07 +0100; 1min 59s ago CGroup: name=systemd:/system/dovecot.socket $ netstat -l | grep -E 'imap|pop' tcp 0 0 *:pop3s *:* LISTEN tcp6 0 0 [::]:pop3s [::]:* LISTEN now it uses dovecot.socket from /etc/... and sockets used are pop3s But beware of following catch: - we connect to the systemd's pop3s socket $ echo quit | openssl s_client -connect localhost:995 and now, what happened: $ netstat -l | grep -E 'imap|pop' tcp 0 0 *:pop3s *:* LISTEN tcp 0 0 localhost:pop3 *:* LISTEN tcp 0 0 localhost:imap *:* LISTEN tcp 0 0 *:imaps *:* LISTEN tcp6 0 0 [::]:pop3s [::]:* LISTEN tcp6 0 0 localhost:pop3 [::]:* LISTEN tcp6 0 0 localhost:imap [::]:* LISTEN tcp6 0 0 [::]:imaps [::]:* LISTEN unix 2 [ ACC ] STREAM LISTENING 21139 /var/run/dovecot/login/pop3 unix 2 [ ACC ] STREAM LISTENING 21153 /var/run/dovecot/login/imap systemd got new connection on pop3s port so it started dovecot with default configuration = with all protocols. So if there's any incoming connection to pop3s you'll see other ports listed too, if you did not disable them in dovecot's config files. Anyway, as you see it works fine for me. Please try to delete all extra service/socket files, re-install dovecot and try again using this example.
(In reply to comment #21) > cat >/etc/systemd/system/dovecot.socket <<EOF .... > EOF .... . > > $ systemctl daemon-reload > $ systemctl status dovecot.socket > dovecot.socket - Dovecot IMAP/POP3 email server activation socket > Loaded: loaded (/etc/systemd/system/dovecot.socket; enabled) > Active: active (listening) since Mon, 12 Dec 2011 12:46:07 +0100; > 1min 59s ago > CGroup: name=systemd:/system/dovecot.socket > > $ netstat -l | grep -E 'imap|pop' > tcp 0 0 *:pop3s *:* LISTEN > tcp6 0 0 [::]:pop3s [::]:* LISTEN That indeed happens to work. I did not think about 'daemon-reload'. As for continuing troubles after a reboot - see below. > But beware of following catch: .... > systemd got new connection on pop3s port so it started dovecot with default > configuration = with all protocols. Well, that can be adjusted so all configurations agree but now one has to keep in sync _two_ different configurations or bump into "a catch". > Anyway, as you see it works fine for me. OK, lets try that a bit more. # systemctl disable dovecot.socket # systemctl is-enabled dovecot.socket disabled # systemctl daemon-reload # netstat -l | grep -E 'imap|pop' tcp 0 0 *:pop3s *:* LISTEN tcp6 0 0 [::]:pop3s [::]:* LISTEN Oops! So lets try to move this custom 'dovecot.socket' file into the same location where 'systemctl enable dovecot.socket' would put it, i.e /etc/systemd/system/sockets.target.wants/dovecot.socket. With that we have now: # systemctl disable dovecot.socket ; echo $? 0 # systemctl enable dovecot.socket Failed to issue method call: Invalid argument # systemctl status dovecot.socket dovecot.socket - Dovecot IMAP/POP3 email server activation socket Loaded: loaded (/lib/systemd/system/dovecot.socket; disabled) Active: active (listening) since Mon, 12 Dec 2011 16:49:39 -0700; 19min ago CGroup: name=systemd:/system/dovecot.socket # systemctl daemon-reload # netstat -l | grep -E 'imap|pop' tcp 0 0 *:imap *:* LISTEN tcp 0 0 *:imaps *:* LISTEN tcp6 0 0 [::]:imap [::]:* LISTEN tcp6 0 0 [::]:imaps [::]:* LISTEN Oops again! BTW with a custom 'dovecot.socket' configuration in this location where you put it 'systemctl disable dovecot.socket' is a noop too. So alltogether this is hacky, fragile, not really documented, not controllable as documented and works sometimes but only by an accident. A truly great design! I still think that the only semi-sane way out is to make /lib/systemd/system/dovecot.socket into a configuration file with ample comments explaining interdependencies if somebody would want to use that stuff. Something like: # If you plan to enable this then make sure that a configuration in # /etc/dovecot/ enables precisely the same sockets or you may get # unwelcome surprises. and a corresponding comment in /etc/dovecot/dovecot.conf I guess that most of the time if you want dovecot then dovecot.service is way to go as opposed to dovecot.socket so these headaches will be left alone. Although I can see some uses for dovecot.socket too.
(In reply to comment #22) > OK, lets try that a bit more. > > # systemctl disable dovecot.socket > # systemctl is-enabled dovecot.socket > disabled > # systemctl daemon-reload > # netstat -l | grep -E 'imap|pop' > tcp 0 0 *:pop3s *:* LISTEN > tcp6 0 0 [::]:pop3s [::]:* LISTEN > > Oops! why oops? there is difference between systemctl disable dovecot.socket and systemctl stop dovecot.socket you've used something like chkconfig dovecot.socket off, which does not stop the socket (like "old" service dovecot stop ). $ systemctl stop dovecot.socket $ netstat -l | grep -E 'imap|pop' -> empty result so this still works > So lets try to move don't. systemd works with symlinks. As you can see in several systemctl <something> output. Only symlink or rm <link>. When you move the file from standard to different place, you will get "special" (mostly broken) behaviour. > this custom 'dovecot.socket' file into the same > location where 'systemctl enable dovecot.socket' would put it, i.e > /etc/systemd/system/sockets.target.wants/dovecot.socket. With that we have > now: > > # systemctl disable dovecot.socket ; echo $? > 0 > # systemctl enable dovecot.socket > Failed to issue method call: Invalid argument > # systemctl status dovecot.socket > dovecot.socket - Dovecot IMAP/POP3 email server activation socket > Loaded: loaded (/lib/systemd/system/dovecot.socket; disabled) > Active: active (listening) since Mon, 12 Dec 2011 16:49:39 -0700; > 19min ago > CGroup: name=systemd:/system/dovecot.socket > # systemctl daemon-reload > # netstat -l | grep -E 'imap|pop' > tcp 0 0 *:imap *:* LISTEN > tcp 0 0 *:imaps *:* LISTEN > tcp6 0 0 [::]:imap [::]:* LISTEN > tcp6 0 0 [::]:imaps [::]:* LISTEN > > Oops again! BTW with a custom 'dovecot.socket' configuration in this location > where you put it 'systemctl disable dovecot.socket' is a noop too. disable=chkconfig ... off -> do not turn it on during boot stop=stop service do not move files, use symlinks let me know if it works for you if you use symlinks and disable/stop where socket disable/stop behaviour is needed > So alltogether this is hacky, fragile, not really documented, not controllable > as documented and works sometimes but only by an accident. A truly great > design! I did not say I like this, but it works.
(In reply to comment #23) > I did not say I like this, but it works. For some very loose definition of "it works"; and for the next version of systemd, with somewhat tighter handling of its configuration files, it may as well stop or will "work" in some other way. Or you can quote some pieces of systemd documentation which give assurances that this is not the case? As it happens now you need _both_ your custom /etc/systemd/system/dovecot.socket and a link in /etc/systemd/system/sockets.target.wants/ from /etc/systemd/system/dovecot.socket for this to be activated in a boot startup sequence. For an added attraction if you _do not_ have that link and with active sockets you will do 'systemctl daemon-reload' then these sockets may or may not disappear. Apparently at random. I still cannot figure out what other factors may influence that.
(In reply to comment #24) > As it happens now you need _both_ your custom > /etc/systemd/system/dovecot.socket and a link in > /etc/systemd/system/sockets.target.wants/ from > /etc/systemd/system/dovecot.socket for this to be activated in a boot startup > sequence. yes /lib/systemd/system/<daemon>.service is something like /etc/init.d/<daemon> SysV init scripts are not marked as %config(noreplace) in spec file, so when you modify them, next rpm update breaks your changes. This is the reason why systemd has another directory in /etc/systemd/system/ for user changes. You can a)put your own file there with whole configuration b)put there file that includes original service file and change only what you need, c)use original file (/lib/systemd/...) only /{etc|lib}/systemd/system/sockets.target.wants/<daemon>.service is like /etc/rc.d/rd.5/<daemon> so in fact, it's not that different. service <daemon> start uses: for init script: /etc/init.d/<daemon> for systemd: /lib/systemd/system/<daemon>.service for start during boot: init script: /etc/rc.d/rc.5/Sxy<daemon> systemd: /lib/systemd/system/multi-user.target.wants/<daemon>.service so both SysV init and systemd need that file in multiple locations to work.
(In reply to comment #25) > SysV init scripts are not marked as %config(noreplace) in spec file, There is one HUGR difference. Those scripts are configurable, usually by "sourcing" something out of /etc/sysconfig/. And just to make an example specific - a file /lib/systemd/system/dhcpd.service has lines: EnvironmentFile=/etc/sysconfig/dhcpd ExecStart=/usr/sbin/dhcpd -d -user dhcpd -group dhcpd --no-pid $DHCPDARGS so I am able to modify how dhcpd is running by editing /etc/sysconfig/dhcpd. Just like with SysV init scritps. I read 'man systemd.socket' and 'man systemd.exec' and I do not see how I can in a similar way to modify what 'ListenStream=...' are especially that a number of those may vary. Unless I am missing something this looks to me like a serious design deficiency. That you can hack around that in not quite obvious way and with unexpected side-effects, if you are knowledgeable enough, does not change that. BTW - would you not think, just by looking at names, that user configuration changes can be found in /etc/systemd/user/ and not /etc/systemd/system/? 'systemctl' fills the later directory with its own stuff and essentially breaks if found some clashes with your own "additions". 'man systemd' claims that /usr/local/lib/systemd/system/ is checked too. Maybe that can be used? OTOH everybody will expect first that a configuration really can be found in some file from /etc/sysconfig/. Also socket configuration files in /etc/xinetd.d/ are marked "config".
(In reply to comment #26) > (In reply to comment #25) > > > SysV init scripts are not marked as %config(noreplace) in spec file, > > There is one HUGR difference. Those scripts are configurable, usually by > "sourcing" something out of /etc/sysconfig/. /etc/sysconfig/... usually configures daemon command line arguments only. That's not too much configuratin. You can change it in service file too, together with any other option. /etc/systemd/system/<daemon>.service: .include /lib/systemd/system/<daemon>.service [Service] ExecStart=..... but for example you can have some more complex configuration so your daemon now requires other service to be running. With SysV init, you can only change boot priority in /etc/init.d/<daemon> which gets overwritten on next update. For systemd, you can add After=<other>.service the same way as you can chage command line arguments. Btw, (afaik) /etc/systemd/<daemon> is going away, or at least it's going to be significantly reduced for compatibility, because other distros don't use it (not my decision, and I'm not 100% sure it's still valid). Anyway, if you have any other questions/comments about systemd, ask them in systemd mailing list systemd-devel.org I'm not a systemd developer, so my knowledge is not 100% accurate and bugzilla is not the best place for discussion.
(In reply to comment #27) > /etc/sysconfig/... usually configures daemon command line arguments only. > That's not too much configuratin. You mean with SysV init scripts? Not really correct. I may have there pieces of a shell code which I can source and/or set other variables which affect results of a startup script. A lot of flexibility. > Btw, (afaik) /etc/systemd/<daemon> is going away, or at least it's going to be > significantly reduced for compatibility, because other distros don't use it They seem to have good reasons to stay away from systemd. So far I failed to see any supposed benefits from it but only headaches, fragility and _longer_, or at least nothing close to shorter, boot times. > Anyway, if you have any other questions/comments about systemd, I was really concerned here how to address in a sane way, an accessible to "mere mortals", troubles with a configuration of dovecot.socket. Yes, I realize that this can be hacked around but you seem to imply that even those hacks will cease to work in the future. Anyway, if '.include' facility is available then why not to use it within /lib/systemd/system/dhcpd.socket in order not to hardwire a configuration there?
(In reply to comment #5) > I've fixed the first part, so it won't print those obsolete messages. For > socket activation, this is not fixed yet. Fixed now. If dovecot gets activated via socket, it closes all sockets that are not configured in dovecot config files.