Re: [systemd-devel] emergency shutdown, don't wait for timeouts
Il 27/12/20 15:00, Reindl Harald ha scritto: > > > Am 27.12.20 um 14:43 schrieb Andrei Borzenkov: >> 27.12.2020 16:26, Germano Massullo пишет: >>> Good day, I recently joined apcupsd (APC UPS Power Control Daemon) >>> package maintainers on Fedora/CentOS/RHEL. >>> After a power failure, apcupsd shuts down the system with a command >>> almost identical to >>> shutdown -h -H now >>> Usually when you normally shutdown your system, you may notice certain >>> services taking too much time to terminate and triggering a timeout >>> value before systemd forces them to terminate. I would like to ask if >>> there is a way to force the system to shutdown without waiting for >>> these >>> timeouts in case an emergency like a power failure. >>> >> >> You can force shutdown without going via normal stop of services. >> >> systemctl --force poweroff > > but that is only a part of the solution because normally most services > don't take long to stop and they should be normally stopped whenever > possible > > the real solution would a option to reduce the timeouts > > systemctl --timeout=5 poweroff I just created a request for enhancement based on your suggestion "[RFE] timeout flag for halt/poweroff/reboot" https://github.com/systemd/systemd/issues/18097 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] emergency shutdown, don't wait for timeouts
Il 27/12/20 15:40, Andrei Borzenkov ha scritto: > 27.12.2020 17:00, Reindl Harald пишет: >> >> Am 27.12.20 um 14:43 schrieb Andrei Borzenkov: >>> 27.12.2020 16:26, Germano Massullo пишет: >>>> Good day, I recently joined apcupsd (APC UPS Power Control Daemon) >>>> package maintainers on Fedora/CentOS/RHEL. >>>> After a power failure, apcupsd shuts down the system with a command >>>> almost identical to >>>> shutdown -h -H now >>>> Usually when you normally shutdown your system, you may notice certain >>>> services taking too much time to terminate and triggering a timeout >>>> value before systemd forces them to terminate. I would like to ask if >>>> there is a way to force the system to shutdown without waiting for these >>>> timeouts in case an emergency like a power failure. >>>> >>> You can force shutdown without going via normal stop of services. >>> >>> systemctl --force poweroff >> but that is only a part of the solution because normally most services >> don't take long to stop and they should be normally stopped whenever >> possible >> >> the real solution would a option to reduce the timeouts >> >> systemctl --timeout=5 poweroff > sytemctl does not have this option. Being able to set a timeout would have been the best option since, from man systemctl, "poweroff" section: "[...]If combined with --force, shutdown of all running services is skipped, however all processes are killed[...]" so we could avoid killing services if not strictly necessary... ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] emergency shutdown, don't wait for timeouts
Good day, I recently joined apcupsd (APC UPS Power Control Daemon) package maintainers on Fedora/CentOS/RHEL. After a power failure, apcupsd shuts down the system with a command almost identical to shutdown -h -H now Usually when you normally shutdown your system, you may notice certain services taking too much time to terminate and triggering a timeout value before systemd forces them to terminate. I would like to ask if there is a way to force the system to shutdown without waiting for these timeouts in case an emergency like a power failure. Thank you ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Start service after video drivers have been loaded
Il giorno lun 17 giu 2019 alle ore 11:07 Lennart Poettering ha scritto: > > On So, 09.06.19 19:45, Germano Massullo (germano.massu...@gmail.com) wrote: > > > Il giorno mar 21 mag 2019 alle ore 16:59 Mantas Mikulėnas > > ha scritto: > Actually, maybe having udev > > > trigger BOINC startup would be a good option? After all that's how > > > BlueZ already works -- it doesn't go in multi-user.target, it has > > > WantedBy=bluetooth.target and there's an udev rule that makes every > > > Bluetooth device pull in bluetooth.target as a dependency. And > > > that's already an official systemd thing, too. > > > > No because BOINC client can even run on systems without graphic card. > > I will try an approach of restarting BOINC client as soon a new > > dev-dri-card0.device appears > > The clean way to handle this is to make your software handle hardware > dynamically internally: make use of the graphics devices it can make > use of the moment they pop up, and not earlier, and do so with any > device showing up, regardless if there are zero initially, one > eventually, or even more... > > systemd is not really designed to be used as work-around for software > that deals with hardware but doesn't really understand that hw is > dynamic these days. > > Hence my recommendation would be to work with the upstream developers > of your project to natively hook up things with libudev or a similar > library to watch for devices popping up and going away. Good, thank you very much for clarifing this. Have a nice day! > > Lennart > > -- > Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Start service after video drivers have been loaded
I have two different options at the moment, and I would like to ask
you for a feedback.
A file
/usr/lib/udev/rules.d/01-boinc-gpu-plugged.rules
containing
ACTION=="add", SUBSYSTEM=="drm", RUN+=systemctl --no-block restart
boinc-client.service
should restart BOINC client when a new DRM device (under /dev/dri)
appears. So we can fix the problem that unables BOINC to detect OpenCL
capabilities if BOINC service is loaded before the videocard drivers.
Flag
--no-block
is needed to avoid udev time it out agains things runned by RUN. When
udev runs something with RUN it has a timeout and it kills the process
after that so that udev doesn't get blocked on some long running
script triggered from a rule.
By the way since udev has various sandbox rules that restict things
like what sort of sockets you can connect to and what system calls can
be used, this approach could not be recommended.
Another approach that should avoid this problems is
ACTION=="add", SUBSYSTEM=="drm", TAG+="systemd",
ENV{SYSTEMD_WANTS}+="boinc-restart.service"
and then have a simple service (""boinc-restart.service") that does
the restart. By the way this means that the machine will have two
systemd unit files for BOINC client and perhaps even a
boinc-restart.service marked as running among running services.
What do you think about? Thank you for your time
BOINC client systemd unit file:
https://github.com/BOINC/boinc/blob/master/client/scripts/boinc-client.service.in
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Start service after video drivers have been loaded
Il giorno mar 21 mag 2019 alle ore 16:59 Mantas Mikulėnas ha scritto: > Actually, maybe having udev trigger BOINC startup would be a good option? > After all that's how BlueZ already works -- it doesn't go in > multi-user.target, it has WantedBy=bluetooth.target and there's an udev rule > that makes every Bluetooth device pull in bluetooth.target as a dependency. > And that's already an official systemd thing, too. No because BOINC client can even run on systems without graphic card. I will try an approach of restarting BOINC client as soon a new dev-dri-card0.device appears ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] interacting with logind to detect user idle time
I have sent the following message to various desktop environment mailing lists SUBJECT: Proposal: passing user idle time to systemd-logind KDE Plasma: https://mail.kde.org/pipermail/plasma-devel/2019-May/098194.html GNOME: https://mail.gnome.org/archives/desktop-devel-list/2019-May/msg00088.html XFCE https://mail.xfce.org/pipermail/xfce4-dev/2019-May/032257.html LXDE: https://sourceforge.net/p/lxde/mailman/message/36674273/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] interacting with logind to detect user idle time
Il giorno mer 22 mag 2019 alle ore 11:41 Mantas Mikulėnas ha scritto: > On Wed, May 22, 2019, 12:37 Germano Massullo > wrote: >> Second question: perhaps can be useful if I start a topic in GNOME / >> KDE Plasma development mailing lists asking them to make patches that >> will let systemd-logind know about user idle time. By doing this, >> Linux distro world could use systemd-logind as single solution for >> detecting user idle time, making easier the work of third party >> developers > > Hmm, doesn't GNOME 3 already do this? Seem to not doing it because the properties IdleSinceHint IdleSinceHintMonotonic are always equal to zero even on GNOME 3 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] interacting with logind to detect user idle time
Il giorno mer 22 mag 2019 alle ore 11:17 Mantas Mikulėnas ha scritto: > If your program is already X11-based, you could use the screensaver protocol > to get idle status and forward it to logind. BOINC client is just a service, and it runs on machines that can run X11, Wayland, or no graphical session. So if with screensaver protocol you meant XScreensaver API, this unfortunately will not fit my needs. Perhaps instead of using a single solution for all of them I have to write some code that will adapt at least to the main desktop environments, by asking to them the user idle time. Second question: perhaps can be useful if I start a topic in GNOME / KDE Plasma development mailing lists asking them to make patches that will let systemd-logind know about user idle time. By doing this, Linux distro world could use systemd-logind as single solution for detecting user idle time, making easier the work of third party developers ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] interacting with logind to detect user idle time
Good day.
I have noticed that on many Linux distributions with different desktop
environments, the properties
IdleSinceHint
IdleSinceHintMonotonic
are always equal to zero. This happens even if you try to use a sleep
in order to simulate a kind of user inactivity.
What is this happening?
I have written a little piece of code that is able to print on
standard output the IdleSinceHint
Thank you!
/*
* Compile with:
* gcc -Wall print_user_idle_time.c -o print_user_idle_time `pkg-config --libs gio-2.0 --cflags`
*/
#include
static void
print_user_idle_time (GDBusProxy *proxy)
{
guint64 user_idle_time;
gchar *property = "IdleSinceHint";
GError *error = NULL;
GVariant *ret = NULL;
sleep(2);
ret = g_dbus_proxy_get_cached_property(proxy, property);
if (!ret) {
g_dbus_error_strip_remote_error (error);
g_print ("IdleSinceHint failed: %s\n", error->message);
g_error_free (error);
return;
}
user_idle_time = g_variant_get_uint64 (ret);
/*
/g_variant_get (ret, "(^ao)", &user_idle_time);
has been replaced with
user_idle_time = g_variant_get_uint64 (ret);
*/
g_print("%lu\n", user_idle_time);
g_variant_unref (ret);
}
int
main (int argc, char *argv[])
{
GDBusProxy *proxy = NULL;
gchar *name = "org.freedesktop.login1";
gchar *object_path = "/org/freedesktop/login1";
gchar *interface_name = "org.freedesktop.login1.Manager";
/* Create a D-Bus proxy */
proxy = g_dbus_proxy_new_for_bus_sync (G_BUS_TYPE_SYSTEM,
G_DBUS_PROXY_FLAGS_NONE,
NULL,
name,
object_path,
interface_name,
NULL, NULL);
g_assert (proxy != NULL);
print_user_idle_time (proxy);
g_object_unref (proxy);
return 0;
}
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Start service after video drivers have been loaded
Hello, Fedora / EPEL BOINC comaintainer here. On BOINC client we have a problem. On some Linux distributions BOINC gets loaded before the videocard drivers are loaded, so it does not detect OpenCL/CUDA capabilities. We cannot use graphical.target as wait condition because there can be headless systems without graphic server so this condition cannot be used. What can be a good solution in your opinion? Thank you ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] interacting with logind to detect user idle time
Perfect, thank you very much! ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] interacting with logind to detect user idle time
To do practise I am using NetworkManager example [1] All macros passed as arguments to functions g_dbus_proxy_call_sync g_dbus_proxy_new_for_bus_sync are implemented at [2]. Is there an equivalent of [2] for logind? I made a quick search into systemd repository [3] but I am getting too many results with the search words I am using. I just need to figure out what parameters I have to pass to the previous functions in order to retrieve IdleSinceHint property Thank you for your time [1]: https://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/examples/C/glib/list-connections-gdbus.c [2]: https://github.com/NetworkManager/NetworkManager/blob/master/libnm-core/nm-dbus-interface.h [3]: https://github.com/systemd/systemd ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] interacting with logind to detect user idle time
Il giorno lun 13 mag 2019 alle ore 10:00 Lennart Poettering ha scritto: > Note that it only works correctly on desktops that support it. Thank you for your reply. Why does it work only on desktop environments that support it? I believed that it provides idle infos to the D.E. not viceversa According to this seems that it would not be able to detect user idle time on headless systems where users generally operate by SSH. Have a nice day ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] interacting with logind to detect user idle time
Hi, I am doing some practice with writing software using GDBus API. I need it to implement on BOINC client, user(s) idle time detection by retrieving such info from logind. In order to retrieve user idle time I was thinking of using the property IdleSinceHint. What do you think about? Best regards ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] logind + GDbus API
Il giorno mer 17 ott 2018 alle ore 10:56 Lennart Poettering ha scritto: > > On Mi, 17.10.18 09:50, Germano Massullo (germano.massu...@gmail.com) wrote: > > > Good day, I planned to write a tiny software for testing purposes that > > will use GDbus API to interact with logind, in order to detect user > > idle time. > > I am still studying GDbus API, and I am also looking for some very > > good example of GDbus API + logind usage, in order to learn best > > practices in using both of them. > > Do you know any? I actually have not found anything yet that fits my > > needs, but there should be some for sure. I have just found this > > StackOverflow topic [1] > > If you need help with the gdbus API I'd recommend pinging the glib > mailing lists, they are the most likely to help you with that. gdbus > is not directly related to systemd, we can't really help you here. > > Hope this makes sense, > > Lennart > > -- > Lennart Poettering, Red Hat Yeah no problem! P.S. GMail putted your reply in the spam, I don't know why... ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] logind + GDbus API
Good day, I planned to write a tiny software for testing purposes that will use GDbus API to interact with logind, in order to detect user idle time. I am still studying GDbus API, and I am also looking for some very good example of GDbus API + logind usage, in order to learn best practices in using both of them. Do you know any? I actually have not found anything yet that fits my needs, but there should be some for sure. I have just found this StackOverflow topic [1] Thank you for your time [1]: https://stackoverflow.com/questions/37185735/sample-program-for-gdbus-signals ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] "systemd-nspawn -b ..." works, "machinectl start" fails with "ethtool ioctl" related errors
Days ago I found out the real cause of this problem: (SELinux bugreport) machinectl user experience is completely broken https://bugzilla.redhat.com/show_bug.cgi?id=1416540 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] "systemd-nspawn -b ..." works, "machinectl start" fails with "ethtool ioctl" related errors
It looks like the problem is systemd-networkd disabled on both host machine and container. Thanks to Francesco Frassinelli for the hint ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] "systemd-nspawn -b ..." works, "machinectl start" fails with "ethtool ioctl" related errors
Errata corrige: # cat /etc/systemd/nspawn/theta-1.nspawn is # cat /etc/systemd/nspawn/test.nspawn ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] "systemd-nspawn -b ..." works, "machinectl start" fails with "ethtool ioctl" related errors
Hi everybody. I am used to create and use systemd-nspawn containers (on Fedora 25) with the following few lines of bash # lvcreate --name test -L 200G vg_machines # mkfs.ext4 /dev/vg_machines/test # mkdir /var/lib/machines/test # mount /dev/vg_machines/test /var/lib/machines/test # dnf --releasever=25 --installroot=/var/lib/machines/test/ install @"Fedora Server" # semanage fcontext -a -t container_file_t "/var/lib/machines/test(/.*)?" # restorecon -R /var/lib/machines/test/ # systemd-nspawn -D /var/lib/machines/test/ --network-bridge=virbr0 --machine=test -bash-4.3# passwd Changing password for user root. passwd: all authentication tokens updated successfully. -bash-4.3# exit Then to boot the container: # systemd-nspawn -b -D /var/lib/machines/test/ --network-bridge=virbr0 --machine=test and everything works fine. Now instead of using # systemd-nspawn -b -D /var/lib/machines/test/ --network-bridge=virbr0 --machine=test I would like to use # machinectl start test to start the container, in order to not leave screen session opened. Unfortunately I am experiencing some troubles in using such command. Everytime I run it, I obtain # journalctl -xe gen 24 19:11:52 host_machine libvirtd[24209]: ethtool ioctl error: No such device gen 24 19:11:52 host_machine NetworkManager[1503]: [1485281512.7412] device (vb-test): driver 'veth' does not support carrier detection. gen 24 19:11:52 host_machine libvirtd[24209]: ethtool ioctl error: No such device gen 24 19:11:52 host_machine libvirtd[24209]: ethtool ioctl error: No such device gen 24 19:11:52 host_machine libvirtd[24209]: ethtool ioctl error: No such device gen 24 19:11:52 host_machine libvirtd[24209]: ethtool ioctl error: No such device gen 24 19:11:52 host_machine libvirtd[24209]: ethtool ioctl error: No such device gen 24 19:11:52 host_machine libvirtd[24209]: ethtool ioctl error: No such device gen 24 19:11:52 host_machine libvirtd[24209]: ethtool ioctl error: No such device gen 24 19:11:52 host_machine systemd[1]: systemd-nspawn@test.service: Main process exited, code=exited, status=1/FAILURE gen 24 19:11:52 host_machine systemd[1]: systemd-nspawn@test.service: Killing process 4343 (systemd-nspawn) with signal SIGKILL. gen 24 19:11:52 host_machine systemd[1]: systemd-nspawn@test.service: Killing process 4343 (systemd-nspawn) with signal SIGKILL. gen 24 19:11:52 host_machine systemd[1]: Failed to start Container test. -- Subject: Unit systemd-nspawn@test.service failed -- Defined-By: systemd -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- Unit systemd-nspawn@test.service failed. -- -- The result is failed. gen 24 19:11:52 host_machine systemd[1]: systemd-nspawn@test.service: Unit entered failed state. gen 24 19:11:52 host_machine audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-nspawn@test comm="sy gen 24 19:11:52 host_machine systemd[1]: systemd-nspawn@test.service: Failed with result 'exit-code'. I attach some other infos # machinectl list-images NAMETYPE RO USAGE CREATED MODIFIED test directory no n/a n/a n/a 1 images listed. # cat /etc/systemd/nspawn/theta-1.nspawn # created by me [Network] Bridge=virbr0 I made many tries but I had no success. What do you suggest me to try? Thank you for your time Best regards ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
