> Does it also move "systemd-ask-password" to -extra?
Yes, systemd-ask-password is/was also part of systemd-extra-utils, along with
several other files.
> For a distro that targets embedded devices (i.e. where services aren't going
> to use
> systemd's ask-password facility because nobody will
>> Any comment on my other question: is systemd-tty-ask-password an optional
>> component?
>
> It is optional. You can skip it with --no-ask-password. If you did not,
> it is assumed you wanted password agent and the warning is correct. It
> is just a message, systemctl does not fail if it could
> Is systemd-tty-ask-password real or a typo?
Sorry, I meant systemd-tty-ask-password-agent.
I dropped “-agent” by mistake (at least I had it right in the subject).
> Also if you're already in a root session, why is it asking for more
> authentication?
I suspect some services need to query for
>>> Is systemd-tty-ask-password still an optional component?
>>>
>>> Is this new behaviour (where systemd-tty-ask-password is repeatedly
>>> executed) intentional?
>>
>> It is not new behavior. systemctl did it for as long as I remember.
>
> Okay. But the display of the warning is new behaviour.
>> Is systemd-tty-ask-password still an optional component?
>>
>> Is this new behaviour (where systemd-tty-ask-password is repeatedly
>> executed) intentional?
>
> It is not new behavior. systemctl did it for as long as I remember.
Okay. But the display of the warning is new behaviour.
Was the
I upgraded from v255.4 to v255.13 (these are tags from
https://github.com/systemd/systemd-stable), I now see the following warning
when I manually start a service:
root@vbox:~/tmp# systemctl start systemd-journald
Failed to execute /usr/bin/systemd-tty-ask-password-agent: No such file or
direct
> > Is there a conf option or an environment variable I can use to disable the
> > unsafe path transition check?
>
> No there is not. It's a security hole what you are doing there...
>
> > Failing that, is there a way I can change the ownership systemd-tmpfiles
> > sees?
>
> Why not just fix the
I am doing dev work on a linux system and I am mounting the root filesystem via
NFS to make my work-flow easier.
Unfortunately, the directory I am NFS mounting is not owned by root, and this
causes some of the directives processed by the systemd-tmpfiles utility during
boot (e.g. in systemd-tmp
> > I think the SIGHUP must come from the new PID 1.
>
> I don't know if this will help you, however here is a program that I
> wrote last year that starts a service in the initramfs, it survives
> the systemd killing spree during the transition to the root
> filesystem, a new copy of the program i
> > It is not clear to me if the '@' is necessary because the process is
> > invoked using the "init" kernel parameter.
>
> That detail doesn't matter. It's irrelevant how the process gets
> started. In particular as I understand you you fork()ed once,
> i.e. init= starts PID 1, but this is not PID
> > I have a program, init-jm, that forks and executes
> > /usr/lib/systemd/systemd in the parent (using execl() ) while the
> > child collects some stats in a loop.
>
> Uh, you can do this, but it's not trivial to get right: you need to
> move yourself down the cgroup tree, because otherwise you'l
> I suspect that your process has a controlling tty based on this comment
> in the killall() function at src/shared/killall.c:
>
>if (send_sighup) {
>/* Optionally, also send a SIGHUP signal, but only if the process
> has a controlling
> * tty. This is useful to allow h
I have a program, init-jm, that forks and executes /usr/lib/systemd/systemd in
the parent (using execl() ) while the child collects some stats in a loop.
The child sets its argv[0][0] to ‘@’.
init-jm is invoked using the “init” kernel parameter on a switch-root system
(it’s Fedora 41).
Can som
> Isn't systemd-bootchart, like, dead? Last release is nine years old or so.
The last release of systemd-bootchart, v235, was done in November 2023:
https://github.com/systemd/systemd-bootchart/tags
There hasn’t been much activity lately, but I wouldn’t call it dead (there are
a few PRs open th
> I opened https://github.com/systemd/systemd-bootchart/issues/58 to track
> this.
Could someone explain why systemd-bootchart is being sent SIGHUP?
Changing systemd-bootchart to ignore that signal isn’t difficult, but I would
like to understand why PID 1 is sending it.
Note that systemd-boot
> **1. systemd-bootchart stops too early**
>
> According to "man systemd-bootchart", the recommended way to invoke bootchart
> is via a kernel parameter:
>
> init=/usr/lib/systemd/systemd-bootchart
>
> That parameter causes systemd-bootchart to be executed as the new init
> process when we swit
Is anyone else using systemd-bootchart on a system that boots using an initial
ramdisk? (e.g. like Fedora 41)
I am fighting with two issues and am looking for some advice.
**1. systemd-bootchart stops too early**
According to “man systemd-bootchart”, the recommended way to invoke bootchart
i
> > > > Hi everyone,
> > > >
> > > > The system manager (as of v253) executes generators in a sandbox with a
> > > > fresh tmpfs mount on /tmp:
> > > >
> > > >
> > > > https://github.com/systemd/systemd/blob/a526b9ddfc03a290f20a65c0a73792e73029f1b8/src/core/manager.c#L4274
> > > >
> > > > Looki
> > Hi everyone,
> >
> > The system manager (as of v253) executes generators in a sandbox with a
> > fresh tmpfs mount on /tmp:
> >
> >
> > https://github.com/systemd/systemd/blob/a526b9ddfc03a290f20a65c0a73792e73029f1b8/src/core/manager.c#L4274
> >
> > Looking at the code, it appears that ther
Hi everyone,
The system manager (as of v253) executes generators in a sandbox with a fresh
tmpfs mount on /tmp:
https://github.com/systemd/systemd/blob/a526b9ddfc03a290f20a65c0a73792e73029f1b8/src/core/manager.c#L4274
Looking at the code, it appears that there is no way to disable that using
20 matches
Mail list logo
