[prev in list] [next in list] [prev in thread] [next in thread] 

List:       debian-user
Subject:    Re: Some services cannot start at boot time because /run is not initialized
From:       Kenneth Parker <sea7kenp () gmail ! com>
Date:       2021-04-22 15:27:42
Message-ID: CAFZQJ16fi03CFdVrzXsXGOobVpognaWjWFSoZyYBtJskyk9ugA () mail ! gmail ! com
[Download RAW message or body]

On Thu, Apr 22, 2021, 8:26 AM Dmitry Katsubo <dma_k@mail.ru> wrote:

> Dear Debian community,
>
> I have noticed that all failed services were missing some directories
> under /run directory. I checked the service which is supposed to create
> them:
>
> *  systemd-tmpfiles-setup.service - Create Volatile Files and Directories
>    Loaded: loaded (/lib/systemd/system/systemd-tmpfiles-setup.service;
> static; vendor preset: enabled)
>    Active: inactive (dead)
>      Docs: man:tmpfiles.d(5)
>            man:systemd-tmpfiles(8)
>
> systemd[1]: sysinit.target: Found ordering cycle on
> systemd-tmpfiles-setup.service/start
> systemd[1]: sysinit.target: Found dependency on local-fs.target/start
> systemd[1]: sysinit.target: Found dependency on zram-setup@zram1.service
> /start
> systemd[1]: sysinit.target: Found dependency on sysinit.target/start
> systemd[1]: sysinit.target: Job systemd-tmpfiles-setup.service/start
> deleted to break ordering cycle starting with sysinit.target/start
>
> and it looks like there is problem in zram-setup@zram1.service which I
> configured like that:
>
> [Unit]
> Requires=dev-%i.device
> After=dev-%i.device
> Before=local-fs.target
> [Install]
> WantedBy=local-fs.target
>
> # systemctl show -p Requires,Wants,Requisite,BindsTo,PartOf,Before,After
> local-fs.target
> Requires=home.mount -.mount var.mount
> Requisite=
> Wants=systemd-fsck-root.service zram-setup@zram0.service
> zram-setup@zram1.service systemd-remount-fs.service
> BindsTo=
> PartOf=
> Before=binfmt-support.service sysinit.target
> systemd-machine-id-commit.service systemd-tmpfiles-setup.service
> networking.service systemd-tmpfiles-clean.service console-setup.service
> After=run-user-1000.mount zram-setup@zram0.service root.mount -.mount
> tmp.mount zram-setup@zram1.service systemd-fsck-root.service
> systemd-remount-fs.service home.mount var.mount local-fs-pre.target
>
> Even though I don't see any conflict with dependencies, it is confusing
> systemd.
>
> Any idea concerning how to fix that is welcomed.
>

Is Debian using Zram now?  (I will need to check my Bullseye system when I
get home).

A couple of years (or so) ago, Ubuntu inflicted Zram on me without advanced
notice, on a system with only 4G Ram, leaving me with nothing to run my
system on.  Needless to say, after I troubleshooted it, I banned Zram on
any future Ubuntu systems.

So is Debian "sneaking" Zram on us, or do you have to select it yourself?

>
> On 2020-06-29 01:37, Dmitry Katsubo wrote:
> > Dear Debian community,
> >
> > I hit the similar problem but this time with /run folder. Few services
> have
> > failed to start:
> >
> > # systemctl status php7.0-fpm.service
> > Jun 24 23:09:48 debian php-fpm7.0[893]: [24-Jun-2020 23:09:48] ERROR:
> unable to bind listening socket for address '/run/php/php7.0-fpm.sock': No
> such file or directory (2)
> > Jun 24 23:09:48 debian php-fpm7.0[893]: [24-Jun-2020 23:09:48] ERROR:
> FPM initialization failed
> > Jun 24 23:09:48 debian systemd[1]: php7.0-fpm.service: Main process
> exited, code=exited, status=78/CONFIG
> > Jun 24 23:09:48 debian systemd[1]: php7.0-fpm.service: Failed with
> result 'exit-code'.
> > Jun 24 23:09:48 debian systemd[1]: Failed to start The PHP 7.0 FastCGI
> Process Manager.
> >
> > # systemctl status motioneye.service
> > Jun 24 23:09:47 debian systemd[1]: Started motionEye Server.
> > Jun 24 23:09:48 debian meyectl[895]:     INFO: hello! this is motionEye
> server 0.41
> > Jun 24 23:09:48 debian meyectl[895]: CRITICAL: pid directory
> "/run/motioneye" does not exist or is not writable
> > Jun 24 23:09:48 debian systemd[1]: motioneye.service: Main process
> exited, code=exited, status=255/EXCEPTION
> > Jun 24 23:09:48 debian systemd[1]: motioneye.service: Failed with result
> 'exit-code'.
> >
> > # cat /etc/tmpfiles.d/php.conf
> > d /run/php/sessions 1733 root root
> >
> > # cat /etc/tmpfiles.d/motioneye.conf
> > d /run/motioneye 0750 motion motion
> >
> > Just after the boot I have inspected /run folder. It was created/mounted
> > correctly and there have been a lot of files/directories there. I
> suspect that
> > all services that have created the necessary directory under /run were
> able to
> > start normally. Few of them which relied on existence of specific
> directory,
> > have failed to started. After I have replayed the corresponding
> instructions for
> > tmpfiles.d, the services have started normally.
> >
> > I have a feeling that systemd-tmpfiles was executed before /run was
> mounted.
> >
> > Needless to note that the problem is not persistent: sometimes OS boots
> without
> > a single failed service.
> >
> > How can I debug the problem?
> >
> > Thank you!
> >
> > On 2020-05-18 02:39, Dmitry Katsubo wrote:
> >> On 2020-05-11 20:11, Darac Marjal wrote:
> >>> On 11/05/2020 08:40, Reco wrote:
> >>>>    Hi.
> >>>>
> >>>> On Mon, May 11, 2020 at 09:33:59AM +0200, Dmitry Katsubo wrote:
> >>>>
> >>>>> root@debian:~ # systemctl status binfmt-support
> >>>>> *  binfmt-support.service - Enable support for additional executable
> binary formats
> >>>>>    Loaded: loaded (/lib/systemd/system/binfmt-support.service;
> enabled; vendor preset: enabled)
> >>>>>    Active: failed (Result: exit-code) since Sun 2020-05-10 21:54:27
> CEST; 10h ago
> >>>>>      Docs: man:update-binfmts(8)
> >>>>>   Process: 353 ExecStart=/usr/sbin/update-binfmts --enable
> (code=exited, status=2)
> >>>>>  Main PID: 353 (code=exited, status=2)
> >>>>>
> >>>>> May 10 21:54:27 debian update-binfmts[353]: update-binfmts: unable
> to open /var/lib/binfmts: No such file or directory
> >>>>>
> >>>>> Any help is appreciated.
> >>>> This should help your problem:
> >>>>
> >>>> mkdir /etc/systemd/system/binfmt-support.service.d
> >>>>
> >>>> cat > /etc/systemd/system/binfmt-support.service.d/override.conf <<
> EOF
> >>>> [Unit]
> >>>> RequiresMountsFor=/var
> >>>> EOF
> >>>
> >>> As another alternative, one can run "systemctl edit
> >>> binfmt-support.service", which will create the intervening folders and
> >>> files for you, and reload the daemon if the editor exits with success.
> >>
> >> Thanks for suggestion! I have tried the advise and it actually worked
> >> (I will keep an eye on that because one reboot may not be
> representative).
> >> I wonder nevertheless what is the problem with this specific unit? It
> has
> >> dependency on local-fs.target which in turn should mount /var. So what
> >> exactly went wrong?
>
>
> --
> With best regards,
> Dmitry
>

Kenneth Parker

>

[Attachment #3 (text/html)]

<div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr" \
class="gmail_attr">On Thu, Apr 22, 2021, 8:26 AM Dmitry Katsubo &lt;<a \
href="mailto:dma_k@mail.ru">dma_k@mail.ru</a>&gt; wrote:<br></div><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex">Dear Debian community,<br> <br>
I have noticed that all failed services were missing some directories under /run \
directory. I checked the service which is supposed to create them:<br> <br>
*   systemd-tmpfiles-setup.service - Create Volatile Files and Directories<br>
     Loaded: loaded (/lib/systemd/system/systemd-tmpfiles-setup.service; static; \
vendor preset: enabled)<br>  Active: inactive (dead)<br>
        Docs: man:tmpfiles.d(5)<br>
                 man:systemd-tmpfiles(8)<br>
<br>
systemd[1]: sysinit.target: Found ordering cycle on \
systemd-tmpfiles-setup.service/start<br> systemd[1]: sysinit.target: Found dependency \
on local-fs.target/start<br> systemd[1]: sysinit.target: Found dependency on \
zram-setup@zram1.service/start<br> systemd[1]: sysinit.target: Found dependency on \
sysinit.target/start<br> systemd[1]: sysinit.target: Job \
systemd-tmpfiles-setup.service/start deleted to break ordering cycle starting with \
sysinit.target/start<br> <br>
and it looks like there is problem in zram-setup@zram1.service which I configured \
like that:<br> <br>
[Unit]<br>
Requires=dev-%i.device<br>
After=dev-%i.device<br>
Before=local-fs.target<br>
[Install]<br>
WantedBy=local-fs.target<br>
<br>
# systemctl show -p Requires,Wants,Requisite,BindsTo,PartOf,Before,After \
local-fs.target<br> Requires=home.mount -.mount var.mount<br>
Requisite=<br>
Wants=systemd-fsck-root.service zram-setup@zram0.service zram-setup@zram1.service \
systemd-remount-fs.service<br> BindsTo=<br>
PartOf=<br>
Before=binfmt-support.service sysinit.target systemd-machine-id-commit.service \
systemd-tmpfiles-setup.service networking.service systemd-tmpfiles-clean.service \
console-setup.service<br> After=run-user-1000.mount zram-setup@zram0.service \
root.mount -.mount tmp.mount zram-setup@zram1.service systemd-fsck-root.service \
systemd-remount-fs.service home.mount var.mount local-fs-pre.target<br> <br>
Even though I don&#39;t see any conflict with dependencies, it is confusing \
systemd.<br> <br>
Any idea concerning how to fix that is welcomed.<br></blockquote></div></div><div \
dir="auto"><br></div><div dir="auto">Is Debian using Zram now?   (I will need to \
check my Bullseye system when I get home).  </div><div dir="auto"><br></div><div \
dir="auto">A couple of years (or so) ago, Ubuntu inflicted Zram on me without \
advanced notice, on a system with only 4G Ram, leaving me with nothing to run my \
system on.   Needless to say, after I troubleshooted it, I banned Zram on any future \
Ubuntu systems.  </div><div dir="auto"><br></div><div dir="auto">So is Debian \
&quot;sneaking&quot; Zram on us, or do you have to select it yourself?  </div><div \
dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 \
0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <br>
On 2020-06-29 01:37, Dmitry Katsubo wrote:<br>
&gt; Dear Debian community,<br>
&gt; <br>
&gt; I hit the similar problem but this time with /run folder. Few services have<br>
&gt; failed to start:<br>
&gt; <br>
&gt; # systemctl status php7.0-fpm.service<br>
&gt; Jun 24 23:09:48 debian php-fpm7.0[893]: [24-Jun-2020 23:09:48] ERROR: unable to \
bind listening socket for address &#39;/run/php/php7.0-fpm.sock&#39;: No such file or \
directory (2)<br> &gt; Jun 24 23:09:48 debian php-fpm7.0[893]: [24-Jun-2020 23:09:48] \
ERROR: FPM initialization failed<br> &gt; Jun 24 23:09:48 debian systemd[1]: \
php7.0-fpm.service: Main process exited, code=exited, status=78/CONFIG<br> &gt; Jun \
24 23:09:48 debian systemd[1]: php7.0-fpm.service: Failed with result \
&#39;exit-code&#39;.<br> &gt; Jun 24 23:09:48 debian systemd[1]: Failed to start The \
PHP 7.0 FastCGI Process Manager.<br> &gt; <br>
&gt; # systemctl status motioneye.service<br>
&gt; Jun 24 23:09:47 debian systemd[1]: Started motionEye Server.<br>
&gt; Jun 24 23:09:48 debian meyectl[895]:        INFO: hello! this is motionEye \
server 0.41<br> &gt; Jun 24 23:09:48 debian meyectl[895]: CRITICAL: pid directory \
&quot;/run/motioneye&quot; does not exist or is not writable<br> &gt; Jun 24 23:09:48 \
debian systemd[1]: motioneye.service: Main process exited, code=exited, \
status=255/EXCEPTION<br> &gt; Jun 24 23:09:48 debian systemd[1]: motioneye.service: \
Failed with result &#39;exit-code&#39;.<br> &gt; <br>
&gt; # cat /etc/tmpfiles.d/php.conf<br>
&gt; d /run/php/sessions 1733 root root<br>
&gt; <br>
&gt; # cat /etc/tmpfiles.d/motioneye.conf<br>
&gt; d /run/motioneye 0750 motion motion<br>
&gt; <br>
&gt; Just after the boot I have inspected /run folder. It was created/mounted<br>
&gt; correctly and there have been a lot of files/directories there. I suspect \
that<br> &gt; all services that have created the necessary directory under /run were \
able to<br> &gt; start normally. Few of them which relied on existence of specific \
directory,<br> &gt; have failed to started. After I have replayed the corresponding \
instructions for<br> &gt; tmpfiles.d, the services have started normally.<br>
&gt; <br>
&gt; I have a feeling that systemd-tmpfiles was executed before /run was mounted.<br>
&gt; <br>
&gt; Needless to note that the problem is not persistent: sometimes OS boots \
without<br> &gt; a single failed service.<br>
&gt; <br>
&gt; How can I debug the problem?<br>
&gt; <br>
&gt; Thank you!<br>
&gt; <br>
&gt; On 2020-05-18 02:39, Dmitry Katsubo wrote:<br>
&gt;&gt; On 2020-05-11 20:11, Darac Marjal wrote:<br>
&gt;&gt;&gt; On 11/05/2020 08:40, Reco wrote:<br>
&gt;&gt;&gt;&gt;      Hi.<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; On Mon, May 11, 2020 at 09:33:59AM +0200, Dmitry Katsubo wrote:<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; root@debian:~ # systemctl status binfmt-support<br>
&gt;&gt;&gt;&gt;&gt; *   binfmt-support.service - Enable support for additional \
executable binary formats<br> &gt;&gt;&gt;&gt;&gt;      Loaded: loaded \
(/lib/systemd/system/binfmt-support.service; enabled; vendor preset: enabled)<br> \
&gt;&gt;&gt;&gt;&gt;      Active: failed (Result: exit-code) since Sun 2020-05-10 \
21:54:27 CEST; 10h ago<br> &gt;&gt;&gt;&gt;&gt;         Docs: \
man:update-binfmts(8)<br> &gt;&gt;&gt;&gt;&gt;     Process: 353 \
ExecStart=/usr/sbin/update-binfmts --enable (code=exited, status=2)<br> \
&gt;&gt;&gt;&gt;&gt;   Main PID: 353 (code=exited, status=2)<br> \
&gt;&gt;&gt;&gt;&gt;<br> &gt;&gt;&gt;&gt;&gt; May 10 21:54:27 debian \
update-binfmts[353]: update-binfmts: unable to open /var/lib/binfmts: No such file or \
directory<br> &gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; Any help is appreciated.<br>
&gt;&gt;&gt;&gt; This should help your problem:<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; mkdir /etc/systemd/system/binfmt-support.service.d<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; cat &gt; /etc/systemd/system/binfmt-support.service.d/override.conf \
&lt;&lt; EOF<br> &gt;&gt;&gt;&gt; [Unit]<br>
&gt;&gt;&gt;&gt; RequiresMountsFor=/var<br>
&gt;&gt;&gt;&gt; EOF<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; As another alternative, one can run &quot;systemctl edit<br>
&gt;&gt;&gt; binfmt-support.service&quot;, which will create the intervening folders \
and<br> &gt;&gt;&gt; files for you, and reload the daemon if the editor exits with \
success.<br> &gt;&gt;<br>
&gt;&gt; Thanks for suggestion! I have tried the advise and it actually worked<br>
&gt;&gt; (I will keep an eye on that because one reboot may not be \
representative).<br> &gt;&gt; I wonder nevertheless what is the problem with this \
specific unit? It has<br> &gt;&gt; dependency on local-fs.target which in turn should \
mount /var. So what<br> &gt;&gt; exactly went wrong?<br>
<br>
<br>
-- <br>
With best regards,<br>
Dmitry  <br></blockquote></div></div><div dir="auto"><br></div><div \
dir="auto">Kenneth Parker  </div><div dir="auto"><div class="gmail_quote"><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"></blockquote></div></div></div>



[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic