Re: [systemd-devel] Systemd killed processes of custom services instead of graceful shutdown
17.06.2020 07:46, Kamal Rathi пишет: >> Please take at least some efforts to format mail so that it can be >> properly understood. Otherwise I am afraid your mails will simply be >> ignored. > >I am sorry for inconvenience, i will try to follow correct approach > afterwards while replying > >> How RemainAfterExit affects *startup* of services? > > The services worked as expected and as i fixed the issue where it was > using su in script. > As in background there was SysVinit script which was getting invoked > when system boot and makes processes falls in users.slice > So the startup is working perfectly after disabling that SysVinit > script. > >> So I was right. Your programs are running as user services or part of >> user sessions. > > You were absolutely right, I tried to dig into that and find out as it > was using internally su, > but now only problem remains is shutdown order. > As I have created a dependency that rdbms.service should start after > grid.service which works perfect at boot. > But when I do shutdown / reboot both services stop simultaneously. > which i want my grid.service to wait first before rdbms.service will > stop > As Type mentioned in services are oneshot. > >> dmesg output does not contain any systemd log. Anyway, we already know >> that your services are not really system services. > > So my service is system services, as let me attach cgls output > > └─system.slice > ├─rdbms.service > │ └─8039 /sarahn9db/db/11.2.0/bin/tnslsnr sarahn9 -inherit > ├─grid.service > │ ├─ 5316 /grid/gi/11.2.0/bin/ohasd.bin reboot > │ ├─ 6159 /grid/gi/11.2.0/bin/cssdagent > The obvious possibilities - ExecStop command returns before application is actually stopped. ExecStop must be synchronous, systemd assumes service is stopped when ExecStop command completes - stopping takes longer then TimeoutStopSec - your actual database it still started outside of rdbms.service. The only process shown in your output is listener, but I would expect rather more of Oracle there Without logs it is impossible to say anything more specific. > On Tue, Jun 16, 2020 at 12:23 AM Andrei Borzenkov > wrote: > >> 16.06.2020 07:36, Kamal Rathi пишет: >>> The fact that you need RemainAfterExit at all hints that processes that >>> belong to your service are not running as part of service control group. >>> Knowing how Oracle has traditionally been managed, I suspect that you >>> perform "su - oracle_owner" or similar to start them in which case all >>> actual service processes become part of respective user sessions, and >>> not part of your system services. There is no way to synchronize >>> stopping of processes/services belonging to different users. They are >>> completely independent and shutdown for all sessions is initiated in >>> parallel. >>> >> >> Please take at least some efforts to format mail so that it can be >> properly understood. Otherwise I am afraid your mails will simply be >> ignored. >> >>> If my theory is correct, the fix would be to actually run your systemd >>> services as systemd services. If my theory is wrong, provide full from >>> system boot to shutdown where it could be seen how your services are >>> started/stopped. Enabling systemd debug log level when doing it >>> certainly won't harm. >>> >>> >>> >>> I have incorporated Type=oneshot and remainAfterExit=yes as it was >> helpful >>> in startup of services, >> >> >> How RemainAfterExit affects *startup* of services? >> >>> but still grid.service are starting up in >>> user.slice >> >> So I was right. Your programs are running as user services or part of >> user sessions. >> >>> and shutdown was giving the same results >>> I am attaching debug logs . >>> >> >> dmesg output does not contain any systemd log. Anyway, we already know >> that your services are not really system services. >> >>> On Mon, Jun 15, 2020 at 10:34 AM Andrei Borzenkov >>> wrote: >>> 15.06.2020 11:01, Kamal Rathi пишет: > Hi Team, > > I have two services which are dependent on each other and are working fine > at boot up but at shutdown / reboot , the processes get killed as shutdown > got initated. > > Services are running fine in particular order but processes got killed >> .I > have enabled lingering on both users and changed confgiuration in > logind.conf to KillUserProcesses=no but still issue is same > Lingering/KillUserProcesses are relevant only for user services/sessions and so far there was no indication you use either. > ## > Systemd service files content are below > > cat /etc/systemd/system/grid.service > [Unit] > Description=Service to auto start Oracle ASM application > Before=rdbms.service > After=syslog.target network.target nfs-mountd.service autofs.service > systemd-user-sessions.service system.slice > [Service] > Type=simple > TimeoutSec=5min
Re: [systemd-devel] Systemd killed processes of custom services instead of graceful shutdown
>Please take at least some efforts to format mail so that it can be >properly understood. Otherwise I am afraid your mails will simply be >ignored. I am sorry for inconvenience, i will try to follow correct approach afterwards while replying > How RemainAfterExit affects *startup* of services? The services worked as expected and as i fixed the issue where it was using su in script. As in background there was SysVinit script which was getting invoked when system boot and makes processes falls in users.slice So the startup is working perfectly after disabling that SysVinit script. >So I was right. Your programs are running as user services or part of > user sessions. You were absolutely right, I tried to dig into that and find out as it was using internally su, but now only problem remains is shutdown order. As I have created a dependency that rdbms.service should start after grid.service which works perfect at boot. But when I do shutdown / reboot both services stop simultaneously. which i want my grid.service to wait first before rdbms.service will stop As Type mentioned in services are oneshot. >dmesg output does not contain any systemd log. Anyway, we already know >that your services are not really system services. So my service is system services, as let me attach cgls output └─system.slice ├─rdbms.service │ └─8039 /sarahn9db/db/11.2.0/bin/tnslsnr sarahn9 -inherit ├─grid.service │ ├─ 5316 /grid/gi/11.2.0/bin/ohasd.bin reboot │ ├─ 6159 /grid/gi/11.2.0/bin/cssdagent On Tue, Jun 16, 2020 at 12:23 AM Andrei Borzenkov wrote: > 16.06.2020 07:36, Kamal Rathi пишет: > > The fact that you need RemainAfterExit at all hints that processes that > > belong to your service are not running as part of service control group. > > Knowing how Oracle has traditionally been managed, I suspect that you > > perform "su - oracle_owner" or similar to start them in which case all > > actual service processes become part of respective user sessions, and > > not part of your system services. There is no way to synchronize > > stopping of processes/services belonging to different users. They are > > completely independent and shutdown for all sessions is initiated in > > parallel. > > > > Please take at least some efforts to format mail so that it can be > properly understood. Otherwise I am afraid your mails will simply be > ignored. > > > If my theory is correct, the fix would be to actually run your systemd > > services as systemd services. If my theory is wrong, provide full from > > system boot to shutdown where it could be seen how your services are > > started/stopped. Enabling systemd debug log level when doing it > > certainly won't harm. > > > > > > > > I have incorporated Type=oneshot and remainAfterExit=yes as it was > helpful > > in startup of services, > > > How RemainAfterExit affects *startup* of services? > > > but still grid.service are starting up in > > user.slice > > So I was right. Your programs are running as user services or part of > user sessions. > > > and shutdown was giving the same results > > I am attaching debug logs . > > > > dmesg output does not contain any systemd log. Anyway, we already know > that your services are not really system services. > > > On Mon, Jun 15, 2020 at 10:34 AM Andrei Borzenkov > > wrote: > > > >> 15.06.2020 11:01, Kamal Rathi пишет: > >>> Hi Team, > >>> > >>> I have two services which are dependent on each other and are working > >> fine > >>> at boot up but at shutdown / reboot , the processes get killed as > >> shutdown > >>> got initated. > >>> > >>> Services are running fine in particular order but processes got killed > .I > >>> have enabled lingering on both users and changed confgiuration in > >>> logind.conf to KillUserProcesses=no but still issue is same > >>> > >> > >> Lingering/KillUserProcesses are relevant only for user services/sessions > >> and so far there was no indication you use either. > >> > >>> ## > >>> Systemd service files content are below > >>> > >>> cat /etc/systemd/system/grid.service > >>> [Unit] > >>> Description=Service to auto start Oracle ASM application > >>> Before=rdbms.service > >>> After=syslog.target network.target nfs-mountd.service autofs.service > >>> systemd-user-sessions.service system.slice > >>> [Service] > >>> Type=simple > >>> TimeoutSec=5min > >>> User=grid > >>> Group=dba > >>> ExecStart=/opt/admin/bin/asm > >>> ExecStop=/opt/admin/bin/asm_stop > >>> RemainAfterExit=yes > >>> [Install] > >>> WantedBy=multi-user.target > >>> > >>> > >>> > >>> cat /etc/systemd/system/rdbms.service > >>> [Unit] > >>> Description=Service to auto start Oracle RDBMS application > >>> Requires=grid.service > >>> After=grid.service syslog.target network.target nfs-mountd.service > >>> autofs.service systemd-user-sessions.service system.slice > >>> [Service] > >>> Type=simple > >>> TimeoutSec=5min > >>> User=osarahn9 > >>> Group=dba > >>>
Re: [systemd-devel] sd-bus change that broke sdbus-c++
Done: https://github.com/systemd/systemd/issues/16193 On Tue, Jun 16, 2020 at 10:50 AM Lennart Poettering wrote: > On Mi, 10.06.20 18:24, Stanislav Angelovič (angelovi...@gmail.com) wrote: > > > Hi folks, > > > > sdbus-c++, a C++ library on top of sd-bus, is based on plain sd-bus > > messages to implement the concept of Variant type. Under plain message > here > > I mean one created via `sd_bus_message_new` with the type being > > _SD_BUS_MESSAGE_TYPE_INVALID. We use such a message as a generic > container > > of serialized D-Bus data, from which we read and to which we write. More > of > > this, including an example, is explained in the mailing list thread > spawned > > a year ago: > > > https://lists.freedesktop.org/archives/systemd-devel/2019-May/042748.html. > > > > That all of sudden stopped working with systemd 245.6. The reason is > highly > > likely this commit in systemd: > > > https://github.com/systemd/systemd/commit/a2dd991d0fde59dc0574bd4d0c1438f01dc0b8ff > . > > This commit changed `sd_bus_message_new` to be more strict and > immediately > > reject creating messages of type _SD_BUS_MESSAGE_TYPE_INVALID, whereas > > before that case was allowed, as were also allowed a few serialization > > operations upon such a message (the rest like enqueuing checked the type > > and failed, naturally). That original behavior was a perfect match for > our > > need for plain sd-bus messages. I understand that this was based on > > internal implementation of sd-bus, since as I checked the documentation > > now, it instructs clients to use one of the method call, method return, > > method error and signal types. > > > > What would you suggest as a solution in this situation? Would it be > > possible to get back to the original behavior? Or would you suggest > > creating a new API method for creating plain messages? Any is fine for > > sdbus-c++, but the latter is a little more difficult because we cannot > > conditionally decide upon the behavior in our code based on the systemd > > version, as 245 exhibits various behaviors depending on the minor > version... > > Please file a bug on github. > > Lennart > > -- > Lennart Poettering, Berlin > ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Strange partition layout from systemd-repart
On Fr, 05.06.20 15:29, Lennart Poettering (lenn...@poettering.net) wrote: > On Do, 04.06.20 16:58, Tobias Hunger (tobias.hun...@gmail.com) wrote: > > > Poking around a bit more: I have 4096 unused sectors before the first > > partiton instead of just 2048. Systemd-repart then tries to put all my > > new partitions into the sectors 2048-4095 and completely ignores the > > GBs of free space that is available elsewhere. > > Hmm, I guess what it does currently does makes some sense > actually. Maybe we should change the defaults for SizeMinBytes= > however, and default to 10M or so for that, so that it doesn't happen > accidentally, if people don't set a lower partition limit. Or maybe we > should warn about really small partitions? > > > So this can be considered a user error. I'll fix the image generation. > > > > Maybe there is some way to improve the reporting done by > > systemd-repart in such a case? > > What would you propose specifically? Warn when partitions of a size > below some compiled-in threshold are generated? anything smarter? https://github.com/systemd/systemd/pull/16191 Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Systemd killed processes of custom services instead of graceful shutdown
On Mo, 15.06.20 03:01, Kamal Rathi (kr30ap...@gmail.com) wrote: > Hi Team, > > I have two services which are dependent on each other and are working fine > at boot up but at shutdown / reboot , the processes get killed as shutdown > got initated. My educated guess is that your services use "su" or so, thus opening a new session, which then gets killed like user sessions get killed. Use "setpriv" to change privileges, not "su". If "su" is not in the mix, then make sure your ExecStop= scripts work correctly and kill all service processes correctly, since systemd just kills what the ExecStop= binary doesn't kill. Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] kernel messages not making it to journal
On Mo, 01.06.20 19:11, Chris Murphy (li...@colorremedies.com) wrote: > dmesg shows this: > > [ 22.947118] systemd-journald[629]: File > /var/log/journal/26336922e1044e80ae4bd42e1d6b9099/user-1000.journal > corrupted or uncleanly shut down, renaming and replacing. journald itself logs about most things to kmsg, and for a select few things also to its own journals. But there's the general problem: in some conditions where we cannot write to disk or where we encounter corrupted files we cannot safely write to disk, hence we don't and only write to kmsg. We genreally also write out everything from kmsg to disk, but ther we actually filter the stuff we wrote there ourselves, to avoid busy loops. It#'s a bit of a tricky situation: when things are fucked we need to be very careful what we do to not make things worse. > [ 22.953883] systemd-journald[629]: Creating journal file > /var/log/journal/26336922e1044e80ae4bd42e1d6b9099/user-1000.journal on > a btrfs file system, and copy-on-write is e > > But journalctl does not show it at all. Seems like it might be a bug, > I expect it to be recorded in the journal, not only found in dmesg. I figure in this case we should probably generate a log message in the main journal file, since only the user one was corrupted. Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] sd-bus change that broke sdbus-c++
On Mi, 10.06.20 18:24, Stanislav Angelovič (angelovi...@gmail.com) wrote: > Hi folks, > > sdbus-c++, a C++ library on top of sd-bus, is based on plain sd-bus > messages to implement the concept of Variant type. Under plain message here > I mean one created via `sd_bus_message_new` with the type being > _SD_BUS_MESSAGE_TYPE_INVALID. We use such a message as a generic container > of serialized D-Bus data, from which we read and to which we write. More of > this, including an example, is explained in the mailing list thread spawned > a year ago: > https://lists.freedesktop.org/archives/systemd-devel/2019-May/042748.html. > > That all of sudden stopped working with systemd 245.6. The reason is highly > likely this commit in systemd: > https://github.com/systemd/systemd/commit/a2dd991d0fde59dc0574bd4d0c1438f01dc0b8ff. > This commit changed `sd_bus_message_new` to be more strict and immediately > reject creating messages of type _SD_BUS_MESSAGE_TYPE_INVALID, whereas > before that case was allowed, as were also allowed a few serialization > operations upon such a message (the rest like enqueuing checked the type > and failed, naturally). That original behavior was a perfect match for our > need for plain sd-bus messages. I understand that this was based on > internal implementation of sd-bus, since as I checked the documentation > now, it instructs clients to use one of the method call, method return, > method error and signal types. > > What would you suggest as a solution in this situation? Would it be > possible to get back to the original behavior? Or would you suggest > creating a new API method for creating plain messages? Any is fine for > sdbus-c++, but the latter is a little more difficult because we cannot > conditionally decide upon the behavior in our code based on the systemd > version, as 245 exhibits various behaviors depending on the minor version... Please file a bug on github. Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Monitoring unit and overall state
On Fr, 05.06.20 14:42, Tomáš Pecka (pecka...@fit.cvut.cz) wrote: > Hello, > > we are currently working on a project where we'd like to let users know > the health status of the system's services. The health status is > supposed to be considered as "is every unit in systemd ok?". > For example, when a daemon crashes we want to switch the red light on > and keep it until the service is started again. After the service is > active again (and nothing else failed meanwhile), switch the green light on. > > At first, we thought that it will be sufficient to monitor manager's > SystemState (or NFailedUnits) property on dbus. It sets up state to > 'degraded' (and NFailedUnits=1) when the daemon crashes. However, the > unit can be set to auto-restart, and when it does, the SystemState > immediately restores back to 'running' (because the unit is in > 'activating auto-restart' state and not failed anymore). So I don't > think I can use it here. > > I can probably think of some ways how to achieve it. Perhaps monitoring > ActiveState/SubState properties of all units and look for the unit > states that we consider bad (probably 'failed' and 'activating > auto-restart'?) and keep track of units that are (not) OK. I am not sure > whether this is a good idea though. I think there might be better ways > which I do not currently see. > > So -- is there a better way how get such information from systemd? We do > not care about the output when the manager is starting/stopping. A failing unit creates a journal log message of MESSAGE_ID=d9b373ed55a64feb8242e02dbe79a49c you can thus do something like thist: journalctl MESSAGE_ID=d9b373ed55a64feb8242e02dbe79a49c -b -f (or something equivalent by linking against libsystemd.) It will report all failed services to you. You can even add "-o verbose" (or -o json) to get additional structure info from it. Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] hostnamectl reapplying the same hostname
On 16/06/2020 10:08, Lennart Poettering wrote: On Mo, 25.05.20 16:19, Thomas HUMMEL (thomas.hum...@pasteur.fr) wrote: Hello, the point below has been buried at the end one of a previous thread. So feel free to ignore it if you find it irrelevant. With systemd-239 on linux 4.18.0 (CentOS 8.1), why does hostnamectl --static set-hostname instantly sets the transient hostname to *only* when is not the current static hostname ? There's a shortcut in place: if you change a hostname to what it is already set to things are NOPs, and won't generate security incidents and so on. Ok, get it. Thanks. -- Thomas HUMMEL ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd IdleAction for lock is not working
On Mi, 03.06.20 17:51, seshu pyla (seshu.p...@gmail.com) wrote:
> Hi,
>
>
>
> I am trying the below logind parameters to configure session lock in my
> system.
>
>
>
> /etc/systemd/logind.conf
>
> IdleAction=Lock
>
> IdleActionSec=1min
>
>
>
> But, with above configurations there is no effect, so I have looked in to
> the code and after the below change the lock event is sent and session lock
> is happening successfully.
>
> --- a/src/login/logind.c
>
> +++ b/src/login/logind.c
>
> @@ -1019,7 +1019,7 @@ static int
> manager_dispatch_idle_action(sd_event_source *s, uint64_t t, void *us
>
> (m->idle_action_not_before_usec <= 0 || n >=
> m->idle_action_not_before_usec + m->idle_action_usec)) {
>
> log_info("System idle. Taking action.");
>
>
>
> -manager_handle_action(m, 0, m->idle_action, false,
> false);
>
> +manager_handle_action(m, 0, m->idle_action, false,
> true);
>
> m->idle_action_not_before_usec = n;
>
> }
>
>
>
> Is there any specific reason the “Lock” action is not handling in systemd?
>
>
>
> Is there any plan in future if the “Lock” action is handled in system?
This might be a bug. Please file a bug on github about thus. Thanks
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] workaround for systemd-networkd-wait-online boot fail/delay on systems with bridge for v234? (fix @ systemd/issues/2154 requires v>242)
On Sa, 30.05.20 18:02, PGNet Dev (pgnet@gmail.com) wrote: > IS there a backport of this^^ fix available for v234 that popped up in > the meantime? > > If not, as is likely, is there a "safe" workaround for quieting the > fail, and rm'ing the associated boot delay? Is rm'ing either the "Also=" or > "WantedBy=" a reasonable band-aid? > > Or, some other approach? You could use RequiredForOnline= in the bridge's .network file to mark it as irrelevant for systemd-network-wait-online. Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] A way to debug machine shutdown
On Di, 16.06.20 11:22, darkpenguin (darkpeng...@yandex.com) wrote: > I would be able to figure it out if systemd told me what is going on. > This is my main point - maybe it should tell us immediately that "this > process is stalling the shutdown" or "this thing reloads me too much"? > And ideally "...Do you want to kill it?". Uh, interactivity during shutdown is not something I even want to start with. Thing is, systemd actually does tell you that, it tells you whcih session is at fault. I understand you'd want more finegrained info at that point, and we place that in the logs. Now, in your system there's a tonload going on, so it's hard to figure out what is the actual culprit, but you can't hardly complain we give you too few logs, we give you rather too many... Anyway we can certainly extend the console status output at shutdown to show offending processes, but it's not trivial to do so: the thing is that system shutdown is handled by PID 1, it shuts down all system services. One of which is your user's service manager, i.e. the systemd --user instance. Now, if we blindly tell you that it is not exiting, you might then complain that systemd is at fault, but actually it is a service under the systemd --user's supervision that is at fault. But that relationship is something only the systemd --user instance understands. Now, we could of course ask `systemd --user` for the output, but that means we'd allow unpriv programs to log to the system console just like that, which I find highly problematic... So, it's not an easy problem. If we indeed want to show more info on the system console if user programs misbheave during shutdown we need to figure out a safe way how to do that, that cannot be gamed by said users to output whatever they want onto the console. Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-nspawn: Failed at step SETSCHEDULER spawning /opt/freeswitch/bin/freeswitch: Operation not permitted
On Fr, 29.05.20 00:31, Nuno Reis (nr...@wavecom.pt) wrote: > > I've noticed that if I give the same CPUScheduling options to the > > 'systemd-nspawn@'.service service on the Fedora 32 hosting > > system I don't have the following error anymore in the container: > > Failed at step SETSCHEDULER spawning /opt/freeswitch/bin/freeswitch: > > Operation not permitted > > > > The only error that remains is the: > > > > Failed at step IOPRIO spawning /opt/freeswitch/bin/freeswitch: Operation > > not permitted > > > What is the best way to have this options set the right way and make > everything work as expected inside the nspawn container? How do you set up your nspawn container? Do you use userns? rt sched is a privileged operation, but RLIMIT_RTPRIO can open it up for unpriv processes. But that rlimit only affects the CPU scheduler, not the IO scheduler. Also, you need to turn off RT group sched in the kernel, as otherweise the CPU cgroup controller will disallowe rt sched all the way down the tree unless an rt budget is configured for each cgroup in the tree. Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] hostnamectl reapplying the same hostname
On Mo, 25.05.20 16:19, Thomas HUMMEL (thomas.hum...@pasteur.fr) wrote: > Hello, > > the point below has been buried at the end one of a previous thread. So feel > free to ignore it if you find it irrelevant. > > With systemd-239 on linux 4.18.0 (CentOS 8.1), why does hostnamectl --static > set-hostname instantly sets the transient hostname to *only* > when is not the current static hostname ? There's a shortcut in place: if you change a hostname to what it is already set to things are NOPs, and won't generate security incidents and so on. Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Services enabled in an nspawn container on an nfsroot
On Sa, 23.05.20 15:07, Antoine Pietri (antoine.piet...@gmail.com) wrote: > Hi, > > I have a setup where my NFS server exports its /export/nfsroot for my > diskless clients. > To ease the deployment of this nfsroot, I'd like to be able to run > ansible roles directly in there to install the packages and > configurations directly in the nfsroot. I thought using an nspawn > container would be a good way to achieve that. > > So I first symlinked my nfsroot like this: ln -s /export/nfsroot > /var/lib/machines > Then I created a very simple nfsroot.nspawn file (Exec.Boot=true, > Network.Private=yes) and enabled this container. It works fine, if I > enable SSH I can install whatever I want through ansible. > > Now my issue is this: there are some services that I'd like to enable > for the diskless boot clients (lightdm will not start properly in my > container), and some I'd like to only enable for the container (I > don't need systemd-networkd in my clients because they will inherit > their network configuration from the PXE stack). > > What is the best way to have a separate set of services that I enable > when running as a container and when running from the diskless boot? > The potential solutions I see are: > > - Masking the services individually on the kernel command line > - Using two targets (container.target / nfsroot.target) which specify > what they require and starting them from the kernel command line > (after having disabled all the services) > - Using systemd.preset(5) (maybe with a bind mount of a preset file in > the container) > - Creating an override file for each service with a line like > ConditionVirtualization=container > > Maybe I'm missing an easier way? My preference would be to have a > whitelist of services that I start when running in the container > (which would probably only be sshd and systemd-networkd to allow > ansible deployments), and ignore everything else. I would probably pull in all services all the time, but then condition them out in the environments you don't want them to run it. i.e. by adding a drop-in with "ConditionVirtualization=" or "ConditionKernelCommandLine="... and so on. Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Fedpra 32 NIS with systemd-logind.service: start operation timed out. Terminating. Got lookup error: io.systemd.TimedOut
On Mi, 20.05.20 11:15, Robert Kudyba (rkud...@fordham.edu) wrote: > One more question, any reason for these error messages in the logs after > restarting systemd-logind? > > May 20 11:12:50 secondary systemd-logind[382684]: New seat seat0. > May 20 11:12:50 secondary systemd-logind[382684]: User or group name "0" > starts with a digit, accepting for compatibility. > May 20 11:12:50 secondary systemd-logind[382684]: Failed to add user by > file name 0, ignoring: Invalid argument > May 20 11:12:50 secondary systemd-logind[382684]: User enumeration failed: > Invalid argument Yes, it's a bug: https://github.com/systemd/systemd/issues/16146 Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to silence systemd's "Starting", "Succeeded" and "Started" notifications?
On Sa, 16.05.20 10:31, Jaime (enopa...@gmail.com) wrote:
> I have a simple non-looping shell script that I call every 60 seconds
> using a systemd service and associated timer. My shell script produces
> no output at all. My journal looks like this:
>
> May 15 03:43:00 server systemd[450]: Starting updater.service...
> May 15 03:43:01 server systemd[450]: updater.service: Succeeded.
> May 15 03:43:01 server systemd[450]: Started updater.service.
> May 15 03:44:00 server systemd[450]: Starting updater.service...
> May 15 03:44:01 server systemd[450]: updater.service: Succeeded.
> May 15 03:44:01 server systemd[450]: Started updater.service.
> May 15 03:45:00 server systemd[450]: Starting updater.service...
> May 15 03:45:01 server systemd[450]: updater.service: Succeeded.
> May 15 03:45:01 server systemd[450]: Started updater.service.
> May 15 03:46:00 server systemd[450]: Starting updater.service...
> May 15 03:46:01 server systemd[450]: updater.service: Succeeded.
> May 15 03:46:01 server systemd[450]: Started updater.service.
> May 15 03:47:00 server systemd[450]: Starting updater.service...
> May 15 03:47:01 server systemd[450]: updater.service: Succeeded.
> May 15 03:47:01 server systemd[450]: Started updater.service.
> May 15 03:48:00 server systemd[450]: Starting updater.service...
> May 15 03:48:01 server systemd[450]: updater.service: Succeeded.
> May 15 03:48:01 server systemd[450]: Started updater.service.
>
> Is it possible to stop these notification lines from being entered
> into the journal? I understand that one alternative is to just rewrite
> the script to loop forever ("while true ; do blah ; done"-style) and
> get rid of the timer, but I wanted to know whether there is any
> built-in log-level style control for these systemd-generated messages.
systemd logs about everything it does. If you don#t want that, you can
turn it of. Set "systemd.log_level=notice" or so on the kernel
cmdline, or LogLevel=notice in /etc/systemd/system.conf
But of course, thigns will be very quiet then...
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemctl status cpu/memory
On Do, 30.04.20 13:40, Reindl Harald (h.rei...@thelounge.net) wrote: > > the cpu time of 672ms is wrong, memory is missing in Fedora 31 while it > was there in previous versions though it's a oneshot service Is this supposed to be a bug report? Please report bugs along with a minimal reproducer on github. Please enable memory and IO accounting in your unit to get proper accounting. Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] A way to debug machine shutdown
On Mi, 13.05.20 08:34, darkpenguin (darkpeng...@yandex.com) wrote:
> I had trouble trying to paste a 70M text file to fpaste.org; here is the
> gzipped log of the shutdown process instead ('zcat journal.gz | less'
> works where other ways don't).
>
> >> Instead of 90 seconds of "Waiting for session-1.scope ... ", which gives
> >> us next to zero information about the real source of the problem, why
> >> not also mention exactly which process is the problem? Or even
> >> better, a
> >
> > Again, as mentioned above, we already do that. That's what I wrote
> > above.
>
> What I meant was not exactly this - rather, show the scope status next
> to the "Waiting for Session 1 of user..." message, so that we don't have
> to enable debug, reproduce the problem one more time and then search
> through a 70M log file.
>
> By the way, I could probably do a "systemctl status session-1.scope"
> from the debug shell, but there is no way to have the debug shell during
> shutdown, is there?..
Hmm, I started having a look at the output, but there's just too much
noise going on, something is reloading PID 1 configuration repeatedly
during shutdown. Please figure out what does that and fix that. It's
not how this should work...
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] networkd: how to match the only interface?
On Tue, Jun 16, 2020 at 4:13 AM Roman Odaisky wrote: > Hi, > > I would like to assign a static IP address to a server in a way that > survives > hardware replacement. Basically I want the configuration to say: “Find the > only > physical interface present and assign this static IP address to it. In the > unexpected case of finding multiple interfaces, assign the address to some > interface”. > > The problem I’m trying to avoid is that if the hardware of a headless > server > fails, then moving its drive(s) to another server may cause it to become > inaccessible if the name of the link becomes different. > > Similarly, if I prepare a USB drive to troubleshoot headless server > issues, I > need to have it assign an address to at least one interface without > knowing in > advance what its name is. > > What would be appropriate .link/.network entries that achieve this and > avoid > assigning the same address to more than one interface or interfering with > virtual interfaces? > In this case I would just *disable* the persistent naming feature, so that you would always keep the kernel-assigned "eth0" name. (This would be either setting NamePolicy= to an empty value in a .link file so that no naming policies are applied, or outright booting with the " net.ifnames=0" kernel parameter.) This works perfectly fine as long as you have exactly one physical Ethernet interface, as you claimed. If you have multiple, one of them will still be "eth0" and will still get the IP address... you just can't be sure *which *one. (They might even swap after a reboot.) -- Mantas Mikulėnas ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] nspawn and mariadb /run/mysql
On Di, 21.04.20 10:40, Damian Ivanov (damianator...@gmail.com) wrote: > Hi, > > After bootstrapping os and mariadb into $DIR > I booted the machine with: > systemd-nspawn -D $DIR -b --resolv-conf=bind-host --capability=all > I had to remove $DIR/etc/resolv.conf first as bind-host seems to fail > if $DIR/etc/resolv.conf already exists. > > mariadb.service was failing, after looking into mysql.log > I found that /run/mysql/mysql.sock (No such file or directory) > > /run is a temporary dir inside nspawn and not the actual $DIR/run > So I went ahead and created /run/mysql (which of course is gone when > the container is stopped) > For mariadb to work it is also required to chown -R mysql:mysql /run/mysql > which results in chown complaing no such group mysql > > The group is in /etc/groups and another attempt to add groupadd mysql > would faill saying that the group exists. Using chmod -R 777 /run/mysql > worked. > > Is there some permanent solution to have mariadb work, > without recreating /run/mysql at container boot and even better with > groups working? This sounds like an OS packaging bug of mariadb. Usually they should ship tmpfiles.d snippets so that all necessary files in /run/ are created. Similar, they either should create all users or provide a sysusers.d snippet to have it created automatically on first boot. Ether way, this smells as if you should report it to your OS vendor. Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-udevd.service cannot start, core dump
On Sa, 13.06.20 04:56, Ed Strong (onkyonk...@outlook.com) wrote: > Hello! As of about a week ago udev cannot start, journalctl -xe gives the > below output. The stack trace references the glibc library but not sure if > red herring or not. Any ideas on how to troubleshoot this would be most > appreciated. > > I am running on Arch Linux kernel 5.7.2 > > Many thanks, > > 6月 12 23:26:22 exps13arch systemd[1]: systemd-udevd-kernel.socket: Failed > with result 'service-start-limit-hit'. > -- Subject: Unit failed > -- Defined-By: systemd > -- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel > -- > -- The unit systemd-udevd-kernel.socket has entered the 'failed' state with > result 'service-start-limit-hit'. > 6月 12 23:26:22 exps13arch systemd-coredump[534]: Process 531 (systemd-udevd) > of user 0 dumped core. > > Stack trace of thread 531: > #0 0x7f650d54c65b > __brk (/usr/lib/ld-2.31.so + 0x1c65b) > #1 0x7f650d54b192 > _dl_sysdep_start (/usr/lib/ld-2.31.so + 0x1b192) > #2 0x7f650d532f4c > _dl_start (/usr/lib/ld-2.31.so + 0x2f4c) > #3 0x7f650d532108 > _start (/usr/lib/ld-2.31.so + 0x2108) This process dies during earliest initialization in the dynamic loader. No systemd code has run at that point yet. Something is wrong with your libc/dynamic loader. Or maybe you have a corrupted udev binary? Either way, please contact your downstream distro about that first. Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
