Re: [systemd-devel] Failed to start up manager. Freezing execution.
To *run Linux from RAM *I have a hook that copies the contents of the root
device to a zram device. Here is a snip from the hook:
mkdir /real_root/
mount ${root} /real_root/
modprobe zram
zRAM__DEV=$(zramctl -f -fs $(free -m | awk '/Mem/ {print
int($2*2)"M"}') -a lzo -t $(nproc))
mkfs.ext2 -q ${zRAM__DEV}
.
.
.
mount --type auto ${zRAM__DEV} /new_root/
.
.
.
rsync \
--archive \
--acls \
--exclude boot \
--exclude dev \
--exclude mnt \
--exclude proc \
--exclude run \
--exclude sys \
--exclude tmp \
--exclude lost+found \
--verbose \
--xattrs \
--hard-links \
\
/real_root/ \
/new_root/ \
.
.
.
umount /real_root/
When I remove quiet from the boot parameters and activate the hook the only
addition to the Freezing message is:
*:: running cleanup hook [udev]*
*Welcome to Arch Linux!*
But it still freezes execution.
The rescue and emergency shells do not start if I activate the hook and
again it freezes.The shells do start, however, when the hook is not
activated.
On Mon, 24 Apr 2023 at 11:41, Lennart Poettering
wrote:
> On Fr, 21.04.23 18:36, Caeri Tech (caerit...@gmail.com) wrote:
>
> > I've been running Linux from RAM for a couple years without issue.
> > However, since the upgrade from 252 to 253 the load to RAM fails and the
> > computer hangs with the message below:
> >
> > [!!] Failed to start up manager.
> > [ 439.264894] systemd[1]: Freezing execution.
> >
> > What does this message mean and what new systemd 253 requirements do I
> > need to satisfy for the load to RAM to work as it did before?
>
> I am not sure "what running Linux from RAM" is precisely supposed to
> mean, but I am pretty sure the above message has little to do with
> amount of memory required. Enable debug output if output is too terse.
>
>
> https://freedesktop.org/wiki/Software/systemd/Debugging/#diagnosingbootproblems
>
> Lennart
>
> --
> Lennart Poettering, Berlin
>
Re: [systemd-devel] rc-local.service and its future in systemd?
If you'd still like to continue using /etc/rc.d/rc.local, and it would be enough for it to be executed "after boot", IOW, after the default runlevel at boot is reached, the following four commands might help you: $ cat >/tmp/order-last.conf < Did you test this yourself? I couldn't get it to work. If I don't disable systemd-rc-local-generator, it'll create a multi-user.target.wants for rc-local.service in /run/systemd. rc-local.service is also referenced in multiple other service files in /usr/lib/systemd/system. I arrived into this following config that is now working: 1) # /etc/systemd/system/rc-local.service.d/override.conf [Unit] After=systemd-user-sessions.service [Install] WantedBy=default.target 2) mkdir /root/systemd mv /usr/lib/systemd/system-generators/systemd-rc-local-generator /root/systemd/ ln -s /dev/null /usr/lib/systemd/system-generators/systemd-rc-local-generator 3) chmod 700 /etc/rc.d/rc.local systemctl enable rc-local.service As one Red Hat employee once said: "And I'm pretty sure that the people who still insist on using it would shout at us very loudly if rc-local.service were removed...". I hope rc-local.service can be kept in systemd in the future. Best regards, Aki P.S. My hunch was correct and rc.local is now (After=systemd-user-sessions.service) ran after crond. root1045 0.0 0.0 3272 1792 ?Ss 19:58 0:00 /usr/sbin/atd -f root1046 0.0 0.0 224304 3584 ?Ss 19:58 0:00 /usr/sbin/crond -n root1047 0.0 0.0 222940 3328 ?Ss 19:58 0:00 /bin/bash /etc/rc.d/rc.local start root1049 0.0 0.0 224692 3328 ?R19:58 0:00 \_ ps auxwwf root1050 0.0 0.0 238216 3200 ?S19:58 0:00 \_ sort -n -k 2,2 cat /etc/rc.d/rc.local #!/bin/bash date > /var/tmp/boot.ps ps auxwwf | sort -n -k 2,2 >> /var/tmp/boot.ps
Re: [systemd-devel] Failed to start up manager. Freezing execution.
On Fr, 21.04.23 18:36, Caeri Tech (caerit...@gmail.com) wrote: > I've been running Linux from RAM for a couple years without issue. > However, since the upgrade from 252 to 253 the load to RAM fails and the > computer hangs with the message below: > > [!!] Failed to start up manager. > [ 439.264894] systemd[1]: Freezing execution. > > What does this message mean and what new systemd 253 requirements do I > need to satisfy for the load to RAM to work as it did before? I am not sure "what running Linux from RAM" is precisely supposed to mean, but I am pretty sure the above message has little to do with amount of memory required. Enable debug output if output is too terse. https://freedesktop.org/wiki/Software/systemd/Debugging/#diagnosingbootproblems Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] rc-local.service and its future in systemd?
If you'd still like to continue using /etc/rc.d/rc.local, and it would be enough for it to be executed "after boot", IOW, after the default runlevel at boot is reached, the following four commands might help you: $ cat >/tmp/order-last.conf < Isn't that the same as running "systemctl edit rc-local.service" and then enter that config there? Best regards, Aki
Re: [systemd-devel] rc-local.service and its future in systemd?
Would it be possible to change the rc-local.service configuration as follows, so that it could be used similarly as before i.e. running close to the end of the "runlevel" or systemd target: [Unit] After=crond.service Why crond? Why is that the "end of the runlevel"? I checked the service startup after boot with "journalctl -b 0 -t systemd" and it showed crond starting near the end of the target. Is there some issue with setting rc-local.service for "After=systemd-update-utmp-runlevel.service" ? It caused that cyclic dependency problem. Best regards, Aki
Re: [systemd-devel] rc-local.service and its future in systemd?
On Mo, 24.04.23 13:01, Aki Ketolainen (a...@mykolab.com) wrote: >I tried to set After=systemd-update-utmp-runlevel.service but I got some >cyclic dependency problem. Would you know how to do that? s-u-u-r.s is a legacy service that will update utmp *after* all services that constitute a sysv runlevel-lookalike have started. If you order rc-local.service after that then you create a cyclic dependency, because it would mean s-u-u-r.s is both before *and* after rc-local.service and that cannot be. Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] rc-local.service and its future in systemd?
On Mon, Apr 24, 2023 at 01:20:09PM +0300, Aki Ketolainen wrote: > > as Lennart already told you in the GitHub issue that "last" just doesn't > > make sense in systemd, there is also no need to change the dependencies > > global for everyone. Especially as there are systems out there which > > doesn't have crond installed (because there are .timer). > > > > Your best bet is really to change all your custom scripts from rc.local > > into proper .service and instead of crond check out systemd.timer. > > > > BR > > Silvio > > I tried to set After=systemd-update-utmp-runlevel.service but I got some > cyclic dependency problem. Would you know how to do that? > > Best regards, > > Aki If you'd still like to continue using /etc/rc.d/rc.local, and it would be enough for it to be executed "after boot", IOW, after the default runlevel at boot is reached, the following four commands might help you: $ cat >/tmp/order-last.conf < signature.asc Description: PGP signature
Re: [systemd-devel] rc-local.service and its future in systemd?
On Mo, 24.04.23 11:57, Aki Ketolainen (a...@mykolab.com) wrote: > Would it be possible to change the rc-local.service configuration as > follows, so that it could be used similarly as before > i.e. running close to the end of the "runlevel" or systemd target: > > [Unit] > After=crond.service Why crond? Why is that the "end of the runlevel"? It's 2023, thinking in concepts such as "runlevels" is like so last decade... Quite frankly, at this point if we make changes to rc-local.service we probably should just remove it altogether. The semantics are just too vague and undefined. For example anything long-running forked off it just lives in an unsupervised netherworld that is not how things should be done in 2023. Note that you can easily order rc-local.service after whatever service you like locally via: mkdir -p /etc/systemd/system/rc-local.service.d/ cat > /etc/systemd/system/rc-local.service.d/50-after-crond.conf <
Re: [systemd-devel] rc-local.service and its future in systemd?
> > This totally depends on the unit you wrote. Without it, we can't help. In general, ignore and forget the run level concept. > > BR > > Silvio > > I only changed these settings in rc-local.service: > > > [Unit] > After=systemd-update-utmp-runlevel.service > > [Install] > WantedBy=default.target > > and disabled /usr/lib/systemd/system-generators/systemd-rc-local-generator from running. > When I tried to boot, the system didn't come up any more. > Well, you created a circular dependency. Just don't use the rc-local.service at all, but put the commands from there in their own .service units. Think about their dependencies and order Proper with Wants=, Before= and After=. If you're able to share your rc.local script, than we can help. The cyclic dependency problem doesn't come from the rc.local file, but from systemd. I only run one simple command in it. Best regards, Aki
Re: [systemd-devel] rc-local.service and its future in systemd?
Am 24.04.2023 um 12:52 schrieb Aki Ketolainen : >> This totally depends on the unit you wrote. Without it, we can't help. In >> general, ignore and forget the run level concept. >> BR >> Silvio > > I only changed these settings in rc-local.service: > > [Unit] > After=systemd-update-utmp-runlevel.service > > [Install] > WantedBy=default.target > > and disabled /usr/lib/systemd/system-generators/systemd-rc-local-generator > from running. > When I tried to boot, the system didn't come up any more. Well, you created a circular dependency. Just don't use the rc-local.service at all, but put the commands from there in their own .service units. Think about their dependencies and order Proper with Wants=, Before= and After=. If you're able to share your rc.local script, than we can help.
Re: [systemd-devel] rc-local.service and its future in systemd?
> I tried to set After=systemd-update-utmp-runlevel.service but I got some cyclic dependency problem. Would you know how to do that? > > Best regards, > > Aki > This totally depends on the unit you wrote. Without it, we can't help. In general, ignore and forget the run level concept. BR Silvio I only changed these settings in rc-local.service: [Unit] After=systemd-update-utmp-runlevel.service [Install] WantedBy=default.target and disabled /usr/lib/systemd/system-generators/systemd-rc-local-generator from running. When I tried to boot, the system didn't come up any more. Best regards, Aki
Re: [systemd-devel] rc-local.service and its future in systemd?
> Am 24.04.2023 um 12:20 schrieb Aki Ketolainen : > >> as Lennard already told you in the GitHub issue that "last" just doesn't >> make sense in systemd, there is also no need to change the dependencies >> global for everyone. Especially as there are systems out there which doesn't >> have crond installed (because there are .timer). >> Your best bet is really to change all your custom scripts from rc.local into >> proper .service and instead of crond check out systemd.timer. >> BR >> Silvio > > I tried to set After=systemd-update-utmp-runlevel.service but I got some > cyclic dependency problem. Would you know how to do that? > > Best regards, > > Aki This totally depends on the unit you wrote. Without it, we can't help. In general, ignore and forget the run level concept. BR Silvio
Re: [systemd-devel] rc-local.service and its future in systemd?
as Lennard already told you in the GitHub issue that "last" just doesn't make sense in systemd, there is also no need to change the dependencies global for everyone. Especially as there are systems out there which doesn't have crond installed (because there are .timer). Your best bet is really to change all your custom scripts from rc.local into proper .service and instead of crond check out systemd.timer. BR Silvio I tried to set After=systemd-update-utmp-runlevel.service but I got some cyclic dependency problem. Would you know how to do that? Best regards, Aki
Re: [systemd-devel] rc-local.service and its future in systemd?
I tried to set After=systemd-update-utmp-runlevel.service but I got some cyclic dependency problem. Would you know how to do that?Best regards,AkiOn Apr 24, 2023 12:24 PM, killermoe...@gmx.net wrote:
Re: [systemd-devel] rc-local.service and its future in systemd?
> Am 24.04.2023 um 10:57 schrieb Aki Ketolainen : > > Hi, > I noticed in Rocky Linux 8.7 LXC container image that they've added a message > to /etc/rc.d/rc.local: > # In contrast to previous versions due to parallel execution during boot > # this script will NOT be run after all other services. > I created an issue report on this at github: > https://github.com/systemd/systemd/issues/27340 > "How to run /etc/rc.d/rc.local as the last Linux bootup task?" > Would it be possible to change the rc-local.service configuration as follows, > so that it could be used similarly as before > i.e. running close to the end of the "runlevel" or systemd target: > [Unit] > After=crond.service > [Install] > WantedBy=default.target > chmod 700 /etc/rc.d/rc.local > systemctl enable rc-local.service > I tested this and see in ps output (ps auxwwf | sort -n -k 2,2 >> > /var/tmp/boot.ps) that it starts after crond > in both multi-user.target and graphical.target. > Best regards, > Aki Hi Aki, as Lennard already told you in the GitHub issue that "last" just doesn't make sense in systemd, there is also no need to change the dependencies global for everyone. Especially as there are systems out there which doesn't have crond installed (because there are .timer). Your best bet is really to change all your custom scripts from rc.local into proper .service and instead of crond check out systemd.timer. BR Silvio
Re: [systemd-devel] rc-local.service and its future in systemd?
I forgot to add that I also disabled /usr/lib/systemd/system-generators/systemd-rc-local-generator from running as it added rc-local.service to multi-user.target (in /run/systemd).Best regards,AkiOn Apr 24, 2023 11:57 AM, Aki Ketolainen wrote:
[systemd-devel] rc-local.service and its future in systemd?
Hi, I noticed in Rocky Linux 8.7 LXC container image that they've added a message to /etc/rc.d/rc.local: # In contrast to previous versions due to parallel execution during boot # this script will NOT be run after all other services. I created an issue report on this at github: https://github.com/systemd/systemd/issues/27340 "How to run /etc/rc.d/rc.local as the last Linux bootup task?" Would it be possible to change the rc-local.service configuration as follows, so that it could be used similarly as before i.e. running close to the end of the "runlevel" or systemd target: [Unit] After=crond.service [Install] WantedBy=default.target chmod 700 /etc/rc.d/rc.local systemctl enable rc-local.service I tested this and see in ps output (ps auxwwf | sort -n -k 2,2 >> /var/tmp/boot.ps) that it starts after crond in both multi-user.target and graphical.target. Best regards, Aki
Re: [systemd-devel] Resource limits getting enforced only for processes in user's terminal not for su [user] from root's terminal
On Mon, Apr 24, 2023 at 7:04 AM jaimin bhaduri wrote:
> Cgroups v2 is enabled in almalinux 9.1 with 5.14.0-70.22.1.el9_0.x86_64
> kernel and systemd 250 (250-12.el9_1.3).
>
> Content of /etc/systemd/system/user-1002.slice.d/override.conf:
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *[Unit]Description=User Slice for UID
> 1002[Slice]CPUAccounting=1MemoryAccounting=1IOAccounting=1TasksAccounting=1CPUQuota=70%MemoryMax=1GMemoryHigh=1GIOReadBandwidthMax=/
> 1GIOWriteBandwidthMax=/ 1GIOReadIOPSMax=/ 1000IOWriteIOPSMax=/
> 1000TasksMax=200[Install]WantedBy=multi-user.target*
>
> I execute systemctl daemon-reload after saving the slice file.
> Every value is getting enforced for the user when I test them by running
> some commands from the user's terminal.
> But they dont work after I run the same commands from the root's terminal
> after doing su to that user.
> They also dont work when a user's process is started from a php script
> using putenv('user_uid');.
> How do I make them work for all the user's processes no matter how they
> start?
>
Using cgroup-based limits means that something needs to actually *move* the
process into the appropriate cgroup. (They are not uid-based limits!)
As php-fpm does not support cgroup management on its own, you might need to
run multiple instances of php-fpm@.service (not just multiple pools in the
same instance), each instance specifying "Slice=user-%i.slice" similar to
how user@.service does it.
For `su`, you would need to configure its PAM stack to invoke pam_systemd,
but this is usually *deliberately* not done, as doing so would cause other
issues, especially for scripts that use `su` for non-interactive purposes.
(Besides that, systemd-logind does not allow creating a new session from
within another one, so the only time `su` would be allowed to do this is
exactly the time when it would be undesirable...)
Instead, `machinectl shell foo@` or `systemd-run --user -M foo@.host --pty
...` could be used if you need to manually run something as another user
(but as soon you need to do it twice, you should just make a .service with
Slice=, or even a --user service).
--
Mantas Mikulėnas
