[systemd-devel] rename a block device
hi, the udev rules prohibit renaming anything other than a network device : what is (would be) the way to really rename a block device (not just to create a symbolic link) ? the objective behind this question is (would be) to give access to the block device through an associated read-only loop device (eg. as a logical forensic write-blocker). here is the idea very roughly : SUBSYSTEM=="block", NAME=".%k", RUN="/usr/local/bin/fakeblkdev %k" # this doesn't work :-( and taking for example /dev/sda and /dev/loop0 : instead of being called /dev/sda, the device would be called /dev/.sda (would be slightly "hidden"), it would be accessible through /dev/loop0 with losetup -r /dev/loop0 /dev/.sda and would finally be made "normal" with ln -s /dev/loop0 /dev/sda. the script /usr/local/bin/fakeblkdev called by udev would do most of the association work between block device and loop device. regards, lacsaP.
Re: [systemd-devel] rename a block device
thanks for this quick feedback Lennart. don't worry, this is not an evolution request for systemd :-) yes for blockdev --setro and, unfortunately, yes for overflows from file systems. *I had once considered using qemu-nbd/snapshot to "tolerate" some writes without altering the real device (because absorbed by the snapshot)...* regards, lacsaP. Le lun. 25 avr. 2022 à 16:33, Lennart Poettering a écrit : > On Mo, 25.04.22 16:25, Pascal ([email protected]) wrote: > > > hi, > > > > the udev rules prohibit renaming anything other than a network device : > > what is (would be) the way to really rename a block device (not just to > > create a symbolic link) ? > > This functionality does not exist in the kernel to my knowledge. And > the uevents for renaming network interface devices are messy enough to > handle, let's please not add this for another subsystem! > > Are you aware of the udev.blockdev_read_only kernel cmdline option > btw? > > (note that Linux is broken, marking a block device read-only actually > is cosmetics mostly. File systems you mount from them may and do still > write to the devices happily regardless whether read-only or > not. Event through loopbck devices actually. You need to pass > 'norecovery' as mount option to relevant file systems if you want > true read-only access. It's crazy, if you ask me) > > Lennart > > -- > Lennart Poettering, Berlin >
[systemd-devel] killmode
hi, is it possible to influence the *killmode* of a script launched by an udev rule ? I have a udev rule that starts a script that itself starts qemu-nbd that gets killed once the script is finished (qemu-nbd links a block device to an nbd node). it is not strictly speaking a *long-running process* but it is a child who survives his father and who is killed when his father stops living successfully ! what a strange world these children live in... ;-) regards, lacsaP.
Re: [systemd-devel] killmode
not really in the sense that qemu-nbd launches and immediately gives the hand back to the script that called it. the script ends positively and qemu-nbd is killed by systemd because it is considered to be garbage left behind by the script. this is not quite the case of a timeout that systemd terminates, but the result is the same. in this case, qemu-nbd looks more like a daemon. I was wondering if there was a way to propagate the killmode through a udev rule that starts a script (like a service)... but it seems from the documentation that the answer is no :-( *"""In order to activate long-running processes from udev rules, provide a service unit and pull it in from a udev device using the SYSTEMD_WANTS device property. See systemd.device(5) <https://www.freedesktop.org/software/systemd/man/systemd.device.html#> for details."""* I would appreciate (and maybe I won't be the only one) a concrete example based, for example, on my problem ;-) let's just say that my rule is : KERNEL=="sdb", RUN+="/usr/local/sbin/myscript" and my script is : #!/usr/bin/bash qemu-nbd -r -s -f raw -c /dev/nbd0 /dev/sdb regards, lacsaP. Le ven. 20 mai 2022 à 17:43, Mike Gilbert a écrit : > On Fri, May 20, 2022 at 10:51 AM Pascal wrote: > > it is not strictly speaking a long-running process but it is a child who > survives his father and who is killed when his father stops living > successfully ! what a strange world these children live in... ;-) > > Sorry, I missed this last line. Are you sure it isn't long-running? It > really makes no sense for it to fork this way. >
Re: [systemd-devel] killmode
will try in this way.
thanks for feedback.
regards, lacsaP.
Le ven. 20 mai 2022 à 19:38, Mike Gilbert a écrit :
> On Fri, May 20, 2022 at 1:34 PM Mike Gilbert wrote:
> >
> > On Fri, May 20, 2022 at 12:54 PM Pascal wrote:
> > >
> > > not really in the sense that qemu-nbd launches and immediately gives
> the hand back to the script that called it.
> > > the script ends positively and qemu-nbd is killed by systemd because
> it is considered to be garbage left behind by the script.
> > > this is not quite the case of a timeout that systemd terminates, but
> the result is the same.
> > > in this case, qemu-nbd looks more like a daemon.
> > >
> > > I was wondering if there was a way to propagate the killmode through a
> udev rule that starts a script (like a service)... but it seems from the
> documentation that the answer is no :-(
> > >
> > > """In order to activate long-running processes from udev rules,
> provide a service unit and pull it in from a udev device using the
> SYSTEMD_WANTS device property. See systemd.device(5) for details."""
> > > I would appreciate (and maybe I won't be the only one) a concrete
> example based, for example, on my problem ;-)
> > >
> > > let's just say that my rule is :
> > >
> > > KERNEL=="sdb", RUN+="/usr/local/sbin/myscript"
> > >
> > > and my script is :
> > >
> > > #!/usr/bin/bash
> > > qemu-nbd -r -s -f raw -c /dev/nbd0 /dev/sdb
> >
> > The most direct translation would be something like this:
> >
> > qemu-nbd0-sdb.service:
> > [Service]
> > ExecStart=qemu-nbd -r -s -f raw -c /dev/nbd0 /dev/sdb
> >
> > udev rule:
> > KERNEL=="sdb", ENV{SYSTEMD_WANTS}+="qemu-nbd0-sdb.service"
>
> Oh, you'll want to add Type=forking to the .service file if it always
> forks a child and exits.
>
Re: [systemd-devel] Preventing automatic driver loading on live boot disk
an udev specific rule may be... Le mer. 16 nov. 2022 à 10:41, Andrei Borzenkov a écrit : > On Wed, Nov 16, 2022 at 12:25 PM Vadim Lebedev > wrote: > > > > I'm preparing ubuntu-based live boot disk. It works fine mostly, but on > some machines equipped with Nvidia Quadro cards the default nouveau driver > causes problems (temporary freezes). I've determined that buy blacklisting > nouveau driver (in /etc/modprobe.d/blacklist.conf) I can fix the problem. > However this approach inhibits nouveau driver for every nvidia equipped > machine which is an overkill. Of course, i can detect the presence of the > Quadro card after the boot, blacklist it, do update-initramfs -u and reboot > but this approach modifies live boot disk and I would like to avoid that. I > wonder if there is a way to detect the presence of nvidia Quadro somewhere > very early in the boot sequence and prevent loading of the offending driver > and fall back to standard VESA driver. > > > > I've tried too create a service file: > > [Unit] > > Description=Disable Nouveau driver > > DefaultDependencies=no > > Before=kmod.service > > > > Drivers for devices are usually loaded dynamically by udev. What does > kmod.service do? I would guess you rather want > Before=systemd-udevd.service. > > > > > [Service] > > Type=oneshot > > ExecStart=/usr/bin/ocd-blacklist-nouveau.sh > > > > > > and the shell script > > #!/bin/bash > > set -x > > if /usr/bin/lspci | /usr/bin/grep Quadro >/dev/null; then > >/usr/bin/logger Found Nvidia Quadro device. Disabling Nouveau driver > >echo blacklist nouveau >/etc/modprobe.d/blacklist-nouveau.conf > > else > >rm -f /etc/modprobe.d/blacklist-nouveau.conf > > fi > > > > But it seems that the service is not executed... > > > > For service to be executed something needs to cause this service to be > executed - other unit dependency or explicit request to start. The > mere presence of unit definition on disk does not mean systemd will > try to activate it. You can manually create links of use usual install > section > > [Install] > WantedBy=default.target > > followed by "systemctl enable your.service". > > Or you could create a generator that runs before systemd begins > activating any service. >
Re: [systemd-devel] homed, LUKS2 passphrase encoding, and recovery key
could cryptsetup be "insensitive" to the configured keyboard layout and adopt/toggle the US/ASCII layout ? as the physical keys on the keyboard do not move ;-), the end user would enter the password he wants and cryptsetup would only receive ASCII characters... let's say I use "zézé" (french keyboard) as a password : well for me, as an end user, changing context doesn't change anything, I always press the same keys [Z] and [é2~] and I always think my password is "zézé", but the password that protects my data is in fact w2w2. Le ven. 24 janv. 2020 à 05:30, Andrei Borzenkov a écrit : > 24.01.2020 06:56, Alexander E. Patrakov пишет: > >> > >> I assume users want their login passphrase to use local characters. > > > > That's just an assumption, with no data presented to back it up. > > > > I have seen enough cases when users memorized Russian passwords and > entered ASCII characters based on keyboard layout mapping (they actually > mentally entered *Cyrillic* characters). I do not have any > scientifically relevant data though. > ___ > systemd-devel mailing list > [email protected] > https://lists.freedesktop.org/mailman/listinfo/systemd-devel > ___ systemd-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] renamed link
hi, I rename my network cards (with udev rule or systemd .link file) in order to use their new name everywhere else: sysctl, systemd-networkd, samba, iptables, etc ... unfortunately, sysctl and systemd-networkd are started before the name change and the defined configurations are not applied to my cards :-( is there a way to start the name change before the rest ? it would even seem more "logical"... actualy, I must restart systemd-networkd service and replay sysctl :-( regards, lacsaP. ___ systemd-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] renamed link
is udev responsible for linking the system with the hardware? in this case, why does renaming not take place at the very first level ? which would make new name available for all other levels... hardware detected (plugged or in place) : ~> udev : ~> rename with defined rule (or not) : ~> systemd etc... (with new name available) thanks for sysctl tip :-) 2017-05-19 1:52 GMT+02:00 Zbigniew Jędrzejewski-Szmek : > On Thu, May 18, 2017 at 11:51:25PM +0200, Pascal wrote: > > hi, > > > > I rename my network cards (with udev rule or systemd .link file) in order > > to use their new name everywhere else: sysctl, systemd-networkd, samba, > > iptables, etc ... > > > > unfortunately, sysctl and systemd-networkd are started before the name > > change and the defined configurations are not applied to my cards :-( > > > > is there a way to start the name change before the rest ? it would even > > seem more "logical"... > That's not possible. Network cards can appear at any time: usb cards > can be detected slowly, and hardware can be plugged in at any time, etc. > > > actualy, I must restart systemd-networkd service and replay sysctl :-( > sysctl settings for a network interface can be applied after the > interface is detected, see 99-systemd.rules. > > Zbyszek > ___ systemd-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] renamed link
and I'm running/testing on version 232 2017-05-19 16:06 GMT+02:00 Pascal : > note that it's about version 210 (year 2014) > > 2017-05-19 16:04 GMT+02:00 Pascal : > >> hi Lennart, >> >> I read this on https://coreos.com/blog/intro-to-systemd-networkd.html : >> >> *"Also, we should note that networkd is only made aware of new network >> devices after udev has applied its low-level settings to them, so we can >> safely match on the new MACAddress and Name that udev has set for our >> device."* >> >> if I understand correctly, systemd-networkd operates in a second time, so >> that we can safely use the new name given by udevd. >> I can't find this information in the systemd / udevd documentation : is >> this information correct ? >> >> regards, lacsaP. >> >> 2017-05-19 11:23 GMT+02:00 Lennart Poettering : >> >>> On Fri, 19.05.17 09:02, Pascal ([email protected]) wrote: >>> >>> > is udev responsible for linking the system with the hardware? >>> > in this case, why does renaming not take place at the very first level >>> ? >>> > which would make new name available for all other levels... >>> >>> renaming takes place as part of the udev rule processing, and clients >>> listeing to udev events will be notified only after the renaming took >>> place. >>> >>> Lennart >>> >>> -- >>> Lennart Poettering, Red Hat >>> >> >> > ___ systemd-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] renamed link
hi Lennart, I read this on https://coreos.com/blog/intro-to-systemd-networkd.html : *"Also, we should note that networkd is only made aware of new network devices after udev has applied its low-level settings to them, so we can safely match on the new MACAddress and Name that udev has set for our device."* if I understand correctly, systemd-networkd operates in a second time, so that we can safely use the new name given by udevd. I can't find this information in the systemd / udevd documentation : is this information correct ? regards, lacsaP. 2017-05-19 11:23 GMT+02:00 Lennart Poettering : > On Fri, 19.05.17 09:02, Pascal ([email protected]) wrote: > > > is udev responsible for linking the system with the hardware? > > in this case, why does renaming not take place at the very first level ? > > which would make new name available for all other levels... > > renaming takes place as part of the udev rule processing, and clients > listeing to udev events will be notified only after the renaming took > place. > > Lennart > > -- > Lennart Poettering, Red Hat > ___ systemd-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] renamed link
note that it's about version 210 (year 2014) 2017-05-19 16:04 GMT+02:00 Pascal : > hi Lennart, > > I read this on https://coreos.com/blog/intro-to-systemd-networkd.html : > > *"Also, we should note that networkd is only made aware of new network > devices after udev has applied its low-level settings to them, so we can > safely match on the new MACAddress and Name that udev has set for our > device."* > > if I understand correctly, systemd-networkd operates in a second time, so > that we can safely use the new name given by udevd. > I can't find this information in the systemd / udevd documentation : is > this information correct ? > > regards, lacsaP. > > 2017-05-19 11:23 GMT+02:00 Lennart Poettering : > >> On Fri, 19.05.17 09:02, Pascal ([email protected]) wrote: >> >> > is udev responsible for linking the system with the hardware? >> > in this case, why does renaming not take place at the very first level ? >> > which would make new name available for all other levels... >> >> renaming takes place as part of the udev rule processing, and clients >> listeing to udev events will be notified only after the renaming took >> place. >> >> Lennart >> >> -- >> Lennart Poettering, Red Hat >> > > ___ systemd-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] log queries on DHCPServer provided by systemd-networkd
hi, how to enable DHCPServer log queries ? I can't find any trace of conversations in the journal. regards, lacsaP. ___ systemd-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd-nspawn
hi, I'm discovering and playing with systemd-nspawn and I must say it's pretty cool ! I have a question about the --port option : why it doesn't work on the loopback with --private-network option ? eg "systemd-nspawn -b -D my_container --private-network --port 1234" doesn't connect the port 1234 of the loopback host with the port 1234 of the loopback container. regards, lacsaP. ___ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-nspawn
hi again, some calrification : I'm on archlinux and systemd version is systemd 228 +PAM -AUDIT -SELINUX -IMA -APPARMOR +SMACK -SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN the systemd-nspawn documentation <http://www.freedesktop.org/software/systemd/man/systemd-nspawn.html> says *-p, --port=If private networking is enabled, maps an IP port on the host onto an IP port on the container. Takes a protocol specifier (either "tcp" or "udp"), separated by a colon from a host port number in the range 1 to 65535, separated by a colon from a container port number in the range from 1 to 65535. The protocol specifier and its separating colon may be omitted, in which case "tcp" is assumed. The container port number and its colon may be omitted, in which case the same port as the host port is implied. This option is only supported if private networking is used*, such as with --network-veth or --network-bridge=. with "systemd-nspawn -b -D my_container --private-network --port 1234", *private networking is enabled* and we could imagine that the port association is done on the loopback interface, no ? it would be good for isolating container without having to set a network configuration (bridge or other)... for example, in my container, I've redis and nodebb, with redis listening on 127.0.0.1:6379 and nodebb on 127.0.0.1:4567, and, on my host, nginx which listening on 0.0.0.0:80 and act as reverse proxy for nodebb : with "systemd-nspawn -b -D nodebb --private-network --port 4567" and without other network setting, I could access nodebb just with "proxy_pass http://127.0.0.1:4567;"; in nginx. regards, lacsaP. 2016-01-25 0:10 GMT+01:00 Pascal : > hi, > > I'm discovering and playing with systemd-nspawn and I must say it's > pretty cool ! > > I have a question about the --port option : why it doesn't work on the > loopback with --private-network option ? > > eg "systemd-nspawn -b -D my_container --private-network --port 1234" > doesn't connect the port 1234 of the loopback host with the port 1234 of > the loopback container. > > regards, lacsaP. > ___ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-nspawn
hi it's me again ;-), with options *network-bridge* or *network-veth*, you « need » to configure network host card *ve-container@if2* and network container card *host0@if5* .. with my request, the idea would be to not disconnect the loopback device and so, without network configuration, the container could simply expose network services throught the host... instead of the option *port* to run with the option *private-network*, this could be a new option (lo-network) that doesn't totally disconnect the network of the two systems, but leaves only loopback device... regards, lacsaP. 2016-01-25 18:39 GMT+01:00 Pascal : > hi again, > > some calrification : I'm on archlinux and systemd version is > systemd 228 > +PAM -AUDIT -SELINUX -IMA -APPARMOR +SMACK -SYSVINIT +UTMP +LIBCRYPTSETUP > +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN > > the systemd-nspawn documentation > <http://www.freedesktop.org/software/systemd/man/systemd-nspawn.html> says > > *-p, --port=If private networking is enabled, maps an IP port on the > host onto an IP port on the container. Takes a protocol specifier (either > "tcp" or "udp"), separated by a colon from a host port number in the range > 1 to 65535, separated by a colon from a container port number in the range > from 1 to 65535. The protocol specifier and its separating colon may be > omitted, in which case "tcp" is assumed. The container port number and its > colon may be omitted, in which case the same port as the host port is > implied. This option is only supported if private networking is used*, > such as with --network-veth or --network-bridge=. > > with "systemd-nspawn -b -D my_container --private-network --port 1234", > *private > networking is enabled* and > we could imagine that the port association is done on the loopback > interface, no ? > > it would be good for isolating container without having to set a network > configuration (bridge or other)... > > for example, in my container, I've redis and nodebb, with redis listening > on 127.0.0.1:6379 and nodebb on 127.0.0.1:4567, and, on my host, nginx > which listening on 0.0.0.0:80 and act as reverse proxy for nodebb : with > "systemd-nspawn > -b -D nodebb --private-network --port 4567" and without other network > setting, I could access nodebb just with "proxy_pass http://127.0.0.1:4567;"; > in nginx. > > regards, lacsaP. > > 2016-01-25 0:10 GMT+01:00 Pascal : > >> hi, >> >> I'm discovering and playing with systemd-nspawn and I must say it's >> pretty cool ! >> >> I have a question about the --port option : why it doesn't work on the >> loopback with --private-network option ? >> >> eg "systemd-nspawn -b -D my_container --private-network --port 1234" >> doesn't connect the port 1234 of the loopback host with the port 1234 of >> the loopback container. >> >> regards, lacsaP. >> > > ___ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Systemd of course
Hi, I need some help to (even) understand systemd process (philosophy)... How, from a service, stop the boot process if an error occurs in this service? For example, a bash script do a check and return false or true. If true returned, all is ok and the boot process go on with default target and display-manager.service. If false returned, the "bash script" service stop the boot process. Thanks, lacsaP. ___ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd debug out of memory
Hi List, I've subscribed to this list to ask for help in debugging a problem we seem to have with the socket activated telnetd on a rhel7 system. A default install of telnetd collects data from some small boxes deployed in the field. It works for a long time and then suddenly: Feb 26 17:46:53 bibr systemd: Created slice user-6006.slice. Feb 26 17:46:53 bibr systemd: Starting user-6006.slice. Feb 26 17:46:53 bibr systemd: Started Session 2223341 of user . Feb 26 17:46:53 bibr systemd-logind: New session 2223341 of user . Feb 26 17:46:53 bibr systemd: Starting Session 2223341 of user . Feb 26 17:46:53 bibr systemd: Started Telnet Server (:28830). Feb 26 17:46:53 pbibr001 systemd: Starting Telnet Server (:28830)... Feb 26 17:46:57 bibr systemd: Failed to fork: Cannot allocate memory Feb 26 17:46:57 bibr systemd: Assertion 'pid >= 1' failed at src/core/unit.c:1996, function unit_watch_pid(). Aborting. Feb 26 17:46:57 bibr001 systemd: Caught , cannot fork for core dump: Cannot allocate memory Feb 26 17:46:57 bibr systemd: Freezing execution. Feb 26 17:47:22 bibr dbus[768]: [system] Failed to activate service 'org.freedesktop.systemd1': timed out Feb 26 17:47:22 bibr dbus-daemon: dbus[768]: [system] Failed to activate service 'org.freedesktop.systemd1': timed out Feb 26 17:47:22 bibr systemd-logind: Failed to start session scope session-2223342.scope: Activation of org.freedesktop.systemd1 timed out org.freedesktop.DBus.Error.TimedOut Feb 26 17:47:47 bibr dbus[768]: [system] Failed to activate service 'org.freedesktop.systemd1': timed out Feb 26 17:47:47 bibr systemd-logind: Failed to abandon session scope: Connection timed out Feb 26 17:47:47 bibr dbus-daemon: dbus[768]: [system] Failed to activate service 'org.freedesktop.systemd1': timed out And after the systemd: Freezing execution. systemctl is no longer able to communicate with systemd. It has all the looks of a memory leak somewhere (systemd (-logind) or telnetd) but how can I debug this... Pascal Kolijn Vrije Universiteit - Amsterdam ___ systemd-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd debug out of memory
Peace, On 28/02/2017 16:00, Lennart Poettering wrote: > On Tue, 28.02.17 13:26, Pascal kolijn ([email protected]) wrote: > >> Hi List, >> >> I've subscribed to this list to ask for help in debugging a problem we >> seem to have with the socket activated telnetd on a rhel7 system. >> >> A default install of telnetd collects data from some small boxes >> deployed in the field. It works for a long time and then suddenly: >> >> Feb 26 17:46:53 bibr systemd: Created slice user-6006.slice. >> Feb 26 17:46:53 bibr systemd: Starting user-6006.slice. >> Feb 26 17:46:53 bibr systemd: Started Session 2223341 of user . >> Feb 26 17:46:53 bibr systemd-logind: New session 2223341 of user . >> Feb 26 17:46:53 bibr systemd: Starting Session 2223341 of user . >> Feb 26 17:46:53 bibr systemd: Started Telnet Server (:28830). >> Feb 26 17:46:53 pbibr001 systemd: Starting Telnet Server (:28830)... >> Feb 26 17:46:57 bibr systemd: Failed to fork: Cannot allocate memory > > Hmm, Linux fork() returns ENOMEM if the maximum number of tasks on the > system is hit (yes this is a bit misleading, but that's how it is). > That max number of tasks is limited for example by the max number of > assignable pids as configured in /proc/sys/kernel/pid_max? Maybe you > hit that limit? Maybe something is leaking pids on your system? not > reaping zombies properly? As far as I can determine running out of pids is not the issue, as I can see pids being reused in a day, which will not say that some may still go missing over time, but how do I determine if that is the case...? What I do see is that the rss of the systemd process is slowly growing over time in the production environment. I've not been able (yet) to reproduce the situation in a test environment, which is a pity. I think I can simulate the telnet connects more accurately after I speak with the developer of the said boxes, and see if I can create a reproducible situation. >> Feb 26 17:46:57 bibr systemd: Assertion 'pid >= 1' failed at >> src/core/unit.c:1996, function unit_watch_pid(). Aborting. >> Feb 26 17:46:57 bibr001 systemd: Caught , cannot fork for core >> dump: Cannot allocate memory >> Feb 26 17:46:57 bibr systemd: Freezing execution. > > So this is definitely a bug. If the limit is hit, we hould certainly > not hit an assert. I tried to figure out how this could ever happen, > but afaics this should not be possible on current git at least. Any > chance you can try to reproduce this isue with something more recent > than a rhel7 box? Hmmm, the version we currently use in production is: # rpm -qa | grep systemd systemd-libs-219-19.el7_2.13.x86_64 systemd-219-19.el7_2.13.x86_64 systemd-sysv-219-19.el7_2.13.x86_64 I think I can update it to the current state in 7.3 for the production machine, but will be reluctant to go for a more recent version... Maybe in the test env, if I can reproduce it there. > Either way it appears that there's both a bug on your setup and in > systemd: something leaks processes (which is bug #1, in your setup) > and then systemd doesn't deal properly with that (which is bug #2, in > systemd upstream)... > > Lennart > Pascal Kolijn Vrije Universiteit Amsterdam ___ systemd-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] udev rule to mount ext4 with data=journal
Hello everyone,
I am new to this list and to udev (used mdev before).
My goal: Mount a CFast card partioned with 2 partitions one FAT32 and one
EXT4, the EXT4 I would like to mount with option "data=journal"
The Problem: from the console using mount the partition can be mounted with
mount -o "data=journal" ... but not from my udev rule. My rule results in
only the FAT32 partition being mounted.
My Rule:
KERNEL!="sd[a-z][0-9]", GOTO="media_by_label_auto_mount_end"
# Import FS infos
IMPORT{program}="/sbin/blkid -o udev -p %N"
# Global mount options
ACTION=="add", ENV{mount_options}="relatime"
# Filesystem-specific mount options
ACTION=="add", ENV{ID_FS_TYPE}=="vfat|ntfs",
ENV{mount_options}="$env{mount_options},utf8,gid=100,umask=002"
ACTION=="add", ENV{ID_FS_TYPE}=="ext4",
ENV{mount_options}="$env{mount_options},data=journal"
#Mount the Filesystems
ACTION=="add", RUN+="/bin/mkdir -p /media/$env{ID_FS_LABEL}",
RUN+="/bin/mount -o %E{mount_options} /dev/%k /media/$env{ID_FS_LABEL}"
# Exit
LABEL="media_by_label_auto_mount_end"
Any help is highly appreciated, so far I can only mount with "data=ordered"
since this seems to be the default option (for that the two lines matching
"ENV{ID_FS_TYPE} are removed).
Best regards
Pascal
___
systemd-devel mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] udev rule to mount ext4 with data=journal
I try to achieve that regardless the device plugged to my embedded system the mount will be in folder /media/"name_of_volume". If I understand correctly for the usage of fstab I have to give a static name for the mount point. Thanks for pointing out the "nofail" option. Best regards, Pascal Lennart Poettering schrieb am Mi., 14. Juni 2017 um 10:06 Uhr: > On Wed, 14.06.17 07:30, Pascal K ([email protected]) wrote: > > > Hello everyone, > > > > I am new to this list and to udev (used mdev before). > > > > My goal: Mount a CFast card partioned with 2 partitions one FAT32 and one > > EXT4, the EXT4 I would like to mount with option "data=journal" > > > > The Problem: from the console using mount the partition can be mounted > with > > mount -o "data=journal" ... but not from my udev rule. My rule results in > > only the FAT32 partition being mounted. > > Note that we run udevd in its own mount namespace through MountFlags=, > and this means no mounts will ever appear on the host anyway. > > Note that it is sufficient to mark mounts as "auto,nofail" in > /etc/fstab to make sure they are mounted automatically as they appear > without making the boot wait for it. > > Lennart > > -- > Lennart Poettering, Red Hat > ___ systemd-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] udev rule to mount ext4 with data=journal
As I am on a embedded device I am trying to avoid the usage of systemd due
to serveral reasons.
@Lennart
I try to follow your point:
> Note that we run udevd in its own mount namespace through MountFlags=,
> and this means no mounts will ever appear on the host anyway.
Am I right that this means that with setting ENV{mount_options} I am
setting a variable from udevd namespace, therefore "...mount -o
%E{mount_options}..." should try to run /sbin/mount with the options I
selected before?
Best regards,
Pascal
Lennart Poettering schrieb am Mi., 14. Juni 2017
um 10:30 Uhr:
> On Wed, 14.06.17 08:11, Pascal K ([email protected]) wrote:
>
> > I try to achieve that regardless the device plugged to my embedded system
> > the mount will be in folder /media/"name_of_volume".
> >
> > If I understand correctly for the usage of fstab I have to give a static
> > name for the mount point.
>
> It appears to me "systemd-mount" is the functionality you want to use
> for this. It will automatically derive a usable name from the device
> metadata and install an automount instance for it, so that there's the
> best chance for the device's file system to always stay in a clean state.
>
> You can invoke systemd-mount directly from the udev rule.
>
> Lennart
>
> --
> Lennart Poettering, Red Hat
>
___
systemd-devel mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] udev rule to mount ext4 with data=journal
To clear things up a bit: I build a Image using Buildroot running Busybox on top. I have SystemVinit. Is there something else commonly used out there? Otherwise I just create my own daemon. Best regards, Pascal Lennart Poettering schrieb am Mi., 14. Juni 2017 um 11:23 Uhr: > On Wed, 14.06.17 08:44, Pascal K ([email protected]) wrote: > > > As I am on a embedded device I am trying to avoid the usage of systemd > due > > to serveral reasons. > > Not sure I follow the logic in the above, but if you don't want to use > systemd, then you should probably run something else that can do most > basic disk management for you. > > udev isn't really the right tool for the job. > > Sorry, > > Lennart > > -- > Lennart Poettering, Red Hat > ___ systemd-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/systemd-devel
