On Thursday, December 18, 2014 at 9:33:57 AM UTC-8, awidde...@hotmail.com
wrote:
>
> Yes, I've found your bug reports and thread on the mailing lists about the
> issue you have been having. Very similar but unfortunately, different as
> you've noticed. Here is the output of the relevant services:
>
> [root@some-server ~]# systemctl status iscsi iscsid remote-fs.target
> remote-fs-pre.target
> iscsi.service - Login and scanning of iSCSI devices
> Loaded: loaded (/usr/lib/systemd/system/iscsi.service; enabled)
> Active: active (exited) since Tue 2014-12-09 09:37:01 EST; 1 weeks 2
> days ago
> Docs: man:iscsid(8)
> man:iscsiadm(8)
> Main PID: 881 (code=exited, status=0/SUCCESS)
>
> Dec 09 09:37:00 some-server systemd[1]: Starting Login and scanning of
> iSCSI devices...
> Dec 09 09:37:00 some-server iscsi-mark-root-nodes[869]: iscsiadm: No
> active sessions.
> Dec 09 09:37:01 some-server iscsiadm[881]: Logging in to [iface: default,
> target: some-target, portal: 10.174.1.38,3260] (multiple)
> Dec 09 09:37:01 some-server iscsiadm[881]: Login to [iface: default,
> target: some-target, portal: 10.174.1.38,3260] successful.
> Dec 09 09:37:01 some-server systemd[1]: Started Login and scanning of
> iSCSI devices.
>
> iscsid.service - Open-iSCSI
> Loaded: loaded (/usr/lib/systemd/system/iscsid.service; enabled)
> Active: active (running) since Tue 2014-12-09 09:37:00 EST; 1 weeks 2
> days ago
> Docs: man:iscsid(8)
> man:iscsiadm(8)
> Main PID: 857 (iscsid)
> CGroup: /system.slice/iscsid.service
> +-855 /usr/sbin/iscsid
> +-857 /usr/sbin/iscsid
>
> Dec 09 09:37:00 some-server systemd[1]: Starting Open-iSCSI...
> Dec 09 09:37:00 some-server iscsid[850]: iSCSI logger with pid=855 started!
> Dec 09 09:37:00 some-server systemd[1]: Failed to read PID from file
> /var/run/iscsid.pid: Invalid argument
> Dec 09 09:37:00 some-server systemd[1]: Started Open-iSCSI.
> Dec 09 09:37:01 some-server iscsid[855]: iSCSI daemon with pid=857 started!
> Dec 09 09:37:01 some-server iscsid[855]: Connection1:0 to [target:
> some-target, portal: 10.174.1.38,3260] through [ifac...ational now
>
> remote-fs.target - Remote File Systems
> Loaded: loaded (/usr/lib/systemd/system/remote-fs.target; enabled)
> Active: active since Tue 2014-12-09 09:37:03 EST; 1 weeks 2 days ago
> Docs: man:systemd.special(7)
>
> Dec 09 09:37:03 some-server systemd[1]: Starting Remote File Systems.
> Dec 09 09:37:03 some-server systemd[1]: Reached target Remote File Systems.
>
> remote-fs-pre.target - Remote File Systems (Pre)
> Loaded: loaded (/usr/lib/systemd/system/remote-fs-pre.target; static)
> Active: inactive (dead)
> Docs: man:systemd.special(7)
>
> I also noticed "remote-fs-pre.target" is not active and guessed that it
> might be an issue but haven't been able to figure out what needs to be
> changed to correct it from not being active. local-fs-pre.target is active
> and I would think these two would be have the same way for the most part.
>
> I just updated the iscsi.service unit file to include
> "Wants=remote-fs-pre.target" and it seems to have solved the issue! I'm not
> sure how I didn't find this myself. I thought I tried just about
> everything. Also, tried this same thing on RHEL7.1 beta and it seems to be
> fixed there out of the box (no changes necessary). Just looked at the
> iscsi.service file on RHEL7.1 and it has "Wants=remote-fs-pre.target".
>
> I guess, according to the changelog,
> https://bugzilla.redhat.com/show_bug.cgi?id=1161417 may have fixed this
> issue in 6.2.0.873-22? I looked through the patch you uploaded and didn't
> see this particular change and was for the fstab issue, which again seems
> pretty different than this. Nothing else in the changelog
> for iscsi-initiator-utils on RHEL7.1 seems to indicate where this fix might
> have come from.
>
> Thanks for your help. Will this fix get applied to RHEL7.0 eventually?
> Will that happen after 7.1?
>
Posting here since I am running into the same exact issue, however I am
running the MariaDB included with RHEL 7.
We have a slightly different configuration, we use a bonded interface from
a pair of 10Gb NICs, using LACP.
On that bonded interface, have three sub interfaces:
bond0 - parent, max MTU 9000, has these children:
bond0.50 ("public", MTU 1500)
bond0.100 (iSCSI VLAN 100, 10.1.1.10/32, MTU 9000)
bond0.101 (iSCSI VLAN 101, 10.1.2.10/32, MTU 9000)
Firstly, NetworkManager simply wouldn't bring up those bonded
sub-interfaces at all. Redhat support eventually said to give up on
NetworkManager (good riddance... RH needs to dump it, it still isn't
production quality).
Switching to just the network service brings up all the bonded interfaces
just fine. However, on to the next problem.
Second problem is the same as stated above, at shutdown, system would tear
down network interfaces and try to stop iSCSI before unmounting the iSCSI
volumes - this lead to data loss and fun times with MariaDB.
Third problem is startup, RHEL7 MariaDB does not wait for remote volumes to
mount before trying to start:
/etc/systemd/system/multi-user.target.wants/mariadb.service:
[Unit]
Description=MariaDB database server
After=syslog.target
After=network.target
[Service]
Type=simple
User=mysql
Group=mysql
$ systemctl status mariadb
mariadb.service - MariaDB database server
Loaded: loaded (/usr/lib/systemd/system/mariadb.service; enabled)
Active: failed (Result: exit-code) since Fri 2015-01-16 17:26:08 EST;
18min ago
Process: 6132 ExecStartPre=/usr/libexec/mariadb-prepare-db-dir %n
(code=exited, status=1/FAILURE)
Jan 16 17:26:08 mysqldb-01 mariadb-prepare-db-dir[6132]: mkdir: cannot
create directory ‘/mnt/db_data_01/mysql/’: Permission Denies
Jan 16 17:26:08 mysqldb-01 systemd[1]: mariadb.service: control process
exited, code=exited status=1
Jan 16 17:26:08 mysqldb-01 systemd[1]: Failed to start MariaDB database
server.
Jan 16 17:26:08 mysqldb-01 systemd[1]: Unit mariadb.service entered failed
state.
I've added:
"After=remote-fs.target" to mariadb.service as a workaround, but yah..
I don't mind systemd, and in fact I like the structure of the unit files
better than init for sure... but this stuff should've been caught pretty
early on in QA!
Hope this helps other people if they encounter it, and hope some additional
data and use case can help Redhat in the future.
--
You received this message because you are subscribed to the Google Groups
"open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to open-iscsi+unsubscr...@googlegroups.com.
To post to this group, send email to open-iscsi@googlegroups.com.
Visit this group at http://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.
