[jira] [Comment Edited] (CASSANDRA-15273) cassandra does not start with new systemd version
[
https://issues.apache.org/jira/browse/CASSANDRA-15273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16969329#comment-16969329
]
Robert Demski edited comment on CASSANDRA-15273 at 11/7/19 3:33 PM:
h5. Shouldn't cassandra register services in the systemd like other standard
services?
For example in RHEL 7:
{{/usr/lib/systemd/system/sshd.service}}
{code:bash}
[Unit]
Description=OpenSSH server daemon
Documentation=man:sshd(8) man:sshd_config(5)
After=network.target sshd-keygen.service
Wants=sshd-keygen.service
[Service]
Type=notify
EnvironmentFile=/etc/sysconfig/sshd
ExecStart=/usr/sbin/sshd -D $OPTIONS
ExecReload=/bin/kill -HUP $MAINPID
KillMode=process
Restart=on-failure
RestartSec=42s
[Install]
WantedBy=multi-user.target
{code}
{{Of course /etc/init.d/cassandra is then superfluous :)}}
As example it is {{/usr/lib/systemd/system/cassandra.service}} from OpenSUSE
15.1
{code:bash}
[Unit]
Description=Cassandra
After=network.target
[Service]
Environment=CASSANDRA_HOME=/usr/share/cassandra
CASSANDRA_CONF=/etc/cassandra/conf
CASSANDRA_INCLUDE=/usr/share/cassandra/cassandra.in.sh
EnvironmentFile=/etc/sysconfig/cassandra
User=cassandra
ExecStart=/usr/sbin/cassandra -f
ExecStopPost=/usr/bin/sleep 5 ; /usr/bin/rm -f /var/lock/subsys/cassandra
StandardOutput=journal
StandardError=journal
LimitNOFILE=10
LimitMEMLOCK=infinity
LimitNPROC=32768
LimitAS=infinity
SuccessExitStatus=143
TimeoutStopSec=60
Restart=on-failure
[Install]
WantedBy=multi-user.target
{code}
was (Author: demsey):
h5. Shouldn't cassandra register services in the systemd like other standard
services?
{{For example in RHEL 7:}}
{{ /usr/lib/systemd/system/sshd.service}}
{code:bash}
[Unit]
Description=OpenSSH server daemon
Documentation=man:sshd(8) man:sshd_config(5)
After=network.target sshd-keygen.service
Wants=sshd-keygen.service
[Service]
Type=notify
EnvironmentFile=/etc/sysconfig/sshd
ExecStart=/usr/sbin/sshd -D $OPTIONS
ExecReload=/bin/kill -HUP $MAINPID
KillMode=process
Restart=on-failure
RestartSec=42s
[Install]
WantedBy=multi-user.target
{code}
{{Of course /etc/init.d/cassandra is then superfluous :)}}
As example it is {{/usr/lib/systemd/system/cassandra.service}} from OpenSUSE
15.1
{code:bash}
[Unit]
Description=Cassandra
After=network.target
[Service]
Environment=CASSANDRA_HOME=/usr/share/cassandra
CASSANDRA_CONF=/etc/cassandra/conf
CASSANDRA_INCLUDE=/usr/share/cassandra/cassandra.in.sh
EnvironmentFile=/etc/sysconfig/cassandra
User=cassandra
ExecStart=/usr/sbin/cassandra -f
ExecStopPost=/usr/bin/sleep 5 ; /usr/bin/rm -f /var/lock/subsys/cassandra
StandardOutput=journal
StandardError=journal
LimitNOFILE=10
LimitMEMLOCK=infinity
LimitNPROC=32768
LimitAS=infinity
SuccessExitStatus=143
TimeoutStopSec=60
Restart=on-failure
[Install]
WantedBy=multi-user.target
{code}
> cassandra does not start with new systemd version
> -
>
> Key: CASSANDRA-15273
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15273
> Project: Cassandra
> Issue Type: Bug
>Reporter: Aleksandr Yatskin
>Priority: Urgent
>
> After update systemd with fixed vulnerability
> https://access.redhat.com/security/cve/cve-2018-16888, the cassandra service
> does not start correctly.
> Environment: RHEL 7, systemd-219-67.el7_7.1, cassandra-3.11.4-1
> (https://www.apache.org/dist/cassandra/redhat/311x/cassandra-3.11.4-1.noarch.rpm)
> ---
> systemctl status cassandra
> ● cassandra.service - LSB: distributed storage system for structured data
> Loaded: loaded (/etc/rc.d/init.d/cassandra; bad; vendor preset: disabled)
> Active: failed (Result: resources) since Fri 2019-08-09 17:20:26 MSK; 1s ago
> Docs: man:systemd-sysv-generator(8)
> Process: 2414 ExecStop=/etc/rc.d/init.d/cassandra stop (code=exited,
> status=0/SUCCESS)
> Process: 2463 ExecStart=/etc/rc.d/init.d/cassandra start (code=exited,
> status=0/SUCCESS)
> Main PID: 1884 (code=exited, status=143)
> Aug 09 17:20:23 desktop43.example.com systemd[1]: Unit cassandra.service
> entered failed state.
> Aug 09 17:20:23 desktop43.example.com systemd[1]: cassandra.service failed.
> Aug 09 17:20:23 desktop43.example.com systemd[1]: Starting LSB: distributed
> storage system for structured data...
> Aug 09 17:20:23 desktop43.example.com su[2473]: (to cassandra) root on none
> Aug 09 17:20:26 desktop43.example.com cassandra[2463]: Starting Cassandra: OK
> Aug 09 17:20:26 desktop43.example.com systemd[1]: New main PID 2545 does not
> belong to service, and PID file is not owned by root. Refusing.
> Aug 09 17:20:26 desktop43.example.com systemd[1]: New main PID 2545 does not
> belong to service, and PID file is not owned by root. Refusing.
> Aug 09 17:20:26 desktop43.example.com systemd[1]: Fa
[jira] [Comment Edited] (CASSANDRA-15273) cassandra does not start with new systemd version
[ https://issues.apache.org/jira/browse/CASSANDRA-15273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16980248#comment-16980248 ] Felipe edited comment on CASSANDRA-15273 at 11/22/19 3:37 PM: -- Hi Guys, I have the same problem, in Centos7 and Redhat7 with CASSANDRA. could you help me to execute the scrip I tried but it did not work, where I must run it, first I must create a file with the scrip and then execute it so it would be the procedure .. thanks. [root@localhost ~]# service cassandra start Starting cassandra (via systemctl): Job for cassandra.service failed because a configured resource limit was exceeded. See "systemctl status cassandra.service" and "journalctl -xe" for details. [FAILED] [root@localhost ~]# systemctl status cassandra.service ● cassandra.service - LSB: distributed storage system for structured data Loaded: loaded (/etc/rc.d/init.d/cassandra; bad; vendor preset: disabled) Active: failed (Result: resources) since Fri 2019-11-22 10:19:29 -05; 8s ago Docs: man:systemd-sysv-generator(8) Process: 10565 ExecStart=/etc/rc.d/init.d/cassandra start (code=exited, status=0/SUCCESS) Nov 22 10:19:29 localhost.localdomain systemd[1]: Starting LSB: distributed storage system for structured data... Nov 22 10:19:29 localhost.localdomain su[10575]: (to cassandra) root on none Nov 22 10:19:29 localhost.localdomain systemd[1]: New main PID 10649 does not belong to service, and PID file is not owned by root. Refusing. Nov 22 10:19:29 localhost.localdomain cassandra[10565]: Starting Cassandra: OK Nov 22 10:19:29 localhost.localdomain systemd[1]: New main PID 10649 does not belong to service, and PID file is not owned by root. Refusing. Nov 22 10:19:29 localhost.localdomain systemd[1]: Failed to start LSB: distributed storage system for structured data. Nov 22 10:19:29 localhost.localdomain systemd[1]: Unit cassandra.service entered failed state. Nov 22 10:19:29 localhost.localdomain systemd[1]: cassandra.service failed. [root@localhost ~]# was (Author: fcampuzano): Hi Guys, I have the same problem, in Centos7 and Redhat7 with CASSANDRA. could you help me to execute the scrip I tried but it did not work, where I must run it, first I must create a file with the scrip and then execute it so it would be the procedure .. thanks. > cassandra does not start with new systemd version > - > > Key: CASSANDRA-15273 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15273 > Project: Cassandra > Issue Type: Bug >Reporter: Aleksandr Yatskin >Priority: Urgent > > After update systemd with fixed vulnerability > https://access.redhat.com/security/cve/cve-2018-16888, the cassandra service > does not start correctly. > Environment: RHEL 7, systemd-219-67.el7_7.1, cassandra-3.11.4-1 > (https://www.apache.org/dist/cassandra/redhat/311x/cassandra-3.11.4-1.noarch.rpm) > --- > systemctl status cassandra > ● cassandra.service - LSB: distributed storage system for structured data > Loaded: loaded (/etc/rc.d/init.d/cassandra; bad; vendor preset: disabled) > Active: failed (Result: resources) since Fri 2019-08-09 17:20:26 MSK; 1s ago > Docs: man:systemd-sysv-generator(8) > Process: 2414 ExecStop=/etc/rc.d/init.d/cassandra stop (code=exited, > status=0/SUCCESS) > Process: 2463 ExecStart=/etc/rc.d/init.d/cassandra start (code=exited, > status=0/SUCCESS) > Main PID: 1884 (code=exited, status=143) > Aug 09 17:20:23 desktop43.example.com systemd[1]: Unit cassandra.service > entered failed state. > Aug 09 17:20:23 desktop43.example.com systemd[1]: cassandra.service failed. > Aug 09 17:20:23 desktop43.example.com systemd[1]: Starting LSB: distributed > storage system for structured data... > Aug 09 17:20:23 desktop43.example.com su[2473]: (to cassandra) root on none > Aug 09 17:20:26 desktop43.example.com cassandra[2463]: Starting Cassandra: OK > Aug 09 17:20:26 desktop43.example.com systemd[1]: New main PID 2545 does not > belong to service, and PID file is not owned by root. Refusing. > Aug 09 17:20:26 desktop43.example.com systemd[1]: New main PID 2545 does not > belong to service, and PID file is not owned by root. Refusing. > Aug 09 17:20:26 desktop43.example.com systemd[1]: Failed to start LSB: > distributed storage system for structured data. > Aug 09 17:20:26 desktop43.example.com systemd[1]: Unit cassandra.service > entered failed state. > Aug 09 17:20:26 desktop43.example.com systemd[1]: cassandra.service failed. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-15273) cassandra does not start with new systemd version
[
https://issues.apache.org/jira/browse/CASSANDRA-15273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17050339#comment-17050339
]
Michael Semb Wever edited comment on CASSANDRA-15273 at 3/3/20 4:05 PM:
||branch||circleci||
|[cassandra_3.0_15273|https://github.com/apache/cassandra/compare/cassandra-3.0...thelastpickle:mck/cassandra-3.0_15273]|[circleci|https://circleci.com/gh/thelastpickle/workflows/cassandra/tree/mck%2Fcassandra-3.0_15273]|
|[cassandra_3.11_15273|https://github.com/apache/cassandra/compare/cassandra-3.11...thelastpickle:mck/cassandra-3.11_15273]|[circleci|https://circleci.com/gh/thelastpickle/workflows/cassandra/tree/mck%2Fcassandra-3.11_15273]|
|[trunk_15273|https://github.com/apache/cassandra/compare/trunk...thelastpickle:mck/trunk_15273]|[circleci|https://circleci.com/gh/thelastpickle/workflows/cassandra/tree/mck%2Ftrunk_15273]|
To test this, rather than following the instructions in
https://github.com/apache/cassandra/tree/trunk/redhat , I've taken the
following approach:
{code}
docker image rm -f `docker images -f label=org.cassandra.buildenv=centos -q`
docker build --build-arg CASSANDRA_GIT_URL=${CASSANDRA_GIT_URL} -f
docker/centos7-image.docker docker/
mkdir /tmp/cassandra-rpms
docker run --rm -v /tmp/cassandra-rpms:/dist `docker images -f
label=org.cassandra.buildenv=centos -q` /home/build/build-rpms.sh
${CASSANDRA_GIT_BRANCH}
{code}
This is the same approach as we used when cutting and staging releases, ref
https://github.com/thelastpickle/cassandra-builds/blob/mck/14970_sha512-checksums/cassandra-release/prepare_release.sh#L299-L302
Note, we are short of packaging experience in the community and really need
extra contributors on this front. Replacing the old initialisation SysV script
with a service script, and testing the building of packages in the CI pipeline,
are obvious subsequent steps that are needed.
was (Author: michaelsembwever):
||branch||circleci||
|[cassandra_3.0_15273|https://github.com/apache/cassandra/compare/cassandra-3.0...thelastpickle:mck/cassandra-3.0_15273]|[circleci|https://circleci.com/gh/thelastpickle/workflows/cassandra/tree/mck%2Fcassandra-3.0_15273]|
|[cassandra_3.11_15273|https://github.com/apache/cassandra/compare/cassandra-3.11...thelastpickle:mck/cassandra-3.11_15273]|[circleci|https://circleci.com/gh/thelastpickle/workflows/cassandra/tree/mck%2Fcassandra-3.11_15273]|
|[trunk_15273|https://github.com/apache/cassandra/compare/trunk...thelastpickle:mck/trunk_15273]|[circleci|https://circleci.com/gh/thelastpickle/workflows/cassandra/tree/mck%2Ftrunk_15273]|
To test this, rather than following the instructions in
https://github.com/apache/cassandra/tree/trunk/redhat , I've taken the
following approach:
{code}
docker image rm -f `docker images -f label=org.cassandra.buildenv=centos -q`
docker build --build-arg CASSANDRA_GIT_URL=${CASSANDRA_GIT_URL} -f
docker/centos7-image.docker docker/
mkdir /tmp/cassandra-rpms
docker run --rm -v /tmp/cassandra-rpms:/dist `docker images -f
label=org.cassandra.buildenv=centos -q` /home/build/build-rpms.sh
${CASSANDRA_GIT_BRANCH}
{code}
Note, we are short of packaging experience in the community and really need
extra contributors on this front. Replacing the old initialisation SysV script
with a service script, and testing the building of packages in the CI pipeline,
are obvious subsequent steps that are needed.
> cassandra does not start with new systemd version
> -
>
> Key: CASSANDRA-15273
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15273
> Project: Cassandra
> Issue Type: Bug
> Components: Packaging
>Reporter: Aleksandr Yatskin
>Assignee: Michael Semb Wever
>Priority: Urgent
> Attachments:
> 0001-Fix-Red-Hat-init-script-on-newer-systemd-versions.patch
>
>
> After update systemd with fixed vulnerability
> https://access.redhat.com/security/cve/cve-2018-16888, the cassandra service
> does not start correctly.
> Environment: RHEL 7, systemd-219-67.el7_7.1, cassandra-3.11.4-1
> (https://www.apache.org/dist/cassandra/redhat/311x/cassandra-3.11.4-1.noarch.rpm)
> ---
> systemctl status cassandra
> ● cassandra.service - LSB: distributed storage system for structured data
> Loaded: loaded (/etc/rc.d/init.d/cassandra; bad; vendor preset: disabled)
> Active: failed (Result: resources) since Fri 2019-08-09 17:20:26 MSK; 1s ago
> Docs: man:systemd-sysv-generator(8)
> Process: 2414 ExecStop=/etc/rc.d/init.d/cassandra stop (code=exited,
> status=0/SUCCESS)
> Process: 2463 ExecStart=/etc/rc.d/init.d/cassandra start (code=exited,
> status=0/SUCCESS)
> Main PID: 1884 (code=exited, status=143)
> Aug 09 17:20:23 desktop43.example.com systemd[1]: Unit ca
[jira] [Comment Edited] (CASSANDRA-15273) cassandra does not start with new systemd version
[
https://issues.apache.org/jira/browse/CASSANDRA-15273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17050339#comment-17050339
]
Michael Semb Wever edited comment on CASSANDRA-15273 at 3/3/20 4:12 PM:
||branch||circleci||
|[cassandra_3.0_15273|https://github.com/apache/cassandra/compare/cassandra-3.0...thelastpickle:mck/cassandra-3.0_15273]|[circleci|https://circleci.com/gh/thelastpickle/workflows/cassandra/tree/mck%2Fcassandra-3.0_15273]|
|[cassandra_3.11_15273|https://github.com/apache/cassandra/compare/cassandra-3.11...thelastpickle:mck/cassandra-3.11_15273]|[circleci|https://circleci.com/gh/thelastpickle/workflows/cassandra/tree/mck%2Fcassandra-3.11_15273]|
|[trunk_15273|https://github.com/apache/cassandra/compare/trunk...thelastpickle:mck/trunk_15273]|[circleci|https://circleci.com/gh/thelastpickle/workflows/cassandra/tree/mck%2Ftrunk_15273]|
To test this, rather than following the instructions in
https://github.com/apache/cassandra/tree/trunk/redhat , I've taken the
following approach:
{code}
docker image rm -f `docker images -f label=org.cassandra.buildenv=centos -q`
docker build --build-arg CASSANDRA_GIT_URL=${CASSANDRA_GIT_URL} -f
docker/centos7-image.docker docker/
mkdir /tmp/cassandra-rpms
docker run --rm -v /tmp/cassandra-rpms:/dist `docker images -f
label=org.cassandra.buildenv=centos -q` /home/build/build-rpms.sh
${CASSANDRA_GIT_BRANCH}
{code}
This is the same approach as we used when cutting and staging releases, ref
https://github.com/thelastpickle/cassandra-builds/blob/mck/14970_sha512-checksums/cassandra-release/prepare_release.sh#L299-L302
Note, we are short of packaging experience in the community and really do need
extra contributors on this front. Replacing the old initialisation SysV script
with a service script, and testing the building of packages in the CI pipeline,
are obvious subsequent steps that are needed.
was (Author: michaelsembwever):
||branch||circleci||
|[cassandra_3.0_15273|https://github.com/apache/cassandra/compare/cassandra-3.0...thelastpickle:mck/cassandra-3.0_15273]|[circleci|https://circleci.com/gh/thelastpickle/workflows/cassandra/tree/mck%2Fcassandra-3.0_15273]|
|[cassandra_3.11_15273|https://github.com/apache/cassandra/compare/cassandra-3.11...thelastpickle:mck/cassandra-3.11_15273]|[circleci|https://circleci.com/gh/thelastpickle/workflows/cassandra/tree/mck%2Fcassandra-3.11_15273]|
|[trunk_15273|https://github.com/apache/cassandra/compare/trunk...thelastpickle:mck/trunk_15273]|[circleci|https://circleci.com/gh/thelastpickle/workflows/cassandra/tree/mck%2Ftrunk_15273]|
To test this, rather than following the instructions in
https://github.com/apache/cassandra/tree/trunk/redhat , I've taken the
following approach:
{code}
docker image rm -f `docker images -f label=org.cassandra.buildenv=centos -q`
docker build --build-arg CASSANDRA_GIT_URL=${CASSANDRA_GIT_URL} -f
docker/centos7-image.docker docker/
mkdir /tmp/cassandra-rpms
docker run --rm -v /tmp/cassandra-rpms:/dist `docker images -f
label=org.cassandra.buildenv=centos -q` /home/build/build-rpms.sh
${CASSANDRA_GIT_BRANCH}
{code}
This is the same approach as we used when cutting and staging releases, ref
https://github.com/thelastpickle/cassandra-builds/blob/mck/14970_sha512-checksums/cassandra-release/prepare_release.sh#L299-L302
Note, we are short of packaging experience in the community and really need
extra contributors on this front. Replacing the old initialisation SysV script
with a service script, and testing the building of packages in the CI pipeline,
are obvious subsequent steps that are needed.
> cassandra does not start with new systemd version
> -
>
> Key: CASSANDRA-15273
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15273
> Project: Cassandra
> Issue Type: Bug
> Components: Packaging
>Reporter: Aleksandr Yatskin
>Assignee: Michael Semb Wever
>Priority: Urgent
> Attachments:
> 0001-Fix-Red-Hat-init-script-on-newer-systemd-versions.patch
>
>
> After update systemd with fixed vulnerability
> https://access.redhat.com/security/cve/cve-2018-16888, the cassandra service
> does not start correctly.
> Environment: RHEL 7, systemd-219-67.el7_7.1, cassandra-3.11.4-1
> (https://www.apache.org/dist/cassandra/redhat/311x/cassandra-3.11.4-1.noarch.rpm)
> ---
> systemctl status cassandra
> ● cassandra.service - LSB: distributed storage system for structured data
> Loaded: loaded (/etc/rc.d/init.d/cassandra; bad; vendor preset: disabled)
> Active: failed (Result: resources) since Fri 2019-08-09 17:20:26 MSK; 1s ago
> Docs: man:systemd-sysv-generator(8)
> Process: 2414 ExecStop=/etc/rc.d/init.d/cassandra stop (code=exited,
> status
[jira] [Comment Edited] (CASSANDRA-15273) cassandra does not start with new systemd version
[
https://issues.apache.org/jira/browse/CASSANDRA-15273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17050339#comment-17050339
]
Michael Semb Wever edited comment on CASSANDRA-15273 at 3/3/20 4:27 PM:
||branch||circleci||
|[cassandra_3.0_15273|https://github.com/apache/cassandra/compare/cassandra-3.0...thelastpickle:mck/cassandra-3.0_15273]|[circleci|https://circleci.com/gh/thelastpickle/workflows/cassandra/tree/mck%2Fcassandra-3.0_15273]|
|[cassandra_3.11_15273|https://github.com/apache/cassandra/compare/cassandra-3.11...thelastpickle:mck/cassandra-3.11_15273]|[circleci|https://circleci.com/gh/thelastpickle/workflows/cassandra/tree/mck%2Fcassandra-3.11_15273]|
|[trunk_15273|https://github.com/apache/cassandra/compare/trunk...thelastpickle:mck/trunk_15273]|[circleci|https://circleci.com/gh/thelastpickle/workflows/cassandra/tree/mck%2Ftrunk_15273]|
To test this, rather than following the instructions in
https://github.com/apache/cassandra/tree/trunk/redhat , I've taken the
following approach:
{code}
docker image rm -f `docker images -f label=org.cassandra.buildenv=centos -q`
docker build --build-arg CASSANDRA_GIT_URL=${CASSANDRA_GIT_URL} -f
docker/centos7-image.docker docker/
mkdir /tmp/cassandra-rpms
docker run --rm -v /tmp/cassandra-rpms:/dist `docker images -f
label=org.cassandra.buildenv=centos -q` /home/build/build-rpms.sh
${CASSANDRA_GIT_BRANCH}
{code}
This is the same approach as we used when cutting and staging releases, ref
https://github.com/thelastpickle/cassandra-builds/blob/mck/14970_sha512-checksums/cassandra-release/prepare_release.sh#L299-L302
Note, we are short of packaging experience in the community and really do need
extra contributors on this front. Replacing the old initialisation SysV script
with a service script (CASSANDRA-13148), and testing the building of packages
in the CI pipeline, as well as others like CASSANDRA-13433 , are obvious
subsequent steps that are needed.
was (Author: michaelsembwever):
||branch||circleci||
|[cassandra_3.0_15273|https://github.com/apache/cassandra/compare/cassandra-3.0...thelastpickle:mck/cassandra-3.0_15273]|[circleci|https://circleci.com/gh/thelastpickle/workflows/cassandra/tree/mck%2Fcassandra-3.0_15273]|
|[cassandra_3.11_15273|https://github.com/apache/cassandra/compare/cassandra-3.11...thelastpickle:mck/cassandra-3.11_15273]|[circleci|https://circleci.com/gh/thelastpickle/workflows/cassandra/tree/mck%2Fcassandra-3.11_15273]|
|[trunk_15273|https://github.com/apache/cassandra/compare/trunk...thelastpickle:mck/trunk_15273]|[circleci|https://circleci.com/gh/thelastpickle/workflows/cassandra/tree/mck%2Ftrunk_15273]|
To test this, rather than following the instructions in
https://github.com/apache/cassandra/tree/trunk/redhat , I've taken the
following approach:
{code}
docker image rm -f `docker images -f label=org.cassandra.buildenv=centos -q`
docker build --build-arg CASSANDRA_GIT_URL=${CASSANDRA_GIT_URL} -f
docker/centos7-image.docker docker/
mkdir /tmp/cassandra-rpms
docker run --rm -v /tmp/cassandra-rpms:/dist `docker images -f
label=org.cassandra.buildenv=centos -q` /home/build/build-rpms.sh
${CASSANDRA_GIT_BRANCH}
{code}
This is the same approach as we used when cutting and staging releases, ref
https://github.com/thelastpickle/cassandra-builds/blob/mck/14970_sha512-checksums/cassandra-release/prepare_release.sh#L299-L302
Note, we are short of packaging experience in the community and really do need
extra contributors on this front. Replacing the old initialisation SysV script
with a service script, and testing the building of packages in the CI pipeline,
are obvious subsequent steps that are needed.
> cassandra does not start with new systemd version
> -
>
> Key: CASSANDRA-15273
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15273
> Project: Cassandra
> Issue Type: Bug
> Components: Packaging
>Reporter: Aleksandr Yatskin
>Assignee: Michael Semb Wever
>Priority: Urgent
> Attachments:
> 0001-Fix-Red-Hat-init-script-on-newer-systemd-versions.patch
>
>
> After update systemd with fixed vulnerability
> https://access.redhat.com/security/cve/cve-2018-16888, the cassandra service
> does not start correctly.
> Environment: RHEL 7, systemd-219-67.el7_7.1, cassandra-3.11.4-1
> (https://www.apache.org/dist/cassandra/redhat/311x/cassandra-3.11.4-1.noarch.rpm)
> ---
> systemctl status cassandra
> ● cassandra.service - LSB: distributed storage system for structured data
> Loaded: loaded (/etc/rc.d/init.d/cassandra; bad; vendor preset: disabled)
> Active: failed (Result: resources) since Fri 2019-08-09 17:20:26 MSK; 1s ago
> Docs: man:systemd-sysv-generator(8)
> Process: 2414 E
[jira] [Comment Edited] (CASSANDRA-15273) cassandra does not start with new systemd version
[
https://issues.apache.org/jira/browse/CASSANDRA-15273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17050339#comment-17050339
]
Michael Semb Wever edited comment on CASSANDRA-15273 at 3/3/20 4:34 PM:
||branch||circleci||
|[cassandra_3.0_15273|https://github.com/apache/cassandra/compare/cassandra-3.0...thelastpickle:mck/cassandra-3.0_15273]|[circleci|https://circleci.com/gh/thelastpickle/workflows/cassandra/tree/mck%2Fcassandra-3.0_15273]|
|[cassandra_3.11_15273|https://github.com/apache/cassandra/compare/cassandra-3.11...thelastpickle:mck/cassandra-3.11_15273]|[circleci|https://circleci.com/gh/thelastpickle/workflows/cassandra/tree/mck%2Fcassandra-3.11_15273]|
|[trunk_15273|https://github.com/apache/cassandra/compare/trunk...thelastpickle:mck/trunk_15273]|[circleci|https://circleci.com/gh/thelastpickle/workflows/cassandra/tree/mck%2Ftrunk_15273]|
To test this, rather than following the instructions in
https://github.com/apache/cassandra/tree/trunk/redhat , I've taken the
following approach:
{code}
docker image rm -f `docker images -f label=org.cassandra.buildenv=centos -q`
docker build --build-arg CASSANDRA_GIT_URL=${CASSANDRA_GIT_URL} -f
docker/centos7-image.docker docker/
mkdir /tmp/cassandra-rpms
docker run --rm -v /tmp/cassandra-rpms:/dist `docker images -f
label=org.cassandra.buildenv=centos -q` /home/build/build-rpms.sh
${CASSANDRA_GIT_BRANCH}
docker run -v /tmp/cassandra-rpms:/dist -it centos /bin/sh
yum install java-1.8.0-openjdk
rpm -ivh /dist/cassandra-4.0~alpha4-20200303git90a391e.noarch.rpm
{code}
This is the same approach as we used when cutting and staging releases, ref
https://github.com/thelastpickle/cassandra-builds/blob/mck/14970_sha512-checksums/cassandra-release/prepare_release.sh#L299-L302
Note, we are short of packaging experience in the community and really do need
extra contributors on this front. Replacing the old initialisation SysV script
with a service script (CASSANDRA-13148), and testing the building of packages
in the CI pipeline, as well as others like CASSANDRA-13433 , are obvious
subsequent steps that are needed.
was (Author: michaelsembwever):
||branch||circleci||
|[cassandra_3.0_15273|https://github.com/apache/cassandra/compare/cassandra-3.0...thelastpickle:mck/cassandra-3.0_15273]|[circleci|https://circleci.com/gh/thelastpickle/workflows/cassandra/tree/mck%2Fcassandra-3.0_15273]|
|[cassandra_3.11_15273|https://github.com/apache/cassandra/compare/cassandra-3.11...thelastpickle:mck/cassandra-3.11_15273]|[circleci|https://circleci.com/gh/thelastpickle/workflows/cassandra/tree/mck%2Fcassandra-3.11_15273]|
|[trunk_15273|https://github.com/apache/cassandra/compare/trunk...thelastpickle:mck/trunk_15273]|[circleci|https://circleci.com/gh/thelastpickle/workflows/cassandra/tree/mck%2Ftrunk_15273]|
To test this, rather than following the instructions in
https://github.com/apache/cassandra/tree/trunk/redhat , I've taken the
following approach:
{code}
docker image rm -f `docker images -f label=org.cassandra.buildenv=centos -q`
docker build --build-arg CASSANDRA_GIT_URL=${CASSANDRA_GIT_URL} -f
docker/centos7-image.docker docker/
mkdir /tmp/cassandra-rpms
docker run --rm -v /tmp/cassandra-rpms:/dist `docker images -f
label=org.cassandra.buildenv=centos -q` /home/build/build-rpms.sh
${CASSANDRA_GIT_BRANCH}
{code}
This is the same approach as we used when cutting and staging releases, ref
https://github.com/thelastpickle/cassandra-builds/blob/mck/14970_sha512-checksums/cassandra-release/prepare_release.sh#L299-L302
Note, we are short of packaging experience in the community and really do need
extra contributors on this front. Replacing the old initialisation SysV script
with a service script (CASSANDRA-13148), and testing the building of packages
in the CI pipeline, as well as others like CASSANDRA-13433 , are obvious
subsequent steps that are needed.
> cassandra does not start with new systemd version
> -
>
> Key: CASSANDRA-15273
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15273
> Project: Cassandra
> Issue Type: Bug
> Components: Packaging
>Reporter: Aleksandr Yatskin
>Assignee: Michael Semb Wever
>Priority: Urgent
> Attachments:
> 0001-Fix-Red-Hat-init-script-on-newer-systemd-versions.patch
>
>
> After update systemd with fixed vulnerability
> https://access.redhat.com/security/cve/cve-2018-16888, the cassandra service
> does not start correctly.
> Environment: RHEL 7, systemd-219-67.el7_7.1, cassandra-3.11.4-1
> (https://www.apache.org/dist/cassandra/redhat/311x/cassandra-3.11.4-1.noarch.rpm)
> ---
> systemctl status cassandra
> ● cassandra.service - LSB: distributed storage system for structured da
[jira] [Comment Edited] (CASSANDRA-15273) cassandra does not start with new systemd version
[
https://issues.apache.org/jira/browse/CASSANDRA-15273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17050339#comment-17050339
]
Michael Semb Wever edited comment on CASSANDRA-15273 at 3/3/20 5:38 PM:
||branch||circleci||
|[cassandra_3.0_15273|https://github.com/apache/cassandra/compare/cassandra-3.0...thelastpickle:mck/cassandra-3.0_15273]|[circleci|https://circleci.com/gh/thelastpickle/workflows/cassandra/tree/mck%2Fcassandra-3.0_15273]|
|[cassandra_3.11_15273|https://github.com/apache/cassandra/compare/cassandra-3.11...thelastpickle:mck/cassandra-3.11_15273]|[circleci|https://circleci.com/gh/thelastpickle/workflows/cassandra/tree/mck%2Fcassandra-3.11_15273]|
|[trunk_15273|https://github.com/apache/cassandra/compare/trunk...thelastpickle:mck/trunk_15273]|[circleci|https://circleci.com/gh/thelastpickle/workflows/cassandra/tree/mck%2Ftrunk_15273]|
To test this, rather than following the instructions in
https://github.com/apache/cassandra/tree/trunk/redhat , I've taken the
following approach:
{code}
docker image rm -f `docker images -f label=org.cassandra.buildenv=centos -q`
docker build --build-arg CASSANDRA_GIT_URL=${CASSANDRA_GIT_URL} -f
docker/centos7-image.docker docker/
mkdir /tmp/cassandra-rpms
docker run --rm -v /tmp/cassandra-rpms:/dist `docker images -f
label=org.cassandra.buildenv=centos -q` /home/build/build-rpms.sh
${CASSANDRA_GIT_BRANCH}
docker run -v /tmp/cassandra-rpms:/dist -it centos /bin/sh
yum install java-1.8.0-openjdk
rpm -ivh /dist/cassandra-4.0~alpha4-20200303git90a391e.noarch.rpm
rm /etc/security/limits.d/cassandra.conf # this should be fixed
/etc/init.d/cassandra start
tail -F /var/log/cassandra/system.log
{code}
This is the same approach as we used when cutting and staging releases, ref
https://github.com/thelastpickle/cassandra-builds/blob/mck/14970_sha512-checksums/cassandra-release/prepare_release.sh#L299-L302
Note, we are short of packaging experience in the community and really do need
extra contributors on this front. Replacing the old initialisation SysV script
with a service script (CASSANDRA-13148), and testing the building of packages
in the CI pipeline, as well as others like CASSANDRA-13433 , are obvious
subsequent steps that are needed.
was (Author: michaelsembwever):
||branch||circleci||
|[cassandra_3.0_15273|https://github.com/apache/cassandra/compare/cassandra-3.0...thelastpickle:mck/cassandra-3.0_15273]|[circleci|https://circleci.com/gh/thelastpickle/workflows/cassandra/tree/mck%2Fcassandra-3.0_15273]|
|[cassandra_3.11_15273|https://github.com/apache/cassandra/compare/cassandra-3.11...thelastpickle:mck/cassandra-3.11_15273]|[circleci|https://circleci.com/gh/thelastpickle/workflows/cassandra/tree/mck%2Fcassandra-3.11_15273]|
|[trunk_15273|https://github.com/apache/cassandra/compare/trunk...thelastpickle:mck/trunk_15273]|[circleci|https://circleci.com/gh/thelastpickle/workflows/cassandra/tree/mck%2Ftrunk_15273]|
To test this, rather than following the instructions in
https://github.com/apache/cassandra/tree/trunk/redhat , I've taken the
following approach:
{code}
docker image rm -f `docker images -f label=org.cassandra.buildenv=centos -q`
docker build --build-arg CASSANDRA_GIT_URL=${CASSANDRA_GIT_URL} -f
docker/centos7-image.docker docker/
mkdir /tmp/cassandra-rpms
docker run --rm -v /tmp/cassandra-rpms:/dist `docker images -f
label=org.cassandra.buildenv=centos -q` /home/build/build-rpms.sh
${CASSANDRA_GIT_BRANCH}
docker run -v /tmp/cassandra-rpms:/dist -it centos /bin/sh
yum install java-1.8.0-openjdk
rpm -ivh /dist/cassandra-4.0~alpha4-20200303git90a391e.noarch.rpm
{code}
This is the same approach as we used when cutting and staging releases, ref
https://github.com/thelastpickle/cassandra-builds/blob/mck/14970_sha512-checksums/cassandra-release/prepare_release.sh#L299-L302
Note, we are short of packaging experience in the community and really do need
extra contributors on this front. Replacing the old initialisation SysV script
with a service script (CASSANDRA-13148), and testing the building of packages
in the CI pipeline, as well as others like CASSANDRA-13433 , are obvious
subsequent steps that are needed.
> cassandra does not start with new systemd version
> -
>
> Key: CASSANDRA-15273
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15273
> Project: Cassandra
> Issue Type: Bug
> Components: Packaging
>Reporter: Aleksandr Yatskin
>Assignee: Michael Semb Wever
>Priority: Urgent
> Attachments:
> 0001-Fix-Red-Hat-init-script-on-newer-systemd-versions.patch
>
>
> After update systemd with fixed vulnerability
> https://access.redhat.com/security/cve/cve-2018-16888, the cassandra service
> does not start correctly.
> Environment: RHEL 7, systemd-2
[jira] [Comment Edited] (CASSANDRA-15273) cassandra does not start with new systemd version
[
https://issues.apache.org/jira/browse/CASSANDRA-15273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17050339#comment-17050339
]
Michael Semb Wever edited comment on CASSANDRA-15273 at 3/3/20 9:13 PM:
||branch||circleci||
|[cassandra_2.2_15273|https://github.com/apache/cassandra/compare/cassandra-2.2...thelastpickle:mck/cassandra-2.2_15273]|[circleci|https://circleci.com/gh/thelastpickle/workflows/cassandra/tree/mck%2Fcassandra-2.2_15273]|
|[cassandra_3.0_15273|https://github.com/apache/cassandra/compare/cassandra-3.0...thelastpickle:mck/cassandra-3.0_15273]|[circleci|https://circleci.com/gh/thelastpickle/workflows/cassandra/tree/mck%2Fcassandra-3.0_15273]|
|[cassandra_3.11_15273|https://github.com/apache/cassandra/compare/cassandra-3.11...thelastpickle:mck/cassandra-3.11_15273]|[circleci|https://circleci.com/gh/thelastpickle/workflows/cassandra/tree/mck%2Fcassandra-3.11_15273]|
|[trunk_15273|https://github.com/apache/cassandra/compare/trunk...thelastpickle:mck/trunk_15273]|[circleci|https://circleci.com/gh/thelastpickle/workflows/cassandra/tree/mck%2Ftrunk_15273]|
To test this, rather than following the instructions in
https://github.com/apache/cassandra/tree/trunk/redhat , I've taken the
following approach:
{code}
docker image rm -f `docker images -f label=org.cassandra.buildenv=centos -q`
docker build --build-arg CASSANDRA_GIT_URL=${CASSANDRA_GIT_URL} -f
docker/centos7-image.docker docker/
mkdir /tmp/cassandra-rpms
docker run --rm -v /tmp/cassandra-rpms:/dist `docker images -f
label=org.cassandra.buildenv=centos -q` /home/build/build-rpms.sh
${CASSANDRA_GIT_BRANCH}
docker run -v /tmp/cassandra-rpms:/dist -it centos /bin/sh
yum install java-1.8.0-openjdk
rpm -ivh /dist/cassandra-4.0~alpha4-20200303git90a391e.noarch.rpm
rm /etc/security/limits.d/cassandra.conf # this should be fixed
/etc/init.d/cassandra start
tail -F /var/log/cassandra/system.log
{code}
This is the same approach as we used when cutting and staging releases, ref
https://github.com/thelastpickle/cassandra-builds/blob/mck/14970_sha512-checksums/cassandra-release/prepare_release.sh#L299-L302
Note, we are short of packaging experience in the community and really do need
extra contributors on this front. Replacing the old initialisation SysV script
with a service script (CASSANDRA-13148), and testing the building of packages
in the CI pipeline, as well as others like CASSANDRA-13433 , are obvious
subsequent steps that are needed.
was (Author: michaelsembwever):
||branch||circleci||
|[cassandra_3.0_15273|https://github.com/apache/cassandra/compare/cassandra-3.0...thelastpickle:mck/cassandra-3.0_15273]|[circleci|https://circleci.com/gh/thelastpickle/workflows/cassandra/tree/mck%2Fcassandra-3.0_15273]|
|[cassandra_3.11_15273|https://github.com/apache/cassandra/compare/cassandra-3.11...thelastpickle:mck/cassandra-3.11_15273]|[circleci|https://circleci.com/gh/thelastpickle/workflows/cassandra/tree/mck%2Fcassandra-3.11_15273]|
|[trunk_15273|https://github.com/apache/cassandra/compare/trunk...thelastpickle:mck/trunk_15273]|[circleci|https://circleci.com/gh/thelastpickle/workflows/cassandra/tree/mck%2Ftrunk_15273]|
To test this, rather than following the instructions in
https://github.com/apache/cassandra/tree/trunk/redhat , I've taken the
following approach:
{code}
docker image rm -f `docker images -f label=org.cassandra.buildenv=centos -q`
docker build --build-arg CASSANDRA_GIT_URL=${CASSANDRA_GIT_URL} -f
docker/centos7-image.docker docker/
mkdir /tmp/cassandra-rpms
docker run --rm -v /tmp/cassandra-rpms:/dist `docker images -f
label=org.cassandra.buildenv=centos -q` /home/build/build-rpms.sh
${CASSANDRA_GIT_BRANCH}
docker run -v /tmp/cassandra-rpms:/dist -it centos /bin/sh
yum install java-1.8.0-openjdk
rpm -ivh /dist/cassandra-4.0~alpha4-20200303git90a391e.noarch.rpm
rm /etc/security/limits.d/cassandra.conf # this should be fixed
/etc/init.d/cassandra start
tail -F /var/log/cassandra/system.log
{code}
This is the same approach as we used when cutting and staging releases, ref
https://github.com/thelastpickle/cassandra-builds/blob/mck/14970_sha512-checksums/cassandra-release/prepare_release.sh#L299-L302
Note, we are short of packaging experience in the community and really do need
extra contributors on this front. Replacing the old initialisation SysV script
with a service script (CASSANDRA-13148), and testing the building of packages
in the CI pipeline, as well as others like CASSANDRA-13433 , are obvious
subsequent steps that are needed.
> cassandra does not start with new systemd version
> -
>
> Key: CASSANDRA-15273
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15273
> Project: Cassandra
> Issue Type: Bug
> Components: Packaging
>Reporter: Aleksandr Yatskin
>
[jira] [Comment Edited] (CASSANDRA-15273) cassandra does not start with new systemd version
[ https://issues.apache.org/jira/browse/CASSANDRA-15273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16905863#comment-16905863 ] Aleksandr Yatskin edited comment on CASSANDRA-15273 at 8/13/19 6:23 AM: The cassandra starts, but the systemd cannot control it. The cause is that when the cassandra starts, the old initialization SysV script is used, in which it is obviously impossible to specify the user and group to start the service. It's about user/group options for systemd: - _[Service]_ _User=cassandra_ _Group=cassandra_ - But since the process pid is created with the permissions of the cassandra user, and the user and group are not specified in the initialization script, the systemd consider that it uses the root to start the service (by default) and does not allow creating the pid with cassandra user permissions. -- _systemd[1]: New main PID 2545 does not belong to service, and PID file is not owned by root. Refusing._ -- More details in CVE-2018-16888 ([https://access.redhat.com/security/cve/cve-2018-16888]) -- _It was discovered systemd does not correctly check the content of PIDFile files before using it to kill processes. When a service is run from an unprivileged user (e.g. User field set in the service file), a local attacker who is able to write to the PIDFile of the mentioned service may use this flaw to trick systemd into killing other services and/or privileged processes._ -- was (Author: aleksandr yatskin): The cassandra starts, but the systemd cannot control it. The cause is that when the cassandra starts, the old initialization SysV script is used, in which it is obviously impossible to specify the user and group to start the service. It's about user/group options for systemd: - _[Service]_ _User=cassandra_ _Group=cassandra_ - But since the process pid is created with the permissions of the cassandra user, and the user and group are not specified in the initialization script, the systemd consider that it uses the root to start the service (by default) and does not allow creating the pid with cassandra user permissions. -- _systemd[1]: New main PID 2545 does not belong to service, and PID file is not owned by root. Refusing._ -- More details in CVE-2018-16888 ([https://access.redhat.com/security/cve/cve-2018-16888]) -- _It was discovered systemd does not correctly check the content of PIDFile files before using it to kill processes. When a service is run from an unprivileged user (e.g. User field set in the service file), a local attacker who is able to write to the PIDFile of the mentioned service may use this flaw to trick systemd into killing other services and/or privileged processes._ -- > cassandra does not start with new systemd version > - > > Key: CASSANDRA-15273 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15273 > Project: Cassandra > Issue Type: Bug >Reporter: Aleksandr Yatskin >Priority: Normal > > After update systemd with fixed vulnerability > https://access.redhat.com/security/cve/cve-2018-16888, the cassandra service > does not start correctly. > Environment: RHEL 7, systemd-219-67.el7_7.1, cassandra-3.11.4-1 > (https://www.apache.org/dist/cassandra/redhat/311x/cassandra-3.11.4-1.noarch.rpm) > --- > systemctl status cassandra > ● cassandra.service - LSB: distributed storage system for structured data > Loaded: loaded (/etc/rc.d/init.d/cassandra; bad; vendor preset: disabled) > Active: failed (Result: resources) since Fri 2019-08-09 17:20:26 MSK; 1s ago > Docs: man:systemd-sysv-generator(8) > Process: 2414 ExecStop=/etc/rc.d/init.d/cassandra stop (code=exited, > status=0/SUCCESS) > Process: 2463 ExecStart=/etc/rc.d/init.d/cassandra start (code=exited, > status=0/SUCCESS) > Main PID: 1884 (code=exited, status=143) > Aug 09 17:20:23 desktop43.example.com systemd[1]: Unit cassandra.service > entered failed state. > Aug 09 17:20:23 desktop43.example.com systemd[1]: cassandra.service failed. > Aug 09 17:20:23 desktop43.example.com systemd[1]: Starting LSB: distributed > storage system for structured data... > Aug 09 17:20:23 desktop43.example.com su[2473]: (to cassandra) root on none > Aug 09 17:20:26 desktop43.example.com cassandra[2463]: Starting Cassandra: OK > Aug 09 17:20:26 desktop43.example.com systemd[1]: New main PID 2545 does not > belong to service, and PID file is not owned by root. Refusing. > Aug 09 17:20:26 desktop43.example.com systemd[1]: New main PID 2545 does not > belong to service, and
