Re: [systemd-devel] My experience with MySQL and systemctl
On 04/13/2017 02:48 AM, Lennart Poettering wrote: > On Wed, 12.04.17 21:09, Michael Biebl (mbi...@gmail.com) wrote: > >> 2017-04-12 20:24 GMT+02:00 Tomasz Torcz : >>> On Wed, Apr 12, 2017 at 11:01:04AM -0700, Auke Kok wrote: The right (or, better) solution IMHO would be for mysqld to signal to systemd that it's running OK before recovery starts, using type=notify. This way recovery can take as long as needed, and if it fails, it could signal this failure as normal back to systemd. Then systemd would retry the recovery a few times this way and finally give up. >>> >>> It wouldn't be good solution. READY=1 means clients can connect and >>> talk to the database. Signalling readiness prematurely would break >>> functionality.. >> >> Maybe we'd need a new state paramenter, like STARTING=1 which could be >> sent by the daemon to systemd in regular intervals and would signal >> systemd that the startup of the daemon is in process and the daemon is >> not actually hung. > > There was an RFE somewhere for supporting watchdog messages > (i.e. WATCHDOG=1) during startup too, not just during runtime. I'd be > fine with adding that. that sounds more than reasonable, +1 Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd-nspawn network-interface
Hello Regaining of the network-interface, as is stated in the manual, ain't happening; man 1 systemd-nspawn ... OPTIONS ... --network-interface= Assign the specified network interface to the container. This will remove the specified interface from the calling namespace and place it in the container. When the container terminates, it is moved back to the host namespace. [...] Given what's actually going on, should be stated; --network-interface= Assign the specified network interface to the container. This will remove the specified interface from the calling namespace and place it in the container. When the container terminates, considering that the specified interface is not moved back to the host namespace, specific kernel module need to be reloaded to move it back to the host namespace. [...] ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] header intact.
Header may be intact, but the rest of your message unfortunately isn't. On Thu, Apr 13, 2017, 13:54 adr jedr wrote: > > adr jedr > ___ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/systemd-devel > ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] header intact.
adr jedr ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Early testing for service enablement
On Thu, 2017-04-13 at 11:45 +0200, Lennart Poettering wrote: > On Thu, 13.04.17 08:49, Mantas Mikulėnas (graw...@gmail.com) wrote: > > > IIRC, enable/disable/is-enabled are implemented entirely via direct > > filesystem access. Other than that, systemctl uses a private socket > > when > > running as root – it talks DBus but doesn't require dbus-daemon. > > Correct, enable/disable/is-enabled can operate without PID 1, but > they > usually don't unless the tool detects it is being run in a chroot > environment. > > And yes, systemctl can communicate with PID 1 through a private > communication socket that exists as long as PID 1 exists. dbus-daemon > is not needed, except when your client is unprivileged. If I interpret this answer correctly, you're saying that "systemctl is- enabled xyz.service" *should* actually work, even if it's called right after PID 1 is started. I'm pretty certain that that wasn't the case for me. My client was running from an udev rule and thus not unprivileged. That should be considered a bug, then? My tests were done with systemd 228 a while ago. Martin -- Dr. Martin Wilck , Tel. +49 (0)911 74053 2107 SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Early testing for service enablement
On Thu, 2017-04-13 at 08:49 +, Mantas Mikulėnas wrote:
> IIRC, enable/disable/is-enabled are implemented entirely via direct
> filesystem access. Other than that, systemctl uses a private socket
> when running as root – it talks DBus but doesn't require dbus-daemon.
> A bigger problem is that initramfs can't know much about the main
> system due to having a separate /etc, unless maybe you run `systemctl
> --root=...`
This is not a problem for us because in initramfs, we only care whether
the service is enabled in initramfs itself.
> Could you elaborate on why you find this checking necessary in the
> first place? Do your udev rules run some weird stuff?
It's about multipath. In the udev rule that checks whether or not a
given device should be treated as a multipath device path, we need to
figure out whether multipathd.service is enabled. We want to to that
without connecting to multipathd.socket at that time in the boot
process, because that would fire up multipathd, and there's strong
evidence that multipath-enabled systems boot more stably if multipathd
is started later (after udev settle). Therefore the idea was to obtain
the information from systemd ("will multipathd.service be started later
in the boot process?").
> If you're working with your own internal services, there might be
> other ways of checking this.
What do you mean?
Regards,
Martin
--
Dr. Martin Wilck , Tel. +49 (0)911 74053 2107
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] My experience with MySQL and systemctl
On Wed, 12.04.17 21:09, Michael Biebl (mbi...@gmail.com) wrote: > 2017-04-12 20:24 GMT+02:00 Tomasz Torcz : > > On Wed, Apr 12, 2017 at 11:01:04AM -0700, Auke Kok wrote: > >> The right (or, better) solution IMHO would be for mysqld to signal to > >> systemd that it's running OK before recovery starts, using type=notify. > >> This way recovery can take as long as needed, and if it fails, it could > >> signal this failure as normal back to systemd. Then systemd would retry > >> the recovery a few times this way and finally give up. > > > > It wouldn't be good solution. READY=1 means clients can connect and > > talk to the database. Signalling readiness prematurely would break > > functionality.. > > Maybe we'd need a new state paramenter, like STARTING=1 which could be > sent by the daemon to systemd in regular intervals and would signal > systemd that the startup of the daemon is in process and the daemon is > not actually hung. There was an RFE somewhere for supporting watchdog messages (i.e. WATCHDOG=1) during startup too, not just during runtime. I'd be fine with adding that. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Early testing for service enablement
On Thu, 13.04.17 08:49, Mantas Mikulėnas (graw...@gmail.com) wrote: > IIRC, enable/disable/is-enabled are implemented entirely via direct > filesystem access. Other than that, systemctl uses a private socket when > running as root – it talks DBus but doesn't require dbus-daemon. Correct, enable/disable/is-enabled can operate without PID 1, but they usually don't unless the tool detects it is being run in a chroot environment. And yes, systemctl can communicate with PID 1 through a private communication socket that exists as long as PID 1 exists. dbus-daemon is not needed, except when your client is unprivileged. In recent systemd versions you can even force systemctl to always do "sytemctl enable/disable/is-enabled" on the client side by setting the env var SYSTEMCTL_INSTALL_CLIENT_SIDE=1 for it. But this is usually not necessary nor a good idea, as PID 1 won't notify clients about changes then, since it doesn't know about them. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Early testing for service enablement
IIRC, enable/disable/is-enabled are implemented entirely via direct filesystem access. Other than that, systemctl uses a private socket when running as root – it talks DBus but doesn't require dbus-daemon. A bigger problem is that initramfs can't know much about the main system due to having a separate /etc, unless maybe you run `systemctl --root=...` Could you elaborate on why you find this checking necessary in the first place? Do your udev rules run some weird stuff? If you're working with your own internal services, there might be other ways of checking this. On Thu, Apr 13, 2017, 11:24 Martin Wilck wrote: > Hi all, > > is there a way to test whether a certain service is enabled (or is > going to be enabled) that would work even very early in the boot > process (in our case from udev rules called in the "udev trigger" phase > both in initrd and after switching root)? > > I tried calling "systemctl is-enabled" but it obviously depends on some > services (dbus, I guess) being functional, and didn't provide reliable > results during early boot for us. > > We finally resorted to scanning *.wants directories by ourselves, but > that's of course sub-optimal (poor mans partial implementation of > systemd's service enablement logic). > > Regards > Martin > > -- > Dr. Martin Wilck , Tel. +49 (0)911 74053 2107 > SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton > HRB 21284 (AG Nürnberg) > > ___ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/systemd-devel > -- Mantas Mikulėnas Sent from my phone ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] My experience with MySQL and systemctl
Am 13.04.2017 um 06:06 schrieb Andrei Borzenkov: Maybe we'd need a new state paramenter, like STARTING=1 which could be sent by the daemon to systemd in regular intervals and would signal systemd that the startup of the daemon is in process and the daemon is not actually hung. You still need to upper bound it. Consider service that is run on shutdown. You cannot indefinitely wait for service that is stuck in STARTING state. So STARTING state is marginally useful to catch hung service, but at some point service manager still needs to decide how long it wants to wait. We are back at square one. why should a process at shutdown/stop signal "STARTING=1"? you should at least distinct between STARTING/STOPPING and combine that with two different settings for the systemd-unit where can be specified how long in each of that states should be waited that distributions and users should get rid of mysqld_safe to use that is a different story, we are probably the first which switched to a native systemd-unit in 2011 for all servers and i can assure nobody needs mysqld_safe at all ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Early testing for service enablement
Hi all, is there a way to test whether a certain service is enabled (or is going to be enabled) that would work even very early in the boot process (in our case from udev rules called in the "udev trigger" phase both in initrd and after switching root)? I tried calling "systemctl is-enabled" but it obviously depends on some services (dbus, I guess) being functional, and didn't provide reliable results during early boot for us. We finally resorted to scanning *.wants directories by ourselves, but that's of course sub-optimal (poor mans partial implementation of systemd's service enablement logic). Regards Martin -- Dr. Martin Wilck , Tel. +49 (0)911 74053 2107 SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to disable systemd snapshot
It wasn't very useful. On Thu, Apr 13, 2017, 10:47 Rock Lee wrote: > > If you're referring to the `systemctl snapshot` feature which remembers > > currently active services – it was removed several releases ago, and > before > > that it was only usable by root. > > > > Systemd does not have any other "snapshotting" features (as far as I can > > remember), except maybe some distro-specific btrfs services. > > > Indeed, there is no "systemctl snapshot" in the recent sytemd source > code. I am using yocto which with systemd 216, that's quite old. Do > you know why "systemctl snapshot" was removed? > > -- > Cheers, > Rock > -- Mantas Mikulėnas Sent from my phone ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to disable systemd snapshot
> If you're referring to the `systemctl snapshot` feature which remembers > currently active services – it was removed several releases ago, and before > that it was only usable by root. > > Systemd does not have any other "snapshotting" features (as far as I can > remember), except maybe some distro-specific btrfs services. > Indeed, there is no "systemctl snapshot" in the recent sytemd source code. I am using yocto which with systemd 216, that's quite old. Do you know why "systemctl snapshot" was removed? -- Cheers, Rock ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to disable systemd snapshot
If you're referring to the `systemctl snapshot` feature which remembers currently active services – it was removed several releases ago, and before that it was only usable by root. Systemd does not have any other "snapshotting" features (as far as I can remember), except maybe some distro-specific btrfs services. On Thu, Apr 13, 2017, 10:25 Rock Lee wrote: > Hi, there: > From the security concern, I need to disable systemd snapshot. I > searched Google, but found nothing. Can anybody give me a hint? > > -- > Cheers, > Rock > ___ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/systemd-devel > -- Mantas Mikulėnas Sent from my phone ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] How to disable systemd snapshot
Hi, there: From the security concern, I need to disable systemd snapshot. I searched Google, but found nothing. Can anybody give me a hint? -- Cheers, Rock ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
