systemd timeout on startup after upgrade

[Jean-Daniel]

systemd don’t need pid files, and the executable must be started without forking.


Can you show us the content fo the system dovecot.service file. As long as it contains this line, it should be fine:

Type=simple
ExecStart=/usr/sbin/dovecot -F



> Le 18 avr. 2021 à 07:34, Felix Zielcke <fzielcke at z-51.de> a écrit :
> 
> Am Sonntag, dem 18.04.2021 um 01:04 +0200 schrieb Łukasz Szczepański:
>> If systemd doesn't recognize that service has started, that mean
>> probably pid file has other location than previously.
>> You can check what systemd is doing via strace:
>> 
>> strace -s 1024 systemctl start dovecot
>> 
> 
> strace doestn't show anything about opening a pid file.
> 
> There's a few repeated of these:
> 
> recvmsg(3, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="/org/freedesktop/systemd1/unit/dovecot_2eservice\0\0\0\0\0\0\0\0\2\1s\0\37\0\0\0org.freedesktop.DBus.Properties\0\3\1s\0\21\0\0\0PropertiesChanged\0\0\0\0\0\0\0\7\1s\0\30\0\0\0org.freedesktop.systemd1\0\0\0\0\0\0\0\0\10\1g\0\10sa{sv}as\0\0\0\35\0\0\0org.freedesktop.systemd1.Unit\0\0\0d\3\0\0\v\0\0\0ActiveState\0\1s\0\0\10\0\0\0inactive\0\0\0\0\0\0\0\0\f\0\0\0FreezerState\0\1s\0\7\0\0\0running\0\10\0\0\0SubState\0\1s\0\4\0\0\0dead\0\0\0\0\0\0\0\0\24\0\0\0StateChangeTimestamp\0\1t\0\0\0\0\0\5\252\316m8\300\5\0\35\0\0\0StateChangeTimestampMonotonic\0\1t\0\0\0\0\357v\2604\r\0\0\0\25\0\0\0InactiveExitTimestamp\0\1t\0\0\0\0\214kJZ8\300\5\0\36\0\0\0InactiveExitTimestampMonotonic\0\1t\0\0\0v8,!\r\0\0\0\24\0\0\0ActiveEnterTimestamp\0\1t\0\0\0\0\0\0\0\0\0\0\0\0\0\35\0\0\0ActiveEnterTimestampMonotonic\0\1t\0\0\0\0\0\0\0\0\0\0\0\0\23\0\0\0ActiveExitTimestamp\0\1t\0\0\0\0\0\0\0\0\0\0\0\0\0\0\34\0\0\0ActiveExitTimestampMonotonic\0\1t\0\0\0\0\0\0\0\0\0\0\0\0\0\26\0\0\0InactiveEnterTimestamp\0\1t\0\0\0\5\252\316m8\300\5\0\37\0\0\0InactiveEnterTimestampMonotonic\0\1t\0\0\357v\2604\r\0\0\0\3\0\0\0Job\0\4(uo)\0\0\0\207\360\0\0#\0\0\0/org/freedesktop/systemd1/job/61575\0\0\0\0\0\17\0\0\0ConditionResult\0\1b\0\0\1\0\0\0\0\0\0\0\f\0\0\0AssertResult\0\1b\0\1\0\0\0\22\0\0\0ConditionTimestamp\0\1t\0\0\0\0\0\0\0005l\nn8\300\5\0\33\0\0\0ConditionTimestampMonotonic\0\1t\0\0\0\0\0\0\379\3544\r\0\0\0\17\0\0\0AssertTimestamp\0\1t\0\08l\nn8\300\5\0\30\0\0\0AssertTimest"..., iov_len=1124}], msg_iovlen=1, msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC}, MSG_DONTWAIT|MSG_CMSG_CLOEXEC) = 1124
> recvmsg(3, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="l\4\1\0013\3\0\0\7\0\0\0\276\0\0\0\1\1o\0000\0\0\0", iov_len=24}], msg_iovlen=1, msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC}, MSG_DONTWAIT|MSG_CMSG_CLOEXEC) = 24
> 
> And then it ends in a loop with a failing
> 
> recvmsg(3, {msg_namelen=0}, MSG_DONTWAIT|MSG_CMSG_CLOEXEC) = -1 EAGAIN (Die Ressource ist zur Zeit nicht verfügbar)
> 
> The strange thing is, that strace mentions then even php7.4-fpm. Which should have nothing to do with the `systemctl start dovecot`?
> 
> Anyone here has a bullseye system where this works?
> Maybe I also should report this to the Debian BTS.
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://dovecot.org/pipermail/dovecot/attachments/20210418/b47ae417/attachment.html>