Re: [systemd-devel] Help: Local and Remote targets
This might be problematic. What will you do with iscsi devices that support iscsi offload? Those are typically completely invisible to the OS and just appear as another HBA. On 8/20/19 3:26 PM, Tony Rodriguez wrote: > I modified systemd-219 functionality to meet a custom requirement for > detecting filesystems/devices that use iscsi without using the _netdev keyword > in /etc/fstab. It is a strict requirement regarding not using _netdev that I > have no control over. However, I am stuck. > > From my understanding, src/fstab-generator.c is used to determine LOCAL-FS and > REMOTE-FS. I have modified fstab-generator.c to search for iscsi udev devices > which works, provided the system is already fully booted (typical multi-user > state type of thing). I can also find /dev/disk/ block devices including > iscsi devices using my logic within fstab-generator.c. The problem is when > the system reboots, it appears systemd using the same fstab-generator logic > that I implemented is unable to detect any iscsi devices. After doing some > research, it appears normal systemd behavior is to mount / and /usr then > invoke fstab-generator.c to determine if a given filesystem in /etc/fstab > should be a local or remote target. > > The problem is I have no way to tell if a given iscsi filesystem/device > specified in /etc/fstab (without the _netdev keyord ) is local/remote during > the booting state. Mainly because devices are not yet populated in /dev/disk > or udev. Is there a way I can determine if a filesystem/mount point/device > specified in /etc/fstab is local or remote without the _netdev or fstype > (which handles nfs, etc) keywords within fstab-generator.c? If checking udev > and /dev/disk are not possible within fstab-generator.c, because such devices > are not yet populated, then what should I modify within the systemd source so > I can determine such local/remote targets myself and pass it to > fstab-generator.c (especially when the system is in that / and /usr mounting > state and udev devices are not yet populated? > > Thanks, > Tony > ___ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/systemd-devel > -- Rick Beldin HPE Master Technologist, ERT HPE Pointnext Tel: +1 470 2129073 Email: rick.bel...@hpe.com Physical: 8000 Foothills Blvd. | Roseville, CA 95747 Hewlett Packard Enterprise ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Restarting a systemd service with new command line options from systemctl?
On 07/07/2018 09:54 AM, Michael Chapman wrote: > On Sat, 7 Jul 2018, Rick Beldin wrote: > [...] >> # systemctl restart systemd-udevd --debug >> systemctl: unrecognized option '--debug' > > You would need to override the service's ExecStart= setting if you wanted > to do it that way. > Ok, so for the general case, this is what I would have to do. Thanks. >> Is there a more supported way of doing this with systemctl for systemd-udevd, >> perhaps in general for all systemd services? I tend to think that there >> isn't, but thought I would I ask. > > For udev in particular you can use: > > udevadm control --log-priority=debug > > to change its log level without restarting it. > Much better solution to this particular issue. Thanks for the reminder. > All of systemd's components will default to a debug log level if "debug" > or "systemd.log_level=debug" appears on the kernel command-line, or if > their environment contains "SYSTEMD_LOG_LEVEL=debug". You could implement > the latter for specific services with drop-in files. > > For the the systemd manager itself, you can also bump its log level by > sending it SIGRTMIN+22 (documented in the systemd(1) manpage). > Perfect. Appreciate the help. Rick -- Rick Beldin HPE Master Technologist, ERT HPE Pointnext Tel: +1 470 2129073 Email: rick.bel...@hpe.com Physical: Windward Parkway West, Alpharetta GA 30004 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Restarting a systemd service with new command line options from systemctl?
Hi...
I was trying to understand some systemd-udevd interactions and from source I
could see that if systemd-udevd was started with --debug option, it would log
additional items, for example:
786 /*
787 * We have partitions but re-reading the partition table
did not
788 * work, synthesize "change" for the disk and all
partitions.
789 */
790 log_debug("device %s closed, synthesising 'change'",
udev_device_get_devnode(dev));
791 strscpyl(filename, sizeof(filename),
udev_device_get_syspath(dev), "/uevent", NULL);
792 write_string_file(filename, "change");
While the man page for systemd-udevd shows this option and others:
/lib/systemd/systemd-udevd [--daemon] [--debug] [--children-max=]
[--exec-delay=]
[--event-timeout=]
[--resolve-names=early|late|never]
[--version] [--help]
I am puzzled as to how I would restart the daemon with anyone of these options
without hacking on the service file or killing the existing systemd-udevd and
starting it up manually. I puzzled over this and tried:
# systemctl restart systemd-udevd --debug
systemctl: unrecognized option '--debug'
Is there a more supported way of doing this with systemctl for systemd-udevd,
perhaps in general for all systemd services? I tend to think that there
isn't, but thought I would I ask.
Rick
--
Rick Beldin
HPE Master Technologist, ERT
HPE Pointnext
Tel: +1 470 2129073 Email: rick.bel...@hpe.com
Physical: Windward Parkway West, Alpharetta GA 30004
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Reliable way to finish system units before termination through systemd shutdown / reboot routines
On 08/31/2017 10:05 AM, Lennart Poettering wrote: > I have running some virtualbox instances under systemd control and use > vboxautostart-service > for starting and stopping (saving). This is running on Centos7 > As long as I use systemctl stop vboxautostart-service for termination, > everything is fine, > but it takes some time for completion. I'm going to guess that this causes vbox to attempt an acpi shutdown for each guest. You may want to monitor the guest console as you do this to verify this. Just a thought... Rick ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
